Summary
This has been a short but concise chapter that has explained how to communicate between logic apps. We looked at the idea of an orchestrator – a central gateway in which you can receive messages and then reroute them for further processing. We considered how the parent and child logic apps communicate and looked at the traditional logic app action step as opposed to an HTTP action step. We then considered using a SQL table to index the audit actions in our message from our legacy system. We can then use this table to determine which logic app the message needs to be passed to.
After, we refined the HTTP POST action from the initial HTTP action step, which was very much like the one-way fire and forget principle and compared this to the request/response actions. These work as a pair that receives an HTTP message and processes it within the logic app. At the end of the logic app, we send a message containing the output back to the parent logic app for further processing...