cancel
Showing results for 
Search instead for 
Did you mean: 

SAP PI: ​Separate EO and EOIO scenarios for same idoc type?

oliver_stoll
Discoverer
0 Kudos

Dear community,

I am currently facing a challenge with the implementation of an SAP PI EOIO scenario with the Java idoc sender adapter (Idoc_AAE): There is an existing ICO where WMTORD idocs are sent from a SAP system (let's call the related business system ECC) to SAP PI and delivered to different non-SAP receiver systems. The idoc sender channel in this ICO is configured with QoS (quality of service) "Exactly Once" (EO). Now there is the requirement to send the same WMTORD idoc type to an additional receiver system, but with QoS "Exactly Once In Order" (EOIO).

My current understanding is that 2 separate idoc sender channels will be needed (one with QoS EO, one with QoS EOIO) which also means that 2 separate ICOs will be needed. Since the same idoc type must be used as sender interface in both ICOs, I created a new business component ECC_EOIO which is supposed to be used as the sender system in the EOIO ICO. For this business component ECC_EOIO I created an EOIO idoc sender channel (manual configuration with a different program id than in the EO idoc sender channel), and I changed the ECC partner profile so that idocs for the new receiver system are sent to a new destination with the same program id (different from the default program id XI_IDOC_DEFAULT_DESTINATION_ECC which is used for the EO scenario). Also the inboundRA Resource Adapter in NWA was copied and modified in order to make this approach work.

Connectivity tests look good (the new destination can successfully be pinged from ECC and the new EOIO sender channel can successfully be pinged from PI). However, when test idocs are sent from ECC to the new destination, they successfully arrive in PI, but they are still processed by the EO idoc sender channel instead of the new EOIO idoc sender channel. I am now confused because I expected that the program id in EOIO idoc sender channel acts as a "link" to the corresponding ECC target destination. Any hints what might be missing in order to get the idocs processed by the EOIO idoc sender channel (or different ideas how to deal with the above requirement) are highly appreciated.


Kind Regards
Oliver

Accepted Solutions (1)

Accepted Solutions (1)

Hi Oliver!

I guess that IDoc control record contains the same info about Sender system/Interface in both cases. So the appropriate sender channel is set. No matter, which inbound resource adapter is used.

I would try to use parties mechanism. But it's worth mention that inbound IDocs should have sender partner of type KU or LI in order to implement it.

Regards, Evgeniy.

oliver_stoll
Discoverer

Hi Evgeniy,

thanks for your reply. Indeed the sender information in the idoc control header (IDOCTYP, MESTYP, SNDPOR, SNDPRN, SNDPRT) is the same for all connected partners. Only the receiver ports (RCVPOR) and receiver partners (RCVPRN) are different. So if the sender partner information in the idoc control header is validated by the idoc sender adapter and must match the PI business system name, this would be a reasonable explanation why my approach did not work as expected. I remembered that the approach to use different sender SAP business system names worked fine in case of RFC sender channels where different program ids could control which ICO should be used to process incoming RFC requests. But obviously it does not seem to be that simple in case of idoc communication. Anyway, I assume your assumption is correct, so I will now discuss some alternative approaches with my SAP colleagues. Thanks again for your feedback!

Answers (0)