This is part of a multi-blog series concentrating on how to consume the backend APIs in SAP Cloud Platform Workflow Service.

Context

Building and extending cloud application workflows can unify processes across systems and connect human-centric activities and information across the enterprise. Often, you would want to consume existing services as part of the extension workflows to perform specific tasks – for example, get product master list, get quotation details, etc. This blog explains how an application developer can:

1. Consume any OData service developed through SAP Gateway Service Builder in SAP Cloud Platform Workflow.
2. Consume any OData service developed through SAP Cloud Platform OData Provisioning in SAP Cloud Platform Workflow.

What to expect in this Blog

By exposing SAP Business Suite functionalities like BAPIs or any RFC-enabled function modules as REST-based OData services, SAP Gateway enables SAP applications to share data (RFC, BAPI) with a wide range of technologies and platforms including SAP Cloud Platform Workflow Service. This blog will NOT explain how to create OData service using SAP Gateway Service Builder or with SAP Cloud Platform OData Provisioning but rather will detail on how a cloud application developer can consume such services in SAP CP Workflow’s Service Task. If you are looking for information on how to expose backend services as OData service you can refer to the following blogs:

A step-by-step guide to building an OData service based on RFC

How to develop a Gateway Service using code based implementation

How to create OData service with all CRUD operations

Connect ABAP Backend to HCP via HCP OData provisioning

Consume OData service created using SAP Gateway Service Builder

Pre-Requisite

1. Before you can consume SAP Gateway OData service, make sure that the service which consumes RFC is created, activated & is also accessible through any HTTP client.
2. Any OData service (which is RESTful and can be formatted as JSON) can be consumed directly in an SAP CP Workflow Service Task. Hence the OData service created by the Service Builder can also be consumed directly in the service task. Since SAP Gateway is an on-premise application and is behind a secure network (intranet), you need to use the SAP Cloud Connector.
3. IT Administrator should have already installed the cloud connector.

How to Achieve it?

To consume the OData services in SAP Gateway, we would be configuring SAP Cloud Connector to expose them outside the intranet. We would then create an SAP Cloud Platform Destination and consume the OData service directly in a Service Task of a workflow.

Configure Cloud Connector

IT Administrator should complete the following steps in SAP Cloud Connector:

Add SAP Gateway system in SAP Cloud Connector

1. Create a new ‘Cloud To On-Premise’ connection.
2. Choose the backend type as ‘SAP Gateway’.
3. In the next screen choose the communication protocol as required. I have chosen HTTPS since the Gateway system is SSL enabled.
4. In the next screen, enter the Internal host and the port to access the SAP Gateway service. In my system, the port for HTTPS communication is 44300.
5. In the next screen, enter the virtual host and port.
6. Maintain the principle type in the next screen. I have maintained it as ‘None’, but you might want to use X.509 certificate or a Kerberos as principle especially in the production system.
7. Finally, enter the description for the system that you are adding and complete the process of adding SAP Gateway system in SAP Cloud Connector.

Configure Resource Access

1. While adding a new resource which can be accessed via cloud connector, I have chosen to expose ALL services in the system by marking the URL as /sap and ‘Path and all sub-paths’ for the access policy. If you want to expose only a few OData services, then you have to choose the options accordingly.

Add an on-premise destination in SAP Cloud Platform

Once the cloud connector installation and configuration is completed by the IT administrator, the cloud application developer needs to perform the following step to create a destination for connecting to the SAP Gateway system.

You can refer to the help content to create an HTTP destination from SAP CP Cockpit. While creating the destination to connect to the SAP Gateway OData service, keep in mind the following information:

• Type of destination is HTTP
• URL is the virtual URL & port as defined in the cloud connector configuration. Make sure you give the HTTP as the protocol here even if you have configured an https service in cloud connector. The services which are exposed via cloud connector are virtually opened in the VM with HTTP but internally connects to the on-premise system via the protocol defined in cloud connector.
• Proxy Type is “OnPremise”
• Credentials for the SAP Gateway system should be provided (in this example, I have used ‘Basic Authentication’. SAP CP Workflow supports NONE and BasicAuthentication as of Oct 2017, and we plan to add OAuth support soon).
• Maintain the SAP Gateway system client information in the property jco.client.client

Optionally, once you have defined the destination, click on ‘Test Connection’ to check if the system can resolve the proxy and connect to the SAP Gateway system.

Consume backend services exposed by SAP Cloud Platform OData Provisioning

SAP Cloud Platform OData Provisioning (ODP) exposes business data and business logic as OData services on SAP Cloud, thereby enabling customers to run user-centric applications on SAP Cloud Platform.

There are multiple articles and help documents that explain how you can expose backend services (like RFC) as OData service on SAP Cloud Platform. For example, refer to this blog. The output is a service document URL which looks like https://gwaas-<userId>trial.hanatrial.ondemand.com/odata/IWBEP/<RFC_NAME>;v=1

Access the OData service from Workflow Service Task

Register OAuth Client

The ODP service URL supports access via OAuth clients and not basic authentication. So, to access the service URL, register a new OAuth client:

1. In your SAP Cloud Platform cockpit where the ODP is enabled, navigate to Security->OAuth section and go to the Clients tab.
2. Choose Register new Client button.
3. Enter the following details and click Save:

Copy the OAuth Token Endpoint under the Branding tab.

Create OAuth Destinations

1. Navigate to Connectivity -> Destinations in your SAP Cloud Platform Cockpit where SAP Cloud Platform Workflow service is enabled.
2. Click New Destination button.
3. Set the name as ODP (or any name of your choice), URL as the OAuth Token Endpoint.
4. Set the Proxy Type as Internet and Authentication as BasicAuthentication.
5. Set the User as OAuth Client ID & Password as OAuth Client Credentials, which were set earlier.
6. Save the Destination.

1. Create one more destination by clicking New Destination button.
2. Set any name of your choice and set the URL as the ODP Service document URL.
3. Set the Proxy Type as Internet and Authentication as NoAuthentication.
4. Click New Property button.
5. Set the property key as bpm.oauth.token.destination and the value as the destination created above (e.g.: ODP).
6. Save the destination.

Provide Authorization for the OAuth Client User

Since the ODP service URL will be accessed via OAuth client, the corresponding (technical) user should be provided with the right roles.

1. In the SAP Cloud Platform cockpit, navigate to the OData provisioning tile under Services section.
2. Choose Configure OData provisioning under Service Configuration section.
3. Under the Roles section, select the role you want to assign (GW_User).
4. Choose Assign in Individual Users section.
5. Enter the user id as oauth_client_<OAuthClientID> and choose Assign (for example, oauth_client_workflow_odp)

Consume OData Service in a Service Task

Once you have configured the required destination successfully, it is straightforward to consume the OData service in a Service Task via Cloud Connector.

1. Add a Service Task to the workflow editor.
2. Add the destination you have created earlier. (In case of SAP Cloud Platform ODP, use the destination which has NoAuthentication as the Authentication type).
3. Enter the path to access the service. If you have to pass any inputs to the service, then you can get it from the workflow context. For example, I have created an OData service called STV_QUOTATION and want to access the quotation details by passing a Quotation ID. Hence, my path would be

/sap/opu/odata/sap/SRV_QUOTATION/QuotationSet(‘${context.quoteid}’)?$format=json

• All the OData services created in SAP Gateway is available under /sap/opu/odata/sap
• QuotationSet is the entity I am accessing to get the details about the quote.
• I am also passing the Quotation ID available in the workflow context. ${context.quoteid}
• I am also formatting the output of the service as JSON by using the keyword $format=json. Make sure you format the result to JSON since SAP CP Workflow works only with JSON object.
• Finally, the output of the service (in JSON format) is transferred to the variable ‘quote’ of the workflow context.

If you are accessing a service to create an entity, you would be accessing a POST method. Such a modify request would require a CSRF token to prevent cross-site request forgery. In such a case, you can provide the path to any non-modifying service in the property ‘Path to XSRF Token’ and the SAP CP workflow service will automatically resolve it.