cancel
Showing results for 
Search instead for 
Did you mean: 

Dymanic Queue EOIO for IDoc to SOAP

nikhil_bose
Active Contributor

Hi Experts,

I've to develop an integration scenario to send Outbound IDocs to Web Service in sequence. The problem is when one IDoc fails, the entire Queue processing is stopped. The scenario has to be tweaked to process the IDocs with same document number / identifier must be in separate Queue so that if a particular IDoc fails in the sequence (with same number) would not affect the other IDocs (with different document numbers).

There are many threads discussed similar problem with custom adapter module to dynamically generate the Queue name as solution. I'm looking forward for your expert advise on going forward with the custom adapter module development and/or any out-of-the-box feature available in SAP PO 7.4 SP 10.

Looking forward for your valuable inputs!

Regards,

Nikhil Bose

Accepted Solutions (1)

Accepted Solutions (1)

vadimklimov
Active Contributor

Hello Nikhil,

Java IDoc adapter in release 7.4 supports dynamic queue name determination - it actually recognizes queue name of a received IDoc and re-uses it when assigning serialization context for corresponding processed PI message. Having this in mind, please:

  1. In sender system which is producing IDocs, enable IDoc serialization and create queue names based on document number. For example, in SAP ABAP systems, enable queue processing for respective message type in partner profile (tx. WE20) and specify queue rule name that generates queue name following required logic - based on document number (tx. WE85). Queue name generation shall be implemented in a function module (assigned to a queue rule name in tx. WE85) - there, you can retrieve document number from the processed IDoc and use it when forming a queue name. More details can be found at Queue Name Rules - IDoc Interface/ALE - SAP Library;
  2. In Java IDoc sender communication channel, enable EOIO mode. You will need to provide a fixed queue name in channel configuration after you enable EOIO mode, but in PI/PO 7.31 / 7.4 this queue name is overwritten by queue name of the received IDoc (the one set by a sender system when processing the IDoc).

Regards,

Vadim

nikhil_bose
Active Contributor
0 Kudos

Hi Vadim,

Thanks for the response!

I've simulated exactly the same steps 1 & 2. The queue name is generated in ECC however the queue name is overwritten by queue name that is specified in the Sender IDoc channel. Is there any settings that to be configured additionally in SAP PI?

Thanks,

Nikhil Bose

vadimklimov
Active Contributor
0 Kudos

Hi Nikhil,

Can you collect a trace of a Java IDoc sender adapter (e.g. using XPI Inspector) - special attention shall be paid to trace entries for log location com.sap.aii.af.idoc.inbound.IDocInboundProcessor (corresponding class of an IDoc adapter implements logic for sequence ID determination for a produced XI message from a processed inbound IDoc)? Original RFC queue name used to be overwritten by a queue name specified in Java IDoc sender communication channel in release 7.3 (that was one of limitations of Java IDoc adapter in 7.3), but not in 7.31 and newer releases: in newer releases, RFC queue name of an incoming IDoc is used to determine a sequence ID and serialization context, and only if it cannot be found, queue name from communication channel configuration is applied. There should be no more additional configuration in standard Java IDoc adapter apart from enabling EOIO and dummy queue name in sender communication channel configuration (assuming it is assured that a sender system produced an RFC queue name when sending an IDoc - which you can get, for example, from details of status 03 for corresponding processed outbound IDoc in tx. WE02 / WE05 / BD87 in a sender system: 1st parameter of this status details indicates generated queue name).

Regards,

Vadim

nikhil_bose
Active Contributor

Important addition:

Along with the specified steps, in Port Maintenance WE21, select 'Queue processing is supported'. This works fine!

Thank you Vadim!

Regards,

Nikhil Bose

Answers (0)