Skip to Content


XI has no standard way to give sereral IB Directory Services the same logical system name.
That seems to be natural but there are some cases where you would like to change that.

The theme is about any Idoc what has to be send to a third party system. In our case it should be a Oracle database, which is
connected over JDBC receiver adapter. A stored procedure can send back an acknowledgement, to switch the
status of original IDoc.

Acknowledgement send by Stored Procedure

The Acknowledgement can only be send back if the database is succesful connected. In any case of errors the
IDoc status will remain at ’03’ (green). The handicap it now a bad R/3 monitoring, searching for errors is difficult
and a message recovering quite complex.

To avoid this a Business Process can catch the exceptions and control the
acknowledgements.It receives the IDoc message, sends a request to the third party system and pushes finally a success
acknowledgement back to R/3. In case of any exception an error acknowledgement will be produced.

Acknowledgement send by Business Process

This design guarantees an acceptable error monitoring at R/3 (red flag at WE02), the responsibility for sending
acknowledgements is now as much as possible close to R/3 system and there is a global mechanism for notice errors.

In the view of XI it would be now neccessary to setup Partner Profile inside the R/3 for every Business Process,
which is sending back IDoc ALEAUD, because u have to give every Business Process a different logical system name.

A solution for that can be, to rout the message not to IDoc adapter / SAP than to the HTTP adapter / XI, where
it’s in a second step routed to R/3. Less performance is not to be expected because of using native HTTP adapter and because
there is no additional mapping.

Acknowledgement send first to HTTP


This is a short instruction. You need some experience to realize it.



  • ALEAUD_abs_asy: abstract asynchronous of ALEAUD type
  • IDOC_abs_asy: abstract asynchronous of IDoc type (the original sent IDoc)
  • REQ_abs_asy: abstract asynchronous of type Request (to Database)
  • RESP_abs_asy: abstract asynchronous of type Response (from Database)
  • MI_abs_syn: abstract synchronous of types for Request and Response
  • MI_inb_syn: inbound sychnronous of types for Request and Response
  • ALEAUD_out_asy: outbound asynchronous of a simple type (one field string)

Interface Mappings

  1. IDoc_2_Request: source: IDOC_abs_asy, target: REQ_abs_asy, filling the request message to database
  2. IDoc_2_ALEAUD_succ: source: IDOC_abs_asy, target: ALEAUD_abs_asy, filling ALEAUD in case of success
  3. IDoc_2_ALEAUD_err: IDOC_abs_asy, target: ALEAUD_abs_asy, filling ALEAUD in case of error

Filling of ALEAUD fields

    1. E1ADHDR/MESTYP: original message type
    2. E1ADHDR/E1STATE/DOCNUM: original IDoc number
    3. E1ADHDR/E1STATE/STATUS: 68 in case of error, 53 in case of success
    4. E1ADHDR/E1STATE/STATXT: Short description for R/3 user what has happend

Business Process Container

  1. ALEAUD type ALEAUD_abs_asy
  2. IDOC type IDOC_abs_asy
  3. REQUEST type REQ_abs_asy
  4. RESPONSE type RESP_abs_asy

Business Process Steps

Integration Process in Repository

1.) Receive: Message: IDOC, Mode: Asynchronous

2.) Block: Mode: Default, Exceptions: noInsert, stopProcess

   3.) Exception Branch: Exception Handler: stopProcess

      4.) Control: Action: Cancel Process

   5.) Exception Branch: Exception Handler: noInsert

      6.) Transformation: IF Mapping: IDoc_2_ALEAUD_err, Exception: stopProcess, Source: IDOC, Target: ALEAUD

   7.) Transformation: IDoc_2_Request, Exception: noInsert, Source: IDOC, Target: REQUEST

   8.) Send: Mode: Synchronous, Synchr Interface: MI_abs_syn, Request Message: REQUEST, Response Message: RESPONSE, Exception: noInsert

   9.) Switch: Condition: //insert_count not equal 0

      10.) Transformation (Branch1): IF Mapping: IDoc_2_ALEAUD_succ, Source: IDOC, Target: ALEAUD

      11.) Transformation (BranchOtherwise): IF Mapping: IDoc_2_ALEAUD_err, Source: IDOC, Target: ALEAUD

12. Send: Mode: Asynchronous, Message: ALEAUD



Receiver Determinations

Interface Determinations

Receiver Agreements

Sender Service Receiver Service Receiver Interfaces Namespace Communication Channel
XI_SYS SAP_SYS Repository-loaded ALEAUD urn:sap-com:document:sap:idoc:messages IDOC_Receive_Channel
* THIRD_P * * JDBC_Receiver_Channel
STATUS_HDL XI_SYS Repository-loaded ALEAUD urn:sap-com:document:sap:idoc:messages HTTP_Receive_Channel


Since SP 14 there is an easier way without routing over HTTP adapter. From SAP Library – Changes:  “IDoc Adapter / It is now possible to get the sender and receiver of a message from the payload.”

To report this post you need to login first.


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

  1. Chandrasekhar Radhakrishnan

    Can we not just make use of the Header Mapping within the Receiver Agreement to change the Sender as “XI_SYS”? This way we don’t have to actually pass the message through the XI HTTP adapters. We can send the data directly from BPM to R/3 via the IDOC adapter.

    Let me know if I am missing here something.

    R Chandrasekhar

    1. Udo Martens Post author
      Hi Chandrasekhar,

      you will get an error message trying to change more than one Sender to “XI_SYS”. But if more than one processes are sending ALEAUDs you just would like to have the same name to avoid setup of Partner Profiles in R/3 for each ALEAUD.


      1. Chandrasekhar Radhakrishnan
        Hi Uno,

        I am not sure why we would get the error.

        Correct me if I am wrong:
        Say I have two different BPMs STATUS_HLD and STATUS_ABC. I can have two Receiver Agreements – One with STATUS_HLD and other with STATUS_ABC as the Sender service. Both use the same Receiver interface as ALEAUD and same IDOC comm channel. In both I can have the Header mapping such that the sender service is XI_SYS. I did not get an error when I activated these objects.

        Is this not sufficient to pass the same “XI_SYS” service for the ALEAUD, irrespective of which BPM sends it? And then we need to have only one partner relation in R/3 to accept the IDOC under the Logical system name of XI_SYS.

        1. Udo Martens Post author
          Hi Chandrasekhar,

          this blog is the result of a real task, so i tested the possibilities as much as possible. The header field mapping doesn’t work for the sender partner number (SNDPRN) if the partner type (SNDPRT) should be ‘LS’. Instead of header field mapping you can configure that over “adapter specific identifiers” of the business system, but THIS allows only new names.

          There was a interesting discussion about that problem in the XI forum: Headerfield Mapping



Leave a Reply