Parameters to Embedded SAIL

@riccardob if i am not wrong, there somewhere you are talking about communication External System with Appian, where you want to pass the Data as parameter from External System (i.e. Can be JS, HTML, JQuery, Java Controllers etc..) to Appian SAIL. If so then as per my understanding You cannot

@riccardob if i am not wrong, then somewhere you are talking about communicating External System with Appian, where you want to pass the Data as parameter from External System (i.e. Can be JS, HTML, JQuery, Java Controllers etc..) to Appian SAIL. If so then as per my understanding You cannot

@aloks176: yes, that's what I meant and we were not able to figure out a way for doing it... Thanks for you answer

You might look at setting up a webAPI to receive data from the external system, and then figuring out a way to make sure the embedded interface only appears for the user after the web api has completed it's action.

@jims419 If you use WEB API to send the data from external system then as per @riccardob requirement a Task won't be appeared to show SAIL From. As per my understanding there is no direct approach, but still there is a indirect approach, You can create a Process Model which will contain SAIL Forms as well as other Nodes as usual, and then you can expose your Process Model as a SOAP Service, as we know SOAP Exchange medium is XML, which is a common for any programming languages, so then consider invoking your SOAP Service along with required parameters (Provided in Process Model which was exposed as SOAP Service) from External Application, so a new Instance of your Process Model will be instantiated, but in this approach at each Service invoke a new Instance of your Process Model will be created. So we do not have any direct approach to send Data as Parameters to existing SAIL form.
So if creation of Task is not a concern then you can go for Exposing Your Process Model as service

I hope this will help you

Thanks @jims419 and @aloks176 for your responses!
We're thinking about using an approch that is mixing your ideas: create an Appian WebAPI that starts a process, hit this from JS and store the returned ppId which will be used for another WebAPI call that returns the taskId from a given ppId. At this point we'll populate (again via JS) the taskId attribute of an <appian-task> element with the value got by the last call. We've not started this implementation yet.
What do you think about this solution?

@riccardob i think your approach may work, But in this case also for each Interaction to WEB-API will cause one new Instances of your Process Model to be Instantiated, so as per my understanding Exposing Process Model as Service Could result better compared to Web-API. However in your approach if you are able to get you TaskID, it might be helpful, but not sure

@riccardob, A webapi can do more than just start a process (complete task, write to data store, etc), so it's more flexible than just exposing a process as a web service. The problem with the double webapi approach is that you're not guaranteed that the task you want has been activated by the time the second call goes through. (I've done a hack-y solution that seems to work, but I'm not going to suggest that publicly)
The other approach would be to have Appian "callback" to your Application, and handle that callback on your server side to trigger a reaction to the appropriate client, using something like Server Side Events/websockets. That technology is a bit new, so it will depend on how custom your external app is on whether you could implement something with that.