Skip to Content

Principal Propagation in ccBPM finally made possible.


Nowadays, clients are more and more asking for traceability of transaction data in the backend system. This was already possible using principal propagation in SAP-XI, using direct interfaces from front-end to backend.

Implementing the described solution in this blog, principal propagation is now also available when using the BPM-engine in XI/PI.

Principal propagation in XI is a ticketing mechanism based on SAP logon / SAP Assertion tickets, which is available since XI3.0 SP19 and PI7.0 SP10.

The principal approach of principal propagation is:

  • The user that is executing the message equals the user that is to be propagated.
  • The credentials are propagated via the SAP Assertion Ticket (SAP Logon Ticket).
  • SAP Logon Ticket: A SAP system generates a SAP-specific assertion containing the subject name of the actual user which is then impersonated in the target system. This assertion is signed by private key of the sender system. There must also be established a trust relationship between the sender and the target system similarly to the X.509 certificate mechanism.
  • On the inbound side, both SAP and non-SAP systems are supported
  • On the outbound side, SAP backend systems are supported (understanding SAP logon tickets)
  • Non-SAP systems might support SAP logon ticket authentication by using the SSOext.dll library

The general configuration of principal propagation is already discussed in an earlier excellent blog ( Principal Propagation in SAP XI)  by Alexander Bundschuh, so there’s no need to explain that in detail again.

So again, what will be discussed in this blog is a way to use principal propagation in ccBPM, which is according to the documentation of SAP not possible.

Case / Scenario

Via a SAP portal, an employee fills in an expense sheet which needs to be authorized by his manager, before sending it to the SAP-HR backend system.

For tracking and tracing, it is a requirement that the expense sheet message is processed on the backend with the right authentication, namely the authorizing manager. Below the (simplified) process is explained.


Process steps:

  1. The employee fills in an expense sheet in the SAP portal webdynpro.
  2. This triggers a BPM in XI, which will create a task in the Universal Work List (UWL) for the Manager. After that, the BPM will wait for the response of the manager.
  3. The manager opens his work list, and approves the expense sheet of the employee. The already started BPM will receive this approval message and will continue.
  4. The BPM will send the expense sheet of the employee to the SAP-HR backend system using the manager’s authentication.
  5. The backend system stores the expense sheet.

I know that for this scenario, other solutions may be possible, but this blog has a goal to explain a way of using principal propagation in XI/PI BPM.



Using Business Process modeling, the “normal” SSO solution (described in this blog ( Principal Propagation in SAP XI) cannot be used, because the mysapsso2 ticket is lost when entering the BPM.

By using the payload of the message instead of the SOAP Header, the ticket can go throughout the Business Process all the way to the backend system (SAP-HR).

The process is described in the figure below. Functionally, this is the message from the manager which approves the expense sheet, and where the business process is waiting for.


AXIS SSO scenario

  1. From the Web Dynpro portal application a web service (or function module via RFC) is triggered on the SAP-XI system. This call contains one mysapsso2 ticket in the SOAP-header and one in the payload. The one in the payload is explicitly inserted by the code in the Web Dynpro. The one in the header comes automatically because of the configuration on the portal and XI systems.
  2. The message is transferred to the XI system. Both the header and the payload still contain the ticket.
  3. When the message is sent to BPM, the SOAP-header is lost; the standard user “WF-BATCH” is used. The SSO-ticket is still available in the payload.
  4. When the message of the approved expense sheet is sent to the backend system; a mapping with a user defined function puts the SSO-ticket from the payload to the XI-header.
  5. Using the AXIS-framework adapter, the SSO-ticket (mysapsso2) is transferred from the XI-Header to the SOAP header, and the adapter sends the  SOAP message to the backend system.
  6. On the backend the SSO ticket is used for authentication.

Additional WebDynpro development.

Besides the “normal” configuration which is necessary to make SSO work, the SSO-ticket needs to be put into the payload of the message.

First the structure of the message is extended with an extra string element “mysapsso2”. After that the sso-ticket can be put in the message when sending it to the XI-system. Below a part of the webdynpro code which does the trick.

Additional SAP-XI development.

In the BPM, the payload of the different messages is extended with the mysapsso2 element which is mapped all the way until the message is sent to the backend. Within the last mapping, the mysapsso2 element is mapped to the XI-header, using a user defined function:


Note the use of 3 parameters (Cookie1, Cookie2 and Cookie3) in the user defined function. This is needed because the length of the parameter SXMS_DYN_CONF_VALUE which is used by SAP for the Dynamic Configuration in the XI-Header is only 200 characters.

Extra configuration and development is needed at the adapter side to concatenate the sso-ticket again in the adapter.

Configuration AXIS Adapter.

Below the configuration of the AXIS-Soap adapter is displayed.



Detailed information of the axis adapter and the configuration is explained in the ” How To… Set http-Header Parameters using the Axis Framework ” on SDN.

There is however one catch in the configuration of this adapter…

Because of the limited length of the Dynamic Configuration value, the SSO ticket is cut into 3 parts in XI. This needs to be concatenated at the adapter. This means modification of the axis code on the server side. In the above picture following parameters are used, which are not available in the standard adapter:






Gets the value of Cookie1 from the XI-header in given namespace, and store it in value.a



Concatenate the value in Cookie2 to value.a



Concatenate the value in Cookie3 to value.a

Below the modified code of the class XI30DynamicConfigurationHandler.class in xi-axis-1.2.jar, which is located on the server in:


Additional development backend.

The axis-adapter uses a standard soap message to communicate to the SAP-HR Backend. To be able to communicate to the backend its necessary to create a Webservice from the available RFC or the (XI/PI) proxy.

You can do that in the ABAP Developer Workbench (SE80)



The URL which is needed for the AXIS adapter will be shown in the last step in the wizard.

For a RFC this would be:




Make sure you activate these in transaction SICF.

Last but not least….

I want to thank my colleagues for helping me out and to make this work.

Especially Marcel Kempers who helped me to take care of SSO configuration of the Portal/XI, and Ronald Kleijn who developed the Web Dynpro’s and modified the AXIS module…

You must be Logged on to comment or reply to a post.
  • The blog is really useful.
    I am working on PI 7.1 and need to enable AXIS framework. I have obtained the .sda file from the market place and as suggested, I am replacing the empty .jar files from that .sda file by those available in Axis 1.4 src package. However,I am unable to find the jar file commons-net-1.0.0-dev.jar in the source apckage and could not find it on the net also.
    Please suggest a solution to the same.
    MAny thanks
    • Hi Nenah,

      Like stated in the note (1028961):
      “Note that commons-net-1.0.0-dev.jar is only in the src package and not in the bin
      you have to download the source from a mirror on:
      If you download the, you will find the commons-net-1.0.0-dev.jar package in the lib folder which you can use in your sda archive.