Skip to Content

PI/XI: Pseudo principal propagation

In standard principal propagation allows you to forward the user context of a message from the sender application via PI/XI to the receiver application. What does it mean in terms of middleware? In most A2A scenarios one application is linked to another with the use of a technical user like shown in this picture:


So basically it does not matter which user is logged on a sender application as the authorization in the receiver application will always be the same – as one technical user is used.

Principal propagation allows us to use the same user that is logged on a sender application in the receiver application like shown in this picture:

this can be achieved if you configure standard principal propagation:
Principal Propagation –
Note 974873 – Principal Propagation
and it works for XI (java, abap proxies), RFC and SOAP adapters.

What if you don’t have NW04 with SPS19 or NW04s with SPS10 so no possibility to configure principal propagation?
Is there any way to use the same user that is used to log on to PI in the receiver application? It turns out there is such a possibility with the use of batch input sessions. Let me show you a simple way on how this can be achieved in a typical SOAP to RFC scenario.

SOAP Adapter part

As you probably know we can quite easily get the username of a user which is used to send a message to a SOAP adapter with the use of Adapter Specific Message Attributes (ASMA). We just need to enable them in the SOAP sender adapter:


and then the user will be inside the dynamic configuration part of out PI message

Now we need to put this username inside our message in order to use in the RFC later on. Getting values from dynamic configuration of an XI message will not be a part of this blog as there are many other blogs which describe it in detail. The only important thing is to have the username inside our RFC message after the mapping so we can use it in the RFC.

RFC part

Inside our RFC we need to use a recorded batch input session which will be executed with the use of the user from the RFC message payload. In order to execute the batch input session we will start function BDC_OPEN_GROUP where in the USER field we can put the username used in SOAP sender adapter. 

              CLIENT   = SY-MANDT
              GROUP    = ‘TEST’
              USER     = SOAPuser
              KEEP     = ‘X’
              HOLDDATE = ‘20090101’.
              TCODE     = ‘VA01’
              DYNPROTAB = BDCDATA.


*we also need to execute this batch input session:

and return.


And what will happen is that transaction VA01 (sales order creation) will be executed with all authorizations of SOAPuser.

Since this is a pseudo principal propagation is has a few differencies then the standard one and many drawbacks like:

– the only way to do it is by using a batch input session
– the SOAPuser is not used for logging into the receiver system (still the technical system is used)
– it only works if the receiver is an SAP system

On the other hand in my opinion is as save as it gets as you still have the technical user inside the PI – Receiver connection with password and in according to this you can check the authorization with the real user which was logged on the sender application. Also if you don’t have the service packs mentioned for having the real principal propagation you don’t have many other choices.

Remember this is just an idea it’s not real principal propagation and if you want to use it you need to understand it’s pros and cons.

You must be Logged on to comment or reply to a post.
    • hi,

      it’s not a perfect approach but still
      sometimes you can’t have everything as clean
      and pretty as you’d like to have 🙂

      Michal Krawczyk

  • What a blog Michal!…kudos to you…i was really finding it hard to configure standard PP, will try this approach keeping in mind the restrictions 🙂
    • hi,

      >>will try this approach keeping in mind the restrictions

      as long as you have those in mind it ok 🙂
      but remember it’s pseudo propagation

      Michal Krawczyk

  • Michal,

    Principal propogation can be explained even to a layman with your 2 diagrams in the blog. The diagram you have shown is simple, neat and clear. Thanks for a quality blog.


  • Thanks for the blog, But its not working for me.

    i checked the two (ASMA and Variable Transport Binding), i cant see Dynamic configuration in SXMB moni.

    After that i tried adding &nosoap=true in the sending url as well..but no clue why iam not getting ..

    Please guide..


  • Very helpful article. My services are REST and of course ASMA parameters are not available in REST. Is there another way to forward PI User ID for REST?