With SAP Build Process Automation – May 2023 (What’s New) we introduced Principal Propagation (Run Step on Behalf Of). See also the documentation: Run a Step on Behalf Of.

In this blog post I will provide a sample for Principal Propagation using the CAP Node.js Service created in the developer tutorial: Extensions for SAP Build Process Automation – Actions from CAP Node.js Service

From the tutorial you have all the knowledge for SAP Build Process Automation, to work with destinations, Actions and Processes, so I will not cover this in detail here.

After you have created and tested the service from the tutorial, you can enhance the scenario using Principal Propagation.

1. Use existing or create new an Authorization and Trust Management Service in your subaccount
2. Use existing or create new Trust Configuration in your subaccount
   some manul configuration steps have to be done, but if you follow the steps in the help file, you will make it
3. Create a Destination to use Principal Propagation
4. Modify the CAP Service sample to use the configured XSUAA service
5. Test in Action Editor
6. Test in SAP Build Process Automation

This is part of a blog series for Actions:
SAP Process Automation – Consume APIs with <no-code> using Actions.

Authorization and Trust Management Service

In your subaccount you should have a service instance with a service key like in the sample below.

Trust Configuration & Destination

In the subaccount where the CAP service is running, you need a trust configuration.
In this sample we are not using Subaccount 1 and Subaccount 2, we are just working with one Subaccount. Still you need to configure Trust, but you will do all the steps in one subaccount.

The Help below contains placeholder for values you need to collect from your subaccount. Whenever ${S2_} is mentioned, just use the ${S1_} value.

You are asked to assemble metadata from different areas. Best way is to copy the content to a text file, work on the configurations and save the work for later use. Here some placeholders used in the help (added some of my experience, full details can be found in the help):

• <content> as ${S1_CERTIFICATE}
  downloaded X.509 certificate of your subaccount
• ${S1_LANDSCAPE_DOMAIN}
  on my trial: us10.hana.ondemand.com as part from the url:https://api.cf.us10-001.hana.ondemand.com
• ${S1_SUBACCOUNT_ID}
• ${S1_SUBDOMAIN}
• <alias> as ${S1_ALIAS}

Now Let’s Start.

1) Read the Concept and follow the Procedure

Follow the steps as outlined in the help till you reach the section Create an OAuthSAMLBearerAssertion Destination: User Propagation between Cloud Foundry Applications

2) Create an OAuthSAMLBearerAssertion Destination

Again follow the steps in the help till you reach the section Consume the Destination and Execute the Scenario (we will consume and execute using Action Editor and SAP Build Process Automation).
Remember, you will use always the ${S1_} value.

From the existing Destination Demo_CAP_Sample_Library we will use some parameters, please copy the value to your text file:

URL: <your CAP Service URL)
Additional Properties:
sap.applicationdevelopment.actions.enabled = true
sap.processautomation.enabled = true

I have used Demo_CAP_Sample_UPP as name for the destination, but feel free to use a different name.

Modify the CAP Service sample

We have to add some definitions and libraries to the sample project and deploy a new version of the service. Open the CAP Project from the developer tutorial in your SAP Business Application Studio and change to View > Explorer.

1) Definitions in mta.yaml

Open the file in a text editor, right-click > Open with… > TextEditor default

The requires section must contain the name of your XSUAA service and must be listed under resources.

    requires: 
      - name: demo_xsuaa
resources:
  - name: demo_xsuaa
    type: org.cloudfoundry.existing-service
    parameters:
      service: xsuaa

2) Definitions in package.json

Open the file and add the cds defintion, just replace starting with “scripts” all lines till the end of the file.

  "scripts": {
    "start": "cds-serve"
  },
  "cds": {
    "requires": {
      "auth": {
        "kind": "xsuaa"
      }
    }
  }
}

3) Definitions in service.js

The toStr function should return also the user information. Replace the existing function with

    srv.on('toStr', req => {
        const {value} = req.data;
        
        return { 'value' : value.toString() + ' ' + req.user.id};
    });

4) Add some libraries

From the Terminal menu, select New Terminal and execute the following commands:

npm add passport

npm add @sap/xssec

5) Deploy your Service to Cloud Foundry

Finally you need to deploy the new version of the CAP Service (like you did in the developer tutorial in Step 5 – Deploy your Service to Cloud Foundry).

bash script.sh

Remark:
This is just covering the basics, More information about Authorization in CAP Services can be found in the documentation of the Cloud Application Programming Model: Authorization and Access Control.
Like Authorization Enforcement using @(requires: ‘authenticated-user’) or using Roles in your service.

Service Binding

After deploying the service, you can check the Bound Applications for the XSUAA service. It should contain your CAP Service.

Test in Action Editor

Open the CAP Sample Actions project and test the action toString using the new Destination.

In the Test Preview you will see the value and the user information –> Principal Propagation from the Action Editor user.

Test in Business Process

For the test in a process, you can use again the existing sample project from the tutorial CAP Sample.
I have created a process which can be started from a Form and uses the toString Action.

The Form contains just a value field which will be passed as input parameter to the action. For Run step on behalf of, the Process Start user was selected.

After releasing and deploying the process (using the destination Demo_CAP_Sample_UPP created above), you can test using the Form Link from the deployed process:

In the Form enter a value and click Submit:

Finally you can check the process execution in the Monitoring and again will find the user information from Principal Propagation in the action result

Conclusion

With this highly requested feature, we enable seamless transmission of the user identity for API’s using Actions.

We hope you enjoy using this new feature and look forward to your feedback.