IDoc error handling from external integration tools
I worked on several Manufacturing Integration Projects for more than 10 years. Most of the cases I involved in fresh implementations. Nowadays started working with pre-implemented projects and started facing some issues which I have never faced before.
It is a well-known fact that integration projects’ defect handling part is the most difficult part to handle. Sometimes the tools are so technical in nature that we struggle to provide a non-technical troubleshooting solution for the functional experts and end users.
Some of us are lucky that we are working integration with SAP.
However, I found that we do not use all the error handlings which SAP provided.
In this document, I am going to explain the trick I do to help the end user to troubleshoot a problem of IDoc integration.
I work with PI and SAP-MII. So, I have defined some rules when I design the interface.
Most of my integration scenarios, PI is the 1st point of integration tool accepts the IDoc from SAP. I also worked where PI is replaced with another integration tool called IWAY.
So, I defined the statuses for the 1st level integration processing are as follows:
Rule 1: 39 IDoc is in the target system (ALE service) — This status is saying the IDoc is transferred by PI/IWAY to the target system.
Now the user knows that PI/IWAY has done their job successfully.
Once the message is transferred to the 2nd level integration tool, the IDoc is now close to the application layer. For me SAP-MII is the 2nd level tool.
If the IDoc processing is successful then set
41 Application document created in target system
If there is an error then set the status as
40 Application document not created in target system
This helps the SAP users to know which team to contact for any failure. Also if the status message is more descriptive then the user can also find out whether the issue can be resolved in SAP or in PI/IWAY or in MII.
Example: As per the example below IDOC status screenshot, the user can see that the IDoc got processed to PI with status 03 and then PI processed the IDoc to the destination system (status 39) and we see there is a success message (41 ) and then two error statuses (40).
** I forced the failure of the message in MII to make create the screenshot.
When we look into the detail at the failure message we see the reason of the failure.
This is what makes my SAP users feel comfortable about the solution I design.
We talked about all the theoretical scopes of the implementation above. Now we need to write the code to make this happen.
It is easy, you need to call the RFC enabled function module of SAP.
Tables –> IDOCS_STATUS_RECORDS_INPUT
DOCNUM <IDOC Number>
STACOD <3 char code><rest of the characters are ID – I use system name or information>
STATXT <Success or failure message>
STATYP <Type of system error message (A, W, E, S, I)>
APPL_LOG <Any extra log text>
This RFC is an auto-commit RFC. Once the call is over you see the information in the IDoc status. This implementation approach always made my end users comfortable to do the troubleshooting.
you can also use an external solution such as SolMan, EDIMON or IZAP to get quick result.
You can send mail and start reactions to solve the errors automatically.