Skip to Content

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 – help.sap.com
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. 

    CALL FUNCTION ‘BDC_OPEN_GROUP’
         EXPORTING
              CLIENT   = SY-MANDT
              GROUP    = ‘TEST’
              USER     = SOAPuser
              KEEP     = ‘X’
              HOLDDATE = ‘20090101’.
    CALL FUNCTION ‘BDC_INSERT’
         EXPORTING
              TCODE     = ‘VA01’
         TABLES
              DYNPROTAB = BDCDATA.

    CALL FUNCTION ‘BDC_CLOSE_GROUP’.

*we also need to execute this batch input session:

submit RSBDCSUB with mappe = ‘TEST’ EXPORTING LIST TO MEMORY
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.

To report this post you need to login first.

8 Comments

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

  1. SEBIN THOMAS
    Michael, This is an awesome blog.

    This information will be very helpful in resolving real business problems.

    Keep blogging…

    (0) 
    1. Michal Krawczyk Post author
      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 🙂

      Regards,
      Michal Krawczyk

      (0) 
  2. abhishek salvi
    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 🙂
    (0) 
    1. Michal Krawczyk Post author
      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

      Regards,
      Michal Krawczyk

      (0) 
  3. Saravana Kumar Kuppusamy
    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.

    Regards
    Saravana

    (0) 
  4. VenkataPrabhakar Teegavarapu
    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..

    Thanks
    Prabhakar

    (0) 
  5. Ivan Kalcha

    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?

    (0) 

Leave a Reply