Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
udo_martens
Active Contributor
0 Kudos

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



  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






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 ServiceReceiver ServiceReceiver InterfacesNamespaceCommunication Channel
XI_SYSSAP_SYSRepository-loaded ALEAUDurn:sap-com:document:sap:idoc:messagesIDOC_Receive_Channel
*THIRD_P**JDBC_Receiver_Channel
STATUS_HDLXI_SYSRepository-loaded ALEAUDurn:sap-com:document:sap:idoc:messagesHTTP_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."
5 Comments