Skip to Content
Author's profile photo Martin Dejl

XML IDOC in SAP ECC without middleware and RFC


  1. Requirement
  2. Prerequisites.
  3. Solution.

     3.1.      SAP ECC inbound direction (interfacing system sends the XML IDOC to SAP ECC).

     3.2.      SAP ECC outbound direction (SAP as HTTP client sends the XML IDOC to partner system on HTTP service URL).

1.    Requirement

You need to exchange xml IDOC messages between SAP ECC and any other system supporting HTTP without middleware.

2.    Prerequisites

  • Proper version of SAP ECC. More in SAP note 1487606:
    “If the services “/sap/bc/IDoc_XML” (as of Release 6.20) or “/sap/bc/srt/IDoc” (as of Release 6.40) are activated in transaction SICF, you can send IDocs to the SAP system and process them if the user that you use has the relevant authorizations.”
  • To send XML IDOC’s to SAP, the partner system must be able of HTTP plain client communication or additional HTTP plain client is to be implemented.
  • To receive XML IDOC’s from SAP, the partner system must be able of HTTP plain server communication or additional HTTP service needs to be implemented.
  • Mapping from/to third party formats must be done on the partner system.
  • In case of SAP inbound interfaces, specific fields of EDI_DC40 IDOC header segment must be mapped specifically for the receiving SAP client system.

3.    Solution

First of all the requirements must be met. The SAP ECC version is essential. Earlier versions of SAP ECC do not contain services to provide server side HTTP connectivity for IDOC receiving.

3.1. SAP ECC inbound direction (interfacing system sends the XML IDOC to SAP ECC).

Open transaction SICF and find service:

Activate it:

And test it:

Browser should open with such information:

Copy URL from the browser. The URL is to be used in sender system HTTP client. For purpose of this how-to I use SOAP UI tool. It has to be set, as the client to pre-emptively authentication:
in global parameters

or in request parameters

This is very important settings to have in the HTTP client. In case the message is larger than minimal size of TCP packet it’s being split and only first packet gets the authentication. SAP rejects in that case the others. In case of using the pre-emptive authentication, SAP accepts all packets.

Media type of the message should be ‘text/xml’.

The RAW data of such request will look like this:

If successful there will be HTML response message sent back:

IDOC will be created in SAP:

In this how-to I use dummy partners so IDOC is not being processed but fails on partner profile identification. To have IDOC properly processed it’s necessary to have correctly filled EDI_DC40 segment(s):

IDOC type                              <IDOCTYP>DELVRY05</IDOCTYP>
IDOC extension(if used)       
Message type                         
Sender partner number          
Receiver partner number       

Message variant                                     <MESCOD>XML</MESCOD>
Message function                                  
TransID/filename from Sender system 

Logical grouping of messages<REFGRP>Warehouse1</REFGRP>

It is very important to implement internal numeric counter of IDOC’s sent from client. The number in


has to increase with each new IDOC message sent to SAP ECC via HTTP. It won’t be used as real IDOC number but there is a check performed on the inbound side that prevents to process two equal transmissions (by checking the DOCNUM against intermediate SAP table…):

3.2. SAP ECC outbound direction (SAP as HTTP client sends the XML IDOC to partner system on HTTP service URL).

Create in transaction SM59 RFC destination that points to the given URL of HTTP service. For purpose of this how-to I’ve used the service of the SAP ECC itself. The URL can be anything HTTP URL valid but has to be accessible by SAP ECC.


Optional – user authentication

Perform connection test to check if RFC destination is correctly configured and SAP ECC can reach the endpoint URL:

The result 409 is actually positive test result. It means that connection was established and server just replied that there was no data to be processed.

Next step is to define outbound port pointing to the RFC destination. Open transaction WE21:

Last step is to define proper partner profile(s) for message types to be exchanged with the HTTP service. The port to be used is the one defined in previous step (e.g. XML_OUT).


Simple test can be performed from transaction WE19. In this example I’ve used existing IDOC 0000000000031006 and modified the EDIDC header fields:

Result is new inbound IDOC:

4. Disadvantages/risks(from my perspective)

  • No central point of monitoring
  • Possible performance issues with WEB AS Abap. That needs to be foreseen and prevented. Essential is to tune up the WEB AS server (SAP ECC) properly.
  • Mapping is fully handled by partner system. In case of third party EDI systems it might be advantage. Doubtful it may be in case of A2A interfacing. Every small change might be difficult and expensive to implement in the partner system (depends on use case).
  • WS-RM not possible with standard SAP handlers. Theoretically possible with additional development effort. Still, not out of box solution.
  • For SAP inbound interfacing is must to have counter functionality that will increase for each message the temporary DOCNUM. That is not always easy to provide in HTTP clients without additional development.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo abilash n
      abilash n

      Thanks Martin for Amazing blog.... Keep it up..

      Author's profile photo Martin Maruskin
      Martin Maruskin

      Thanks for sharing Martin! it is quick and easy solution for interfacing SAP system. As you spotted it is not very robust but it works.



      Author's profile photo Former Member
      Former Member

      Hi Martin,

      great article. I have one question regarding the IDoc DocNUM. Can this be set unique per external partner so that the partner can take care of the counter or is this globally unique in the SAP system (I assume second option) so that we need to take care of the counter?

      Do you have info?

      Thanks in advance


      Author's profile photo Martin Dejl
      Martin Dejl
      Blog Post Author

      Hi Timo,

      it is as you assume. External partner/system can set it's own counter. The number just needs to be unique per partner/port. That should be fine to make it work. To be sure, I'd recommend also to make few tests with different partner(and/or port) names. To see which combination needs to be unique(I guess it's SNDPRN + DOCNUM but it's some time already, I may be wrong).

      I did not try to debug the SAP webservice but this is what I observed: The XML IDOC has to contain unique DocNum to be accepted and transferred to SAP DB table(s). Then when being processed it gets new DocNum from the SAP internal counter. So the number you give it in the XML(the temporary DocNum) is not the same as the DocNum in the final IDOC.

      There must be some intermediate table used just for the XML port. If you find it, please share with us ūüėČ



      Author's profile photo Tom Meißner
      Tom Meißner

      Hi Martin,

      i have debuged the inbound process of an XML_IDOC and found the table for the docnum-check: SRRELROLES here SAP store the DOCNUM for all IDOCs.



      select single * from tednolinks into wa_tednolinks
      and ( MESTYP = l_edidc-mestyp
      or  MESTYP = '*' ).
      if sy-subrc <> 0.
          select single * from srrelroles
                   where objkey eq help_docnum
                   and   objtype eq 'IDOC'
                   and   logsys eq l_edidc-sndpor
                   and   roletype eq 'OUTIDOC'.
      *            transporting no-fileds.
          if sy-subrc eq 0.
            rc = 4.
      *   restore original received docnum
             xml_http_original_docnum = l_edi_dc40-docnum .

            exit. ---> This exit triggers the error message in the next step.



      Only the logical system makes a different, so for each partner you need a unique number.  A bit strange, that the coding checks for "OUTIDOC" instead of "INIDOC" 

      There is also an Note 505608 about "ALE: Reorganizing IDOCREL" .