SAP Build Process Automation, SAP Business Technology Platform, SAP S/4HANA Cloud, SAP SuccessFactors Platform

Principal Propagation (Run a Step on Behalf of) in SAP Build Process Automation

webadmin

Introduction:

With the latest release of SAP Build Process Automation, you can now allow other business users who participate in the business process to perform an action on external systems, such as S/4HANA, Ariba, or SuccessFactors. This feature also provides clear information on who triggered a business process in the system .

Pre-requisites:

You can enable principal propagation by setting Run step on behalf of field of Action and Subprocess activity with preceding step. Details will be explained subsequently.

What is Principal Propagation?

Principal propagation forwards the identity of cloud users to a remote system or service (Cloud Foundry environment).

SAP Certification

The Destination services let you forward the identity of a cloud user to a remote system. This process is called principal propagation (also known as user propagation or user principal propagation). It uses a JSON Web token (JWT) as exchange format for the user information.

The Destination service provides a secure way of forwarding the identity of a cloud user to another remote system or service using a destination configuration with authentication type OAuth2SAMLBearerAssertion. This enables the cloud application to consume OAuth-protected APIs exposed by the target remote system.

Supported scenarios:

  • Cloud to on-premise (using the Connectivity service)
  • Cloud to Cloud (using the Destination service).
  • Scenario: Cloud to On-Premise: The user is propagated from a cloud application to an on-premise system using a destination configuration with authentication type Principal Propagation.
  • Scenario: Cloud to Cloud: The user is propagated from a cloud application to another remote (cloud) system using a destination configuration with authentication type OAuth2SAMLBearerAssertion.
    In this blogpost ,I would cover the use cases related to the scenario Cloud to Cloud.

Scenario Cloud to Cloud:

Use Cases: Cloud to Cloud

  • User Propagation from the Cloud Foundry Environment to SAP S/4HANA Cloud
  • User Propagation between two Cloud Foundry Applications
  • User Propagation from the Cloud Foundry Environment to SAP SuccessFactors

Configuration steps:

Now ,let’s see the use cases in detail.

Use Case- 1: Execute Principal propagation end to end in from CF to SAP S/4HANA Cloud

Steps:

Configure Destination in SAP BTP cockpit

Configured OAuth2SAMLBearerAssertion Destination
  • Create a business Project.
Create Project
  • Create a process with a subprocess, which will be configured to be executed by the preceding approver using principal Propagation mechanism.
Model a process
  • Click on the subprocess and select Form user as ‘Run step on behalf of’ section in Subprocess’s side panel.
map Run step on behalf of field
  • Configure the subprocess to create business partner by connecting to S4 system. Click on the action in the subprocess and select ‘Process Start’ as ‘Run step on behalf of’ section.
Add an action to connect to S4 system
  • Release and deploy the project with the below destination (as configured above)
Deploy process
  • Trigger the process from Monitor tab with relevant payload.
  • Open ‘Process and Workflow’ section and search for the triggered process instance.
Workflow instance in Monitor tab
  • Check if the subprocess is executed by the user who submitted the form as ‘Run step on behalf of’ was selected as ‘Approver’.
Subprocess started by the propagated Approver user
Action inside subprocess executed by Propagated user

Use Case- 2: Execute Principal Propagation E2E from One Cloud Foundry environment to another Cloud Foundry environment

Concept:

  • User logs in to the cloud application. Its identity is established by an identity provider.
  • When the application retrieves an OAuthSAMLBearer destination, the user is made available to the Destination Service by means of a user exchange JWT.
  • The service then wraps the user identity in a SAML assertion, signs it with the SubAccount’s private key and sends it to the specified OAuth token service.
  • The OAuth token service accepts the SAML assertion and returns an OAuth access token. In turn, the Destination service returns both the destination and the access token to the requesting application.
  • The application uses the destination properties and the access token to consume the remote API.

Logical Flow of execution:

  • Ensure BTP Cockpit access in Source (Sub-account 1) for Configuring destination, download trust certificate.
  • Ensure BTP Cockpit access in Target (Sub-account 2) for adding trust, spa instance to get Client ID & Secret.
  • Create, release, deploy a process in Target account. Fetch workflow instance api endpoint and payload from monitor tab.
  • Create an action using the below json file in Source SubAccount (which will be triggered using the above fetched payload in runtime).
  • Create destination in source sub-account same way as mentioned in earlier hyperlink.
  • Add trust configuration in Target Sub-account and add the user’s ID as user with required roles in the trust profile.
  • Set PP user from source account to the action’s Side Panel.
  • Create, release, deploy process with the created destination with above action setup in Source account.
  • Start WF instance with the above fetched payload.
  • Watch over the execution log in Source account monitor tab.

Logical flow of Setting up outbound communication channel access for the user:

  • Create Administrator account
  • Create Communication user [e.g Client ID & Secret]
  • Setup communication system using the trust certificate from Source cloud environment.
  • Specify inbound/outbound communication mode.
  • Setup communication arrangement, to what service I want access.
  • Setup Authentication- OAuth
  • Update destination with OAuth details

Steps:

Configure destination in SAP BTP Cockpit

Configured destination of type ‘OAuth2SAMLBearerAssertion'
  • Create a business project.
Create project
  • Create a process and select Run step on behalf of field as preceding approver.
Model process and set Run step on behalf of
  • Configure an action to create workflow instance. This action will be used to call a deployed project instance in another CF environment.
Action editor to create workflow instance
  • Release and deploy project with the below destination.
Deploy the process
  • You can look for principal propagation reference in the deployed model for the activity where user has been propagated to execute the activity on behalf of.
principalPropagationRef in deployed workflow model
  • Create any process in ‘Another environment’ and release, deploy it.
  • Note down the workflow definition ID from TRIGGER section in Monitor tab.
  • Trigger the process by submitting the trigger form and provide relevant inputs.
Submit the trigger form
  • The propagated user from the action’s ‘Run on behalf of’ section has successfully executed the workflow definition corresponding to a deployed process in other CF environment using the configured destination.
Propagated user executed the workflow definition for a deployed process from other CF environment

Use Case- 3: Principal Propagation from Cloud foundry environment to SAP SuccessFactors

Business user want to propagate the identity of the user mapped for Principal Propagation to an action that invokes API of SAP SuccessFactors.