Skip to Content

Background


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


Implementation


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

Repository


Interfaces


  • 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

Directory


Services


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


Changes


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.

5 Comments

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

  1. Former Member
    Hi,

    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.

    Rgds
    R Chandrasekhar

    (0) 
    1. Former Member 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.

      Regards,
      Udo

      (0) 
      1. Former Member
        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.

        (0) 
        1. Former Member 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

          Regards,
          Udo

          (0) 

Leave a Reply