In the second part of the blog series on how to Integrate SAP using the SAP IDoc Snaps we are going to have a look at the behaviour of the IDoc Write Snaps and the various settings you can make as well as shed light into the configuration inside SAP to either have the SnapLogic Pipeline process synchronously or asynchronously in case you intend to continue processing your pipeline without waiting for the IDoc processing to finish in the SAP system.
Understanding the settings in the IDoc Write Snap
The most important setting you will need to make is adding the name of the Function Module in the IDoc Read BAPI Name field that is used to read the status of the IDoc once it is created in the SAP system. We discussed the Function Module in the first part of our blog series and attached a sample implementation at the bottom of the first blog. Once an IDoc is created the Snap will attempt to read the IDoc via the Function Module exactly once to determine the current status the IDoc has in the SAP system and then use this status to determine if the SnapLogic pipeline should continue processing the document downstream or route the document to the Error View. For the Snap to do so, the Route errors checkbox must be selected.
IDoc statuses in the SAP system are divided into two parts: Outbound IDocs ranging from 01-42 and Inbound IDoc processing ranging from 50-75. You can see a complete listing of IDoc status codes using transaction WE47 in the SAP system. Going into all the details of IDoc status codes is beyond this blog, but standard inbound IDoc processing typically goes through these state transitions:
- 50 IDoc added
- 64 IDoc ready to be passed
- 62 IDoc passed to application
- 53 Application document posted.
By adding the above status codes to the Success Codes fields, you tell the Snap to route documents to the output view if the IDocs created has any of these statuses at the time of reading the status. All other documents that created IDocs with other statuses will be routed to the Error View. Again, as the function module only reads the status once and only looks at the current status at the time of reading, it is essential to add all statuses to the field that should be used to continue processing your document downstream.
The Polling Interval and Polling Timeout fields control the time that you want the Snap to wait to determine the status of the IDoc. If the Polling Interval is set to 0, the Snap will not use the Function Module and will not try to read the status of the IDoc at all. Any setting above 0 will be used as the seconds to wait in between calls to the SAP system to read a status. The Polling Timeout will determine the overall time to wait before throwing a Java Exception. The settings can be used if you create IDocs in very busy SAP systems, for which you must determine the status of the IDoc to determine your routing.
Understanding processing behaviour of IDocs in SAP
At the time of writing, the SnapLogic SAP IDocs only support tRFC (transactional Remote Function Call), and qRFC (queued Remote Function Call) is not supported. Furthermore, our IDoc Snaps use SAP's JCO Library and the accompanying IDoc Java Library to create IDocs. With that, we will focus only on the IDoc Java library's behavior when calling the JCoIDoc.send(..) methods. Be aware that systems that are not making use of these libraries may expose a different behavior as well as different options.
Synchronous Behaviour of IDoc Processing
When we first started investigating the various behaviors, we often found people on the Internet saying that IDocs are always asynchronous. Still, we observed a different behavior when using the IDoc Write snap, which appeared to wait for the processing to "finish" in SAP before continuing. We ended up posting a question on SAP's Software Developer Network. We soon got an answer pointing us to SAP Note 180057 that explains that SAP has changed the behavior of the function module IDOC_INBOUND_ASYNCHRONOUS and no longer decouples the creation of the IDoc in the ALE layer from the transfer to the application. IDOC_INBOUND_ASYNCHRONOUS is the Function Module used in the IDoc Java Library by the JCoIDoc.send(..) method. This means that if you have configured your IDoc coming from SnapLogic to be processed immediately in transaction WE20, as shown in the screenshot below.
The creation of the IDoc in the ALE layer of SAP will happen in the same process as the processing of the IDoc by the application, and the SAP IDoc Java Library will wait until the application has finished processing the IDoc. With the library waiting, the IDoc Write Snap cannot call for the IDoc status, although the IDoc has already passed status codes 50, 64, and 62. This behavior effectively binds the SnapLogic pipeline to the entire processing of the IDoc by the application inside SAP, and the pipeline will only continue once the IDoc processing finishes.
Options for asynchronous processing of IDocs
If you are interested in decoupling your SnapLogic pipeline from the processing of the IDoc in SAP Note 180057 presents multiple options. Unfortunately, the first solution to use the INBOUND_IDOC_PROCESS function module is unavailable to us as the SAP IDoc Java Library does not give a choice to use this function module. Also, option two, transferring smaller packages of IDocs, does not work as this would still wait for the application to finish processing. That leaves us with two options: The first would be to switch the processing of your IDoc in Transaction WE20 from Trigger Immediately to Trigger in background program.
This configuration will decouple the creation of the IDoc in the ALE layer of SAP from the processing of the IDoc by the application and allow the SAP IDoc Write to continue as soon as the IDoc is created in the ALE layer. This also means that the status your IDoc will have when the SAP IDoc Write Snap reads will never be past 64.
The second option is to use an ABAP-PI port for the incoming IDoc in Transaction WE21 and then specify the ABAP-PI port instead of a Transactional RFC port in the control structure of your IDoc.
The screenshot below demonstrates the Port configuration in Transaction WE21. When creating the port, you can choose any function module. In this case, we used RFC_PING. It's worth noting that the function module you specify is not used during Inbound Processing but is required to save the configuration.
Once the port is specified, use the new port name, ASYNC0001, in our case, in the SNDPOR field of the Control Structure of your IDOC. To give you an idea, we use the below JSON in a JSON Generator Snap in the sample pipeline we attached to the first part of the blog series but replace the SNDPOR field with the port name of the ABAP-PI port.
{
"EDI_DC40": {
"MESTYP" : "ZPERSONDATA",
"SNDPRT" : "LS",
"SNDPRN" : "SNPCLNT000",
"SNDPOR" : "ASYNC00001",
"RCVPRT" : "LS",
"RCVPRN" : "A4HCLNT001"
},
"ZPERSONDATA01": [
{
"FIRSTNAME": "Ingo",
"LASTNAME": "Sauerzapf",
"TITLE": "Mr.",
"GENDER": "male",
"STREET": "33rd Str.",
"CITY": "New York",
"ZIP": "98632",
"COUNTRY": "United States",
"EMAIL": "ingo.s@somecompany.com",
"PHONE": "5405883833",
"SLEEPTIME": 40
}
]
}
When sent via an ABAP-PI port, the SAP system starts the application for direct processing but does not wait for the end of processing. Your IDoc Write Snap will be able to continue to read the status immediately.
Testing the behavior when switching between synchronous and asynchronous processing
To test the behavior, we created an IDoc in the SAP system and built a tiny application that will take the data of the incoming IDoc and write it to a table in the SAP system database. To simulate long-running IDoc processing, we added a sleep statement of 60 seconds. When we create an IDoc by sending it to the tRFC port, we can see that the execution of the pipeline will take a little more than 1 minute.
In the third part of our blog series, we are going to look at the IDoc Listen and the IDoc Document Listen Snaps. We are also going to look at changing the status of an IDoc in the SAP system that we received via the listening snaps to accurately reflect its status once it has been processed by the SnapLogic process.
