Web API requirement.

I recently implemented something similar. In the process I had a "Receive Message" event waiting. I had a Web API receiving the data which started a process. This process sends the data via a message to the waiting one. Works, but I think this is not the best solution. Next time I will try to just have short snippets of process, persisting state and data in DB, and each incoming call just figures out by status which process to start next. This way there are no active waiting process instances. Keep an eye on proper validation of incoming data and also if a specific call is allowed in the status the process is in.

Why not separate it in two processes instead?

The second process should receive an identifier or something to match it with the first process.

You could then call the second process to start from the API directly and you would probably need to handle exceptions on the second process.

Thanks for your reply, 
Could you please elaborate on what steps you have performed in the process model? 

Thanks,

Sharath

For which variant?

Why don''t you create two WebAPI endpoints? I think it would be easier and will it it more reusable assuming that you divide the operations properly?

For example:

Create a Process Model with these Elements

1. User Input Task->
   1. Form 1 (Enter User Information)
   2. User enters information
   3. User submits
   4. Send data to Web API #1
   5. User gets response.
2. User gets response -> If continue = YES (XOR Gateway)
   1. YES:
      1. User Input Task
      2. Pass data from Form 1 to Form 2 (Enter other details) in Process Variables
      3. User enters information
      4. User submits
      5. Send data to Web API #2
      6. User gets response
   2. NO, display reason not to continue
3. User Input Task -> Form 3 -> Display Confirmation