Can IDOCs reach status 12 when using XML-HTTP port?

[r_herrmann]

Background:
When sending IDOCs from SAP ECC via RFC port, they first will get status 03 when they are dispatched to the port. Nevertheless delivery could still fail (they could hang in SM58). If they are finally delivered to the target, the status will switch to 12 (by use of the transaction BD75 or the program "RBDMOIND") as explained in this blog by vadim.klimov.

Questions:

When using an "XML-HTTP" port (instead of RFC) in WE21 and sending out IDOCs to the target via a HTTP destination, the IDOCs stay in status 03 (even if they were successfully sent out and reached the partner).

• Is there an equivalent to the BD75/RBDMOIND when using XML-HTTP that moves the status from 03 to 12?
• Is there a transaction to monitor the HTTP requests that are made when sending out the IDocs from SAP ECC via HTTP? (I'm thinking of something similiar to SRT_MONI, SXMB_MONI ... only for IDocs that are send via HTTP.)

[malteschluenzkc · Accepted solution]

Hi @r_herrman,

there is a possibility to send from the receiving system an SYSTAT iDoc back to the sender system. Within this iDoc you can set the status to number 12 (and more details, like SAP CPI message id, ...)

We have set up an iFlow managing this. On my todo list is to write a blog article about that. Maybe I should prioritize that...

Best regards,
Malte

[r_herrmann · Accepted solution]

Hi Malte,

this sounds pretty interesting looking forward to your blog! 🙂

[malteschluenzkc · Accepted solution]

Hi Raffael,

and here is the blog article: https://blogs.sap.com/2020/09/15/update-the-delivery-status-of-idocs-sent-from-sap-cpi-pi-in-sap-bac...

In case of any questions, feel free to reach out to me! 🙂

Best regards,
Malte

[engswee]

Hi Raffael,

I'm interested to know what's the reason for having the those IDoc status set to 12. Do you specifically need them to be in status 12 to indicate successful sending of the IDoc, or do you just want to be sure that the sending was successful?

If it's the latter, then the status of the IDoc at status 03 should be sufficient. Because it is using an XML-HTTP port which behaves synchronously, if the message processing fails in the CPI IFlow, the error is returned back and the IDoc would be in status 02.

If your reason is the former (for whatever reason that you want/need status 12), then according to Vadim's blog, the approach is only applicable for non-RFC port types. My assumption for the difference in behaviour is because the IDoc is transmitted asynchronously on a tRFC port, while synchronously on an XML-HTTP port.