XML Idocs Response – can we change it?

The idocs have a well grounded status system, with close integration to the standard structure of return messages from BAPIs. That's why there shouldn't be a problem to return them to the 3rd party partner right?

This story I should actually start from another topic, that also is not widely known and could actually save you a lot of time if you are developing idoc interface with a 3rd party that requires more than a xsd of idoc structure (generated from WE60), which is a WSDL to import. Thankfully there is actually a SAP Note for this one, which explains the process step by step – 3352948 (2).

Now that the 3rd party can send us the idocs in the structure we want we can discuss the response. Standard one for the ORDERS idoc looks as follows:

<ORDERS05Response xmlns="urn:sap-com:document:sap:idoc:soap:messages"
                  xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
	<IdocAssign>
		<TransferId>0000000000000007</TransferId>
		<DbId>0000000000047867</DbId>
	</IdocAssign>
</ORDERS05Response>

As we can see there is no much data here, with only idoc number making any sense. What’s more the only information I was able to find was as follows:

Note
If IDocs are sent using the SOAP protocol, a response is expected using export parameter ASSIGN (TRANSFER_ID, DB_ID) of function module IDOC_INBOUND_XML_SOAP_HTTP.

So why is it like this? The simple answer is that idoc by nature are asynchronous, this means they won’t return a full status or logs simply because there is nothing to return. What we get from the whole SOAP interface in the SAP is the idoc number after it was put in the queue. Of course it could be processed immediately, so why not wait for it? Why there is no such configuration.

Actually to answer this, since I found no possible enhancement points, user exits etc. in the IDOC_INBOUND_XML_SOAP_HTTP or in methods prior to this on my own I posted an OSS to the SAP to confirm my worries and the answer we got long story short is – “It might be a better to achieve the required functionality in a custom development”.

Since we are left with only the possibility of a custom solution. For this we can approach this topic in two ways.

• We enclose the idoc processing in a custom interface (SOAP or RFC FM) and post them from the ABAP code to the standard logic. Wait for the processing to be finished either by waiting while checking the status and act accordingly or by additionally further enhancing logic of the selected idoc processing to trigger the response generation.
• We can also scrap the data from the idoc to put it into the standard BAPI structures, that will do the same as the posted idoc while also being synchronous . This also allows us to skip the possible bottle necks on idoc processings, while having more control on when and how we can run our second logic. However this approach is more complicated, since the idoc structures are not compatible with BAPIs out of the box. The mapping needs to be done somewhere.
• We can do a bit of a mix of 1st and 2nd approach like mentioned by [3] or [4], however due to the fact it is treated like an idoc on entrance it shares its problems, which was not suitable for our solution. The benefit of this approach is mapping done by standard, so it is as close to the standard as you could get.

Additionally if you are using middleware like SIS the second approach is a bit easier, because if you import both the idoc structure and your bapi structure you can map it quite fast on standard blocs, without any need for additional code. This was what we did in the end.

If we didn’t have this middleware we would most likely pack the idoc xml in base64, and then parsing by xslt to two different structures in the SAP for both bapi and the second logic. This approach is already well document for example on the sap blog posts [5] – however if you want long story short its XSLT_TOOL + se11 and some ABAP.

Conclusion

Remember that idoc are asynchronous by default, so every scenario that requires posting them in a synchronous interface is a bit problematic. It is not possible unless you want to modify the standard to change the xml idoc processing response, so the only way is a custom solution.

Sources:

1. https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/4b/6bf4dfd1e841a8e10000000a421937/frameset.htm
2. 3352948 – ESI – How to generate a test WSDL file for the IDoc via SOAP service endpoint – SAP for Me
3. https://sites.google.com/site/ruslimchang/create-bapi-based-idoc
4. https://www.eckert-marco.de/2024/03/10/using-idocs-to-call-buisiness-object-bapi/
5. https://community.sap.com/t5/technology-blogs-by-members/step-by-step-procedure-to-process-complex-xml-having-deep-structure-header/ba-p/13294208