Issue with collecting IDocs PI 7.3

[tom_wall]

Hello gurus,

We have a scenario where the same IDoc type is either collected or transferred immediately depending on the partner type.  The process works in our test environment, but not in production. I both test and prod, the transfer immediate is good.

Environment:  PI 7.3. Single Stack.  Test is a single server. Production has multiple servers.

Partner profile: outbound IDoc.  For a LS partner, the partner profile is set to Transfer Immediately.  For a KU, the partner profile is set to collect.   Pack size is set to 1000 in both test and prod.

RSEOUT00 releases the collected IDocs correctly and one single message flows to PI.

In PI configuration, we have two communication channels.  One is set to "Multiple IDocs in Single XI Message".   The other is not.  Each of these feeds into a unique Integrated Configuration.  Both have the same Sender.  NON-collected Integrated Configuration does not use the virtual receiver.  The Collected IDocs us the virtual receiver and the Receiver Communication Party is *.

In test, we see this in the message log for the successful collected message:

Sender Party:  Sender Service:RQ1_500 Receiver Party:0000008095 Receiver Service:  Communication Channel:CollectIDOCSenderChannel

in Prod, we see this in the message log for the message that are going to the incorrect Integrated Configuration:

Sender Party:  Sender Service:RP1_500 Receiver Party:  Receiver Service:  Communication Channel:DefaultIDOCSenderChannel

So the obvious difference is that the Receiver Party is not populating in Production.  I believe that if we have that, our process will work as expected. What can I do to pass this value correctly?

The only other difference we can find is that in the PI settings, the InboundRA has a parameter of Local = true in test and Local = false in Prod. This was changed due to having multiple servers in prod.

Thanks!

Tom

[tom_wall · Accepted solution]

Hi Eng Swee,

QA Header

Prod Header

Prod Partner Profile

We are not using 8095 anywhere as party.

I attempted to create an ICO with 0000008095.   Numeric values are not permitted.

Thanks!

Tom

[engswee · Accepted solution]

Hi Tom,

The screenshot really helps.

It looks like something is missing in your Production system that is in your Test system.

For the virtual receiver on the ICO part, it needs an actual Party object in the system, instead of entering any value directly.

It looks like there is a Party object in your Test system's with the name 0000008095. If you open that object in your Test system, it should contain additional values in it's Identifier:

Agency = RQ1_500

Scheme = ALE#KU

Name = 0000008095

Refer to my reply in the following thread for a screenshot of how it would roughly look like.

Re: Separate ICo for different receivers with same sender  and same IDOC type

You need to have the same object in your Production system with the following values:-

Agency = RP1_500

Scheme = ALE#KU

Name = 0000008095

Once you have this Party object created, assigned it in the virtual receiver of the ICO - try using the search help to locate the party and assign it instead of typing the value directly.

The key thing is to refer to your Test system objects and config since it is already working fine there.

Rgds

Eng Swee

[engswee · Accepted solution]

Tom

Additionally, can you post Production screenshot of the Main section similar to what I have posted in my previous reply? Follow the steps shown below to retrieve it.

Rgds

Eng Swee

[tom_wall · Accepted solution]

Hi Eng Swee,

Your responses pointed us in the right direction.   With the information you provided about the receiver partner,  we found SAP note 1941832.  http://service.sap.com/sap/support/notes/1941832

In QA, the property ResolveVirtualReceiver was set to true in NWA > Application Resources > Select JavaIdocAdapter.    In Production this was false.   We have changed the setting in prod and now the process works.

Thanks!

Tom

[engswee · Accepted solution]

Excellent! Real glad to hear that it works now.

Thanks also for sharing the final resolution, Tom. My pointers were based on my previous experience on the IDoc adapter on dual stack. I didn't know it is also possible that no matching party is found and the partner number is set as the receiver - so I've learned something new myself Thanks!

[tom_wall]

Eng Swee,

The partner profile in each system is identical except for the receiver port.   In test, we the port is our QA PI system.   In prod, we point to the PRD PI system.

Please respond with any suggestions.

Thanks!

Tom

[engswee]

Hi Tom

Can you provide a screenshot of the following?

- Main section of SOAP Header for messages in both QA and Prod

- Partner profile for Prod

Can you also check if there is a Party in Prod that has partner no 8095 in it's identifier?

Can you also try to create an ICO that uses the specific Party as a virtual receiver instead of *?

Rgds

Eng Swee

[engswee]

Hi Tom

Can you check and compare the Main section of the SOAP Header at the first point when the IDoc message enters the PI system? If you do not have the version at the first point, then please set logging for Message Preparation (BI step).

When you compare this part, can you check what are the values (if any) populated for the Receiver section?

Since you are using KU partner profile, the IDoc adapter should automatically translate it to a valid receiver party that has the partner number as it's identifier. Once the receiver party is determined, it will check for a corresponding ICO which has that value in virtual receiver field.

If you don't see any receiver party value, then either IDoc partner profile in sender system is set up incorrectly, or there is no matching party in PI with an identifier that matches the partner number.

Rgds

Eng Swee

[tom_wall]

Eng Swee,

Thank you for the reply.  The receiver party is not being populated.  We are using * as the receiver party in the configuration.  I will now look at the partner profile in the sending system.

Thanks!

Tom