Now that we covered the event processing phase and went through all the basic concepts related to setting up the B1iF to properly “supervise” those events for us, let’s get to the intriguing part of our project – receiving the outgoing payload (XML) sent with the HTTPCall Atom and invoking our WebHook which then triggers our workflow.
I assume you already have an active Azure subscription; if not, it is high time you got one.
Logic App Workflow Steps:
Step 1) Our Logic App needs to have a trigger – In our case, this will be the “When a HTTP request is received” connector:
Remember, all we want is to subscribe to a service endpoint by registering a callback URL. This URL will get generated once the Logic App is saved for the first time, and it will be unique to this workflow.
Step 2) If you recall , the HTTPCall Atom on B1iF is to call our workflow (using the above callback URL) sending an XML body, so we would use the “triggerBody()“expression to retrieve whatever our trigger has to deliver.
In fact, B1iF maintains its own XSL Transformation Schemas for pretty much any output type that is required by the Receiver System, so we can make sure to do that conversion even before we relay the payload to the outbound final Atom.
This would involve additional steps to prepare the output so that our WebHook gets a JSON body instead of an XML body. To keep things simple, I decided to use a faster way and do the conversion from within the Logic App itself.
- If you wish to know more about XSL Transformation Schemas, go to Version 1.X of your B1iF, navigate to Help -> Documents and look for “Schemas”. I could potentially write a subsequent blog on how to handle various schema types during XSL transformations.
So, our 2nd workflow step would involve a “Compose” action that converts the body to a JSON element :
Step 3) IF we were to execute the workflow up to its 2nd action, this would yield the following output :
We can clearly notice that the value we are looking to get (New Business Partner Code, remember ? ) is “hiding” within the newly created JSON object, and we need to extract it from there
Step 4) We will then create a second “Compose” action and use the “Outputs()“ expression to navigate through our JSON:
This action will retrieve the BP code and will store its value
This could very well be a Sales Order with items, an Invoice, or a new item that is created/updated – it really depends on your business scenario.
The important thing is that now you can hold on to it and use it to do whatever is needed based on your requirements:
- You can trigger an approval process
- You can generate a PO based on a Sales Order
- You can send a Quotation to a customer for a newly created item
These could all be achieved by using the SAP Business One Service Layer from within the Logic App.
The final action, in my case, would be to send an Email to myself using the “Send an email (V2)” connector and use the outputs of the “Compose” action as the Email body:
Our final flow will look like the following :
And then comes the Email itself:
Once again, we need to save our Logic App so that our callback URL is generated :
Once we copy that URL, we can go back to B1iF and wrap things up – we would breakdown the URL into the following fields :
- destProtocol- https
- destHost- our Azure host name
- destPort- 443
- destPath- the remaining URL string
- Method- Will usually be a “POST” for this scenario.
Despite the fact that our scenario was not too complex, we were able to have a glimpse of how Built-In SAP Business One Events could be fetched and then utilized to trigger other business flows using both the Integration Framework and Serverless Technology like Azure Logic Apps Workflows
The immediate benefits we get from doing so include:
- Reduced DevOps
- Faster Time To Market (= a Happier customer while also assisting us in better managing our own internal resources)
- Reduced Costs
Azure Logic Apps has been with us for quite some time now, but with the current running version, there is pretty much nothing that could not be achieved when building an integration to our ERP and managing our APIs.
The fact that we can skip a relatively long (tedious and also rather expensive) process of subscribing to the SAP BTP platform and setting up the Event Mesh/Grid to work with it opens up a vast window of opportunity for us to fire business workflows that are only based on real-life events coming from our own ERP, in real-time, rather than repeatedly polling and checking our endpoints to see if we have some data to work with.