Contents

  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):

Mandatory
IDOC type                              <IDOCTYP>DELVRY05</IDOCTYP>
IDOC extension(if used)       
<CIMTYP></CIMTYP>
Message type                         
<MESTYP>DELINS</MESTYP>
Sender partner number          
<SNDPRN>SENDER</SNDPRN>
Receiver partner number       
<RCVPRN>RECEIVER_CLNT100</RCVPRN>

Optional
Message variant                                     <MESCOD>XML</MESCOD>
Message function                                  
<MESFCT>EDI</MESFCT>
TransID/filename from Sender system 
<REFINT>SAP000001.xml</REFINT>

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

<DOCNUM>1</DOCNUM>

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.


Example:


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).

Example:


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.
To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. 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.

    cheers

    m./

    (0) 
  2. Timo Klein

    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

    Timo

    (0) 
    1. Martin Dejl 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 😉

      Cheers!

      Martin

      (0) 

Leave a Reply