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.
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’
CLIENT = SY-MANDT
GROUP = ‘TEST’
USER = SOAPuser
KEEP = ‘X’
HOLDDATE = ‘20090101’.
CALL FUNCTION ‘BDC_INSERT’
TCODE = ‘VA01’
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 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.