Additional Blogs by Members
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

XML IDOC in SAP ECC without middleware and RFC

martin_dejl2
Participant
‎07-22-2014 11:22 AM

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.
7 Comments
Popular Blog Posts