- SAP Managed Tags:
In this blog, we'll take a look at the difference between synchronous and asynchronous APIs as they relate to SAP S/4HANA Cloud with an example.
First, we should define what these terms asynchronous and synchronous mean since it is often a source of confusion. In general, a synchronous API will have the calling system wait for a response from the target system. That is to say, the source system waits for the outcome of the operation requested and any associated payload. For example, the completed payload with any success or error codes. On the other hand, for an asynchronous call, the calling system (i.e. source) does not wait for a response from the target system, it continues on processing the application or interface logic. It's more of a send and forget type scenario. In an asynchronous scenario, the callign system doesn't know if there is an error, it simply delivers the payload.
As a API example, think of video conferencing and instant messaging as synchronous (i.e. real time interaction) and text messaging and email as asynchronous (message is sent and at some point in time the information will be picked up and processed by the receiver).
Each has several advantages and we'll take a look at one of the biggest differences in terms of how they are monitored in this blog.
For this blog, we'll explore a API that was released in 1808 to the existing Journal Entry API that is commonly used by customers to post journal entries into SAP S/4HC. The Post Journal Entry on SAP API hub now has 2 SOAP based services for posting journal entries--one is asynchronous (new) and the other synchronous (existing).
I setup SAP_COM_0002 Communication Arrangement in my SAP S/4HC system and you can see both endpoints shown under Inbound Services.
In order to demo the differences, I created 2 iFlows on SAP Cloud Platform Integration (CPI) that post a single journal entry to S/4HC from a JSON payload submitted using Postman. Both have the very simple flow as shown below in the screenshot. A JSON payload is submitted from Postman, converted to XML, a message mapping step then occurs followed by the web service call. The groovy scripts only log the payloads for demo purposes in this blog. The two iFlows are identical except for the service they call in SAP S/4HC.
One of the biggest differences between the two is how these interfaces are monitored. In a synchronous scenario, CPI needs to analyze the response and determine if the journal entry post was successful. In an asynchronous scenario, the monitoring and error handling is carried out in SAP S/4HC using the Application Interface Framework (AIF). There are many benefits to using asynchronous in this fashion for system to system communication where S/4HC users may not have access to CPI and/or the source system sending journal entries. For example, in the asynchronous scenario business users would use SAP S/4HC to check on the status of all of the interfaces, take actions to reprocess payload(s), subscribe to events, etc. In a synchronous scenario, in order to monitor the interface for an error someone needs to log into CPI to determine (if) there were errors and the course of action to reprocess them (or receive an email that an interface failed and then log into CPI to troubleshoot). Of course, if the service itself was down CPI log an error in both cases.
Regarding the AIF and Message Monitor capabilities (help documentation), you can find this documented on the business documentation page of the asynchronous journal entry service. Here is the section at the bottom of the page:
In order to use the Message Monitoring capabilities in S/4HC, I assigned my user the business role SAP_BR_CONF_EXPERT_BUS_NET_INT.
Then the FINAC_RET_JOURNALENTRY_IN recipient can be set up for namespace /FINAC
Finally, I assign my user to the recipient.
And can now see the Namespace/Interface in my message dashboard.
First, we'll execute the iFlow which calls the synchronous API (journalentrycreaterequestconfi) 2 times--one with an error and the other successful. In both cases, the iFlow status shows as "Completed successfully". The developer would need to take special action to trigger the Exception handling on the iFlow so the iFlow either shows status of Failed or sends an email for a person(s) to take follow up actions.
In this case, I submitted an invalid material number in my payload and you can see the response from SAP S/4HC in CPI monitoring web ui:
Removing the material and resubmitting to the iFlow from Postman results in a successful posting of the Journal Entry.
It's also worth noting that these are the same payloads received in Postman as well.
Now, we'll execute the iFlow that calls the asynchronous API (journalentrybulkcreationreques) 2 times--one with an error and the other successful.
In both cases, the logged response in CPI and Postman are simply the submitted payload:
However, if we look in the Message Dashboard in S/4HC a user can analyze the status of the interface very easily.
Filtered for today's date, I can see 2 messages were submitted today and 1 was successfully processed while the other did not.
Drilling further into the details, I can see the posting with the invalid material code. From here I could take further action as appropriate.
And of course I can see the successful journal entry posting:
That's all for the blog. There are other pros/cons to synchronous vs asynchronous depending on the scenario but hope you found this blog helpful.
Best Regards,
Marty
First, we should define what these terms asynchronous and synchronous mean since it is often a source of confusion. In general, a synchronous API will have the calling system wait for a response from the target system. That is to say, the source system waits for the outcome of the operation requested and any associated payload. For example, the completed payload with any success or error codes. On the other hand, for an asynchronous call, the calling system (i.e. source) does not wait for a response from the target system, it continues on processing the application or interface logic. It's more of a send and forget type scenario. In an asynchronous scenario, the callign system doesn't know if there is an error, it simply delivers the payload.
As a API example, think of video conferencing and instant messaging as synchronous (i.e. real time interaction) and text messaging and email as asynchronous (message is sent and at some point in time the information will be picked up and processed by the receiver).
Each has several advantages and we'll take a look at one of the biggest differences in terms of how they are monitored in this blog.
For this blog, we'll explore a API that was released in 1808 to the existing Journal Entry API that is commonly used by customers to post journal entries into SAP S/4HC. The Post Journal Entry on SAP API hub now has 2 SOAP based services for posting journal entries--one is asynchronous (new) and the other synchronous (existing).
I setup SAP_COM_0002 Communication Arrangement in my SAP S/4HC system and you can see both endpoints shown under Inbound Services.
In order to demo the differences, I created 2 iFlows on SAP Cloud Platform Integration (CPI) that post a single journal entry to S/4HC from a JSON payload submitted using Postman. Both have the very simple flow as shown below in the screenshot. A JSON payload is submitted from Postman, converted to XML, a message mapping step then occurs followed by the web service call. The groovy scripts only log the payloads for demo purposes in this blog. The two iFlows are identical except for the service they call in SAP S/4HC.
One of the biggest differences between the two is how these interfaces are monitored. In a synchronous scenario, CPI needs to analyze the response and determine if the journal entry post was successful. In an asynchronous scenario, the monitoring and error handling is carried out in SAP S/4HC using the Application Interface Framework (AIF). There are many benefits to using asynchronous in this fashion for system to system communication where S/4HC users may not have access to CPI and/or the source system sending journal entries. For example, in the asynchronous scenario business users would use SAP S/4HC to check on the status of all of the interfaces, take actions to reprocess payload(s), subscribe to events, etc. In a synchronous scenario, in order to monitor the interface for an error someone needs to log into CPI to determine (if) there were errors and the course of action to reprocess them (or receive an email that an interface failed and then log into CPI to troubleshoot). Of course, if the service itself was down CPI log an error in both cases.
Regarding the AIF and Message Monitor capabilities (help documentation), you can find this documented on the business documentation page of the asynchronous journal entry service. Here is the section at the bottom of the page:
Configure Message Monitoring for AIF
In order to use the Message Monitoring capabilities in S/4HC, I assigned my user the business role SAP_BR_CONF_EXPERT_BUS_NET_INT.
Then the FINAC_RET_JOURNALENTRY_IN recipient can be set up for namespace /FINAC
Finally, I assign my user to the recipient.
And can now see the Namespace/Interface in my message dashboard.
Synchronous API Call
First, we'll execute the iFlow which calls the synchronous API (journalentrycreaterequestconfi) 2 times--one with an error and the other successful. In both cases, the iFlow status shows as "Completed successfully". The developer would need to take special action to trigger the Exception handling on the iFlow so the iFlow either shows status of Failed or sends an email for a person(s) to take follow up actions.
In this case, I submitted an invalid material number in my payload and you can see the response from SAP S/4HC in CPI monitoring web ui:
Removing the material and resubmitting to the iFlow from Postman results in a successful posting of the Journal Entry.
It's also worth noting that these are the same payloads received in Postman as well.
Asynchronous API Call
Now, we'll execute the iFlow that calls the asynchronous API (journalentrybulkcreationreques) 2 times--one with an error and the other successful.
In both cases, the logged response in CPI and Postman are simply the submitted payload:
However, if we look in the Message Dashboard in S/4HC a user can analyze the status of the interface very easily.
Filtered for today's date, I can see 2 messages were submitted today and 1 was successfully processed while the other did not.
Drilling further into the details, I can see the posting with the invalid material code. From here I could take further action as appropriate.
And of course I can see the successful journal entry posting:
That's all for the blog. There are other pros/cons to synchronous vs asynchronous depending on the scenario but hope you found this blog helpful.
Best Regards,
Marty
7 Comments
