Webhooks are very common today. What are webhooks? They are a way to get notified when something happens. For example, if you like to get notified when a virtual machine shuts down in Microsoft Azure, just configure a webhook URL in Azure. When the virtual machine shuts down at any point in time, it calls the configured webhook URL. This method is much better than polling to see if the virtual machine has shut down.
This is the most common pattern for event-based programming, where you subscribe to an event and then when that event happens, it notifies the subscriber or subscribers. Most web applications let you configure webhooks to notify you when events happen, whether it's HubSpot, Salesforce, or SugarCRM they all support webhooks.
FlowWright Enterprise service bus always supported webhooks, a published event is processed using event handlers but also passed on to a configured webhook. This method always pushed out information, but with the implementation of Microservices, FlowWright now can receive webhooks too.
If you are not familiar with Microservices, here’s a quick video on how to build a Microservice within FlowWright. It's a way to turn any workflow definition into a REST API.
Workflow Microservice Architecture - Microservices Workflows - Flowwright
Once the Microservice/REST API is built, the REST API URL can be used as a webhook to receive events from other systems. For example, when a deal is created within the CRM system, an event is raised, this event will automatically call the webhook URL configured, which in turn runs the Microservice within FlowWright.
Depending on each webhook configuration, incoming data through the HTTP protocol could be in various formats such as text, XML, or JSON formats. You might want to have a custom step, within the workflow definition, to decode incoming data from the microservice input parameters. Microservice input parameters are directly mapped to variables/globals within the workflow definition.
Webhooks are another good use of Microservices within FlowWright.