Prinicpal Propdagation for IDOC Receiver Adapter

[Former Member]

Hi

I know principal propagation is not possible for IDOC Receiver Adapter.

Is there a way to pass user id from SAP PI to ECC to process IDOCs using the same user? Please advice any alternate mechanism available. Appreciated in advance

[former_member200962 · Accepted solution]

Is there a way to pass user id from SAP PI to ECC to process IDOCs using the same user

In one of his blogs Michal mentioned the use of Pseudo-Principal Propagation, wherin user-details were passed to an RFC (one of the restrictions was receiver system should be SAP)....if there is some workaround then it could be the above procedure...though I am doubtful about it!

Regards,

Abhishek.

[Former Member]

Thanks for the suggestion.

The pseudo option only works with batch processing for RFC or Proxy etc... And it doesn't seem like an option for Inbound IDoc's. We are on the latest PI 7.1 We can enable Principal Propagation with out going to pseudo route.

I am thinking of having multiple RFC destination in the system, so that the user gets populated based on destination we use in the IDoc receiver adapter. I hope this is not the best option.

If there is any other alternative, i would like to give it a try

[former_member200962]

And it doesn't seem like an option for Inbound IDoc's

Yes, thats why i mentioned it is doubtful.....normal procedure to configure PP for IDOC is not possible....and even the pseudo-PP will not fit into it.... as of now there is no option (or even workaround) to propagate user from source to target for IDOC scenarios.

However, if the business allows you can make use of PROXY/ RFC .... in case it is mandatory to pass user-details from source to target.

Regards,

Abhishek.

[Former Member]

As I mentioned, multiple RFC Destination would solve the problem.

Jin Shin also help me to understand, where there are no other solutions available. Here is the information Jin suggested

"As far as I know, there isnu2019t a way to propagate the user from PI to ECC using IDoc connectivity. I conferred with some colleagues and one suggested that you might instead create multiple logical RFC destinations (type L) that each hold the user logon for each message type/partner and have one of the normal RFC destinations (type 3) that contains the system connection data. Each of the type L connections would refer to the lone type 3 connection. That way, at least you would only have to maintain the user logon data and not all the physical connection info for each one (e.g. server/ip, port, balancing, tracing, aRFC behavior, tRFC behavior, conversions, basic logon data, etc.). Overall less maintenance though you still have to create multiple RFC destinations."