PI 7.4 Single Stack IDOC Adapter - how to see payload after mapping

[Former Member]

Hello experts,

We have been migrating from dual stack PI 7.11 to single stack PI 7.4.

One thing I miss about SXMB_MONI is that we could see the payloads before and after mapping.

I cannot find a way to do this in the new IDoc Adapter Monitor in NWA Message Monitoring.

I can get to the point of finding my particular message, it says the outbound IDOC number in the Details section. Then below it we have 3 tabs for Acknowledgment, IDoc Message Details, and Control Record.

From here I see a link to my MessageID which takes me to the source payload before mapping. I want to see the payload after the mapping step. Any ideas?

Extra info about why I care to see this:

We are troubleshooting an issue where the real world outgoing IDOC is dropping some fields which map correctly in the testing mode.

We fear it has to do with IDOC Metadata Repositories having the same short SID name. We have a name conflict in our landscape and although these communication components have different names, it seems the Metadata is based on the SID name only. So maybe in our case when our message through mapping to IDOC then gets handed off to the Meta Data Repository, it is getting an IDOC version which doesn't have the fields we need. If this is true it will be a  big problem for us because I don't know how we will control the conflicting Metadata (changing SID on our system is not an option).

This is really a bigger potential issue but for now I would just like to find a way to see the payload after the mapping step with Sintgle Stack PI.

Thanks very much,

Aaron

[Former Member · Accepted solution]

Hi Aaron,

NWA settings are global whereas you can have those settings at the scenario level in ICO (Advanced settings),Where you can configure logging and staging of each stage in the pipeline. It is not recommended to use these setting in production for very obvious reasons.

I hope you wont miss dual stack as much now...

Regards,

Mudassir

[Former Member · Accepted solution]

Ok Mudassir, that is good to know we can reduce the logging when we are only interested in once scenario. Thanks!

I'm starting to let go of the old ways now...  takes time for the old dog to learn new tricks.

-Aaron

[nidhi_srivastava22]

Hi Aaron,

You can set the XPI stagging and logging parameter in NWA, as suggested by Praveen.

Also, I have used the MessageLoggerBean Module as shown in the below screenshot. After this I can see different version of messages.

Thanks,

Nidhi

[Former Member]

Never heard of that bean before, that is so cool, thanks for the tip!

[vadimklimov]

Hello Aaron,

If you are unsure about which IDoc metadata is used by the IDoc adapter, you may have a look into IDoc Metadata Monitor (PIMON: Monitoring > Adapter Engine > IDoc Adapter Monitor > tab "Metadata Monitor") and check uploaded metadata structure for the specific IDoc type in question. For each cached IDoc metadata entry, you can see which backend system was used as a repository (from which system structure was uploaded) and check cached metadata elements (data segments and their structure):

Please note that IDoc metadata is cached per node, so you can check if it is consistent across all nodes as well.

if you find inconsistency between cached metadata in PO and actual IDoc structure in backend system, you can try to reload IDoc metadata or delete and preload it again in IDoc Monitor.

Enabling logging after mapping is helpful when you want to check produced target message, but IDoc structure that is used in target structure may not always be identical to the one contained in IDoc metadata (even though ideally they should be same, in reality, this is not always the case - for example, if IDoc structure was changed, but wasn't re-imported in ESR and mapping was not adjusted, but new IDoc structure / metadata has been cached by IDoc adapter). So for the described issue, I would suggest firstly checking IDoc metadata since that one is used by IDoc adapter when converting XI message into IDoc list and transmitting it to the receiver system.

By the way, if you only want to enable logging after mapping for only specific interface, you may think of using interface-specific logging configuration (done in Integrated Configuration object, tab "Advanced Settings") rather than enabling additional logging steps globally in Advanced Adapter Engine for all interfaces. Refer to the already mentioned blog for more details.

Regards,

Vadim

[Former Member]

Hi Vadim,

This Metadata monitor is exactly where we were investigating and found that the Repository ID given to the backend is just the SID of the SAP system. In our case we need more detail because we have two SIDs with the exact same 3 characters. So we have a workaround in unique Component, Port, and Comm channel names. However we didn't know that the new PI system would combine our metadata like this under the Repository ID of just the short SID name.

Do you know any ways to manipulate this Repository ID name?

[vadimklimov]

Aaron,

In configuration of an IDoc receiver communication channel, you can explicitly specify which backend system shall be used as a repository of IDoc metadata - e.g. referring to an RFC destination maintained in NWA using default mode (recommended), or specifying connection parameters to it right in communication channel configuration using manual mode:

Please also ensure that IDoc definition that you imported in ESR and used as a target message type, corresponds to IDoc type definition in the system to which IDocs of these type are to be sent from PI.

Regards,

Vadim

[former_member182412]

Hi Aaron,

You need to set below parameter, check below blog for more details.

Regards,

Praveen.

[Former Member]

Hi Praveen,

Thanks for this advice, I don't know how I would have found this setting! I'll try it tomorrow and let you know.

[former_member186851]

Hello Aaron,

Select the open message option and there you can see various logging of messages.I mean after every step.

[Former Member]

Hi Raghuraman,

This only shows Version 0 of the message which has the original source payload.

I think reading the other suggestions my system is not configured to log the multiple versions yet.

Thanks for the idea!

Aaron

[former_member186851]

Hello Aaron,

Ya...Just configure as per Praveen's Idea and check.

Guess it will work, because I am able to see multiple versions in my system.

[vadimklimov]

Be cautious when enabling additional logging globally in Advanced Adapter Engine (as suggestion from Praveen implies). Additional staging and logging brings performance impact both on application server and database, especially in highly loaded PI systems (refer to PI/PO Performance Guide at , section "Logging / Staging on the AAE", and a SAP Note 1760915, Q6 and Q7). If it is necessary to enable logging after mapping only for few interfaces which are in question, it is not recommended to globally change logging settings in Advanced Adapter Engine by changing XPI Adapter: XI service properties, but makes sense to customize logging on the level of specific interfaces, in corresponding Integrated Configuration objects. Having minor impact in systems with low workload, it is really noticeable when being implemented in large scale PI installations with high processing throughput and workload.

Regards,

Vadim