Principal Propagation
You can forward user contexts using principal propagation, which means you can transfer principals from incoming events (such as start events and intermediate message events) and from human activities to an automated activity. The automated activity is then executed with the given user information.
The user identity that is forwarded is only used to start the automated activity, the Web service call. It is not used for the execution of other activity types.
To use the principal propagation functionality, you need to select the Enable Principal Propagation checkbox on the Properties tab of the process, on the General pane. For downwards compatibility, principal propagation is set to off by default. For more information, see Creating a Process .
The following picture shows a simple example of principal propagation.
The principal that initiated the process is used authenticate the subsequent Web service call in the automated activity ( Service Call ).
Receipt of Goods process: The goods come on pallets. The pallets and their content are registered at the gate. A worker needs to confirm that everything is okay. This is done by a Web service that needs to be authenticated by this worker. For the process this means that the initiator of the process needs to be propagated to the service call and then be authenticated.
Propagation of the Principal Data
The incoming message that transfers the principal information can come from the following BPMN elements:
-
Start event
-
Intermediate message event
-
Human activity
For more information about BPMN (Business Process Modeling Notation) process models and elements, see Using BPMN Process Models .
Start Event and Intermediate Message Event
Both event types (start event and the intermediate message event) are triggered by an incoming request. The principal information is given by the incoming request and the principal attributes of the events are then copied to the main token of the process flow that propagates the principal onward. For more information about events, see Events and Modeling Events .
Human Activity
The principal attributes are only propagated when a task is completed. The actual owner information is taken from the involved task and the main flow token is populated with the principal information. For more information about human activities, see Activities and Modeling Human Activities .
Consumption of the Principal Data
When an automated activity is reached in the process flow, it consumes the principal information. It switches to the user that is set in the principal attributes for the time when calling the Web service. If there is a technical user maintained for the service definition or service group in the SAP NetWeaver SOA Management, this setting overrules the principal propagation token.
The following table shows the default hierarchy of used credentials to start an automated activity:
|
Provider of the Credential/Principal |
Condition |
|---|---|
|
1. Connectivity |
The user and password that is used to set up the connection in the SAP NetWeaver Administrator SOA Management is consumed by the automated activity. |
|
2. Principal propagation |
If no credential is provided by the connectivity and if principal propagation is activated for the process flow and the token contains a principal this is consumed by the automated activity. |
|
3. BPM Service User |
If no credential is provided by principal propagation or connectivity the default user BPM Service User is consumed by the automated activity. |
Principal Propagation in the Process Flow
When modeling a process with active principal propagation, you have to consider when in the process flow the principal information is forwarded and when it is removed. The following table describes the behavior of the token populated with the principal information in a process flow.
|
Exclusive choice |
The token is sent onward including the principal information. |
|
Parallel split |
The token is sent onward including the principal information. If new tokens are generated the principal attributes are set accordingly for them. |
|
Uncontrolled merge |
The token is sent onward including the principal information. |
|
Parallel join |
Any principal information is removed. |
|
Loops |
Due to token merge semantic, the out token flow does not propagate the principal. |
|
Boundary events |
Due to cancel semantic, the out token flow does not propagate the principal. |
|
Embedded sub-process |
The token propagates the principal information from the main process flow into the embedded sub-process. The principal information is also effective in the sub-process flow. There, the principal can be set by task activities and can be used by automated activities. When a token leaves an embedded sub-process flow, it propagates the latest principal information into the main process flow. |
|
Referenced sub-process |
Due to independency semantic, the in and out token flow for referenced sub-process flow does not propagate the principal. |