Skip to Content
Technical Articles
Author's profile photo Michael Koch

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Phil Cooley
      Phil Cooley

      Nice blog, thanks for sharing!

      Author's profile photo srinivas sistu
      srinivas sistu

      Nice blog Michael, thank you for sharing the knowledge......

      Author's profile photo Michelle Crapo
      Michelle Crapo

      An On-premise blog!!!  Woohoo!

      Very nice - I'll have to take a look at the code on github.


      Author's profile photo jyothir aditya k
      jyothir aditya k

      Thanks a ton !! Been looking for something like this.

      Author's profile photo Mhac Dugay
      Mhac Dugay

      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?

      Author's profile photo Michael Koch
      Michael Koch
      Blog Post Author

      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.




      Author's profile photo Mhac Dugay
      Mhac Dugay

      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.



      Author's profile photo Phil Walburn
      Phil Walburn

      Hi Michael Koch

      Is it possible to display the OAuth Clients Name (SCPWF in your example), rather than the long string oauth_client_xxxxxx..... as the "created by" user in the Workflow screen ?

      Author's profile photo swarnali basu
      swarnali basu

      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.



      Author's profile photo karimulla mahammad
      karimulla mahammad

      Hello Michael,

      i trying to call cloud CF workflow from cloud abap environment, facing authorization issues. help guid me here.

      Thanks in advance.