Skip to Content
Technical Articles

Call SAP Cloud Platform Workflow from ABAP using an OAuth access token

I recently had to develop some code to trigger a workflow in SAP Cloud Platform from an ABAP onPrem environment using OAuth access tokens. This blog hopefully gives those of you a “leg up” who are working on the same task.

As an inspiration, I used Archana Shukla’s great blog post on Using OAuth2.0 to access SCP Business Rules, which gave me the correct steps to set up destinations, gave me the Access Token URL and helped me to test the call before coding it in ABAP. Another help was Rich Heilman’s recent blog post on “Leveraging SCP Neo Workflow from the ABAP Environment“, which uses ABAP Cloud (aka Steampunk), but also gave me some pointers.

Note: This example uses a simple SCP Workflow. If you haven’t got one yet, simply create one using these tutorials and missions.

The sample ABAP code for this blog post can be found on my Github sample repo. Ok, let’s get started.


Step 1: just like in Archana’s example, I registered an OAuth client in SAP Cloud Platform (Step 1). Note the subscription wfs/bpmworkflowruntime I used, which differs from Archana’s example. I also gave my client a “secret” password.


Step 2. I then added my OAuth client to the roles in the SCP Workflow settings (Services ->Workflow->Configure Settings->Roles – not the prefix of “oauth_client_” before the generated client ID from step 1.


Step 3. just like in Archana’s exmaple, I then created 2 destinations in SCP Cockpit: one for the OAuth token URL and another one for the SCP Workflow API.

Destination for the OAuth acess token (note the setting for Basic Authentication), which uses the generated client user ID from Step 1 and the “secret” password. For the URL, I used the “Token Endpoint” URL from the “Branding” tab in the OAuth section (see step 1 or Archana’s example).


Destination to call the SCP Workflow API: As URL for the SCP Workflow API, please enter: https://bpmworkflowruntimewfs-<scp-user>

Since the destination is without authentication, the access is granted via the OAuth2.0 toekn, which is indicated using the property bpm.oauth.token.destination (note: this is not available in the dropdown and has to be keyed in) and value SCP_WF_UAA (ie the name of the first destination created a moment ago).

Checking the Connection using the button “Check Connection” works just fine:


Step 4. Now our OAuth client, role and destinations are configured, we turn our minds to the ABAP stack. First, we need to set up 2 HTTP destinations in SM59, since the ABAP code uses client creation “by Destination” (as recommended by SAP). Please note the path prefix of “/oauth2” and the use of port 443 (https).

The first destination is for the OAuth service:

Logon & Security is set to the generated client User ID for OAuth (see Step 1) and your chosen “secret” passowrd.


The second HTTP destination is for the call of the workflow API destination. Please note the target host is specified as “bpmworkflowruntimewfs-<scp-user>”. Also note the path prefix of “/workflow-service/rest/v1” and port 443.

under Logon & Security, no authentication details are required, because our access OAuth2.0 token suffices now.


Step 5: Now all setup is complete and all that is left to do is implement our ABAP coding. I will explain the main steps of the logic below. Please check my Github repo to clone the sample code.

  • we create an HTTP client from our destination by using the standard libraries. Note the form field “grant_type”



  • then we extract the received access OAuth token to later use it to set it as the “Authorization” header field. Note that the workflow definition ID I am using is “testworkflow”. This is the name of my workflow in SCP Workflow.


  • when executing the Workflow, the ABAP spits out the workflow instance ID it has just created via HTTPS call.

  • when finally checking my workflow inbox in the Portal, I can see a new Workflow instance and approval request waiting for me:


Summary: As shown, a new SCP Workflow instance was created using a call from ABAP using 2 new SCP destinations, an OAuth2.0 client, SCP Workflow role and http destinations from the ABAP stack. OAuth2.0 is a commonly used authentication method to access Rest APIs in cloud environments.

Another option would obviously be to perform the same using integration via Cloud Platform Integration (CPI). Maybe a blog post for another day…

I hope you will find this useful. Please feel free to branch, extend and contribute to my ABAP code on GitHub.

You must be Logged on to comment or reply to a post.
  • Great blog.. Exactly what we were looking for thanks!

    If our SAP Cloud Platform subaccount is configured with an Application Identity Provider via Identity Authentication Service (IAS).. How will we incorporate this in the RFC or SCP destination?

    • Hi Mhac

      You're welcome.

      I haven't worked with AIP and IAS yet, but in this case, you simply wouldn't be able to used the create_by_destination method from ABAP, but call the IAS service directly. RFC destinations wouldn't support this setup. It is just a shortcut in any case to do away with code changes everytime auth changes.




  • Hi Michael Koch ,

    Question.. Why did you need to create the 2 destinations in SCP when those were not used by the ABAP program as it is using the 2 SM59 destinations instead?

    Thanks for this helpful blog.



  • Hello Michael

    I have followed your blog and tried to create a WF instance . When I am trying to do so  , the destination is set up with  a proxy and hence the results in content variable  holds the details of a CNF-PAC file, also the workflow also doesnt trigger.

    Do you know how I can mitigate this.