Hi,
For handling asynchronous calls from Appian, I have analyzed below approaches. Can you pls advise which approach would be suitable for below scenario? If you have any better solution, kindly let me know.
Thank you in advance.
Design summary:
1- Orchestration is carried out in Appian process model. There are three external APIs (Say A, B and C) that need to be invoked from Appian.
2- After calling API-A, Appian will hold the process flow
3- Once Appian receives response for API-A asynchronously, then it should move on next step
4- Same pattern follows for API- B and API-C
We have following solutions to accomplish this Asynchronous communication pattern.
Solution-1:
Disadvantage:
Solution-2:
Solution-3:
This approach is tightly coupled and P2P communication.
Discussion posts and replies are publicly visible
My suggestion is to not have any active process waiting. Why not send out the message, persist some state in DB and start the next process phase as the result comes in?
You will probably want to implement some house keeping to find "processes" waiting for a result for too long.
Thanks for your reply, but in our use case we cannot go with the approach you mentioned i.e. using db and instead we need to handle in the process itself.
we want to hold process flow and move to next task/activity once Appian gets the response from webapi asynchronously.
Appreciate your help.
What is the reason for not going the proposed way?
About how many process instances are we talking? Depending on that one or the other solution might be better.
There is no info to save in DB. All we need is to hold process flow after the API invocation till Appian gets the response from upstream systems asynchronously. Also to answer your question on transaction volume, the instance count will be considerably high.
OK. Then this is another reason for not going the way to keep a high number of processes in flight.
Last year I implemented a call-back mechanism to talk to other systems over a message bus. In the outgoing message is a unique identifier. In DB I store that identifier, expected response time and the UUID of the process to start as the message with that identifier comes back.
I had a polling process to check for new messages. Your case is easier. The API gets the message, checks DB for the process to start and ... done.
Agreed with Stefan - it's always best practice to not have your process "wait" for an external event. What would happen if you never received the response back? Now either your process waits forever and you never clear that from memory or you have to expire the task and may miss responses from long waits.
Surely you have something that could be stored in the database - otherwise, how would you route the request back from the external system to the correct process?