One Logical System Name for serveral BPM Acknowledgements

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.

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.

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.

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

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

Filling of ALEAUD fields

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

Business Process Container

2. ALEAUD type ALEAUD_abs_asy
4. IDOC type IDOC_abs_asy
6. REQUEST type REQ_abs_asy
8. RESPONSE type RESP_abs_asy

Business Process Steps

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

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