This is a short series of blogs that will address how to consume OData APIs from your SAP Cloud Platform Workflow Service. It is recommended to go through the following blog – Connectivity Options with SAP Cloud Platform Workflow Service, to get a better understanding of all connectivity options for the workflow service.
In the workflow, if you wish to invoke a service, you would need to configure a service task and a destination appropriately. While you can create a RESTfull service and expose it through a Java application on the cloud, you might be interested to know how to deal with your existing services that are exposed as OData APIs. In this series of blogs, I will attempt to familiarize you with configuring your Workflow and consuming such OData APIs.
Let’s start simple. An OData API of method type GET, and Basic Authentication.
- You have the URI to invoke the OData API
- You have the credentials to authenticate the call
As an example, I will use some common OData APIs that SuccessFactors provides on its Test (as well as Live) landscapes.
You can refer to the following document for further information:
Please note, if you wish to use the SuccessFactors’ OData APIs, you need to have a SuccessFactors instance with appropriate access rights to it. Please refer here for further details.
Suffice to know, as far as consuming the OData API from workflow is concerned, it does not matter if the apis are on the cloud or on premise. The destination configuration will be similar. However, for consuming apis on premise, there is an additional configuration. You can learn more about it here – SAP Cloud Connector
In the scope of this blog, I will explain how to consume the OData API from a service task. Displaying or further using the received data will not be covered here.
You would first need to configure how to access the endpoint URI. This is done by creating a Destination and providing the relevant information.
- In the SAP Cloud Platform Cockpit, go to Connectivity -> Destinations
- Create a new destination by clicking on New Destination
- Provide the required information
- Save the changes. With this we are almost half way through. The destination is ready to be used in your workflow to invoke any OData APIs.
Note that the URL is succinct enough to tell where the OData APIs will be accessed from, but not which OData API or which version of the OData API. This makes the destination reusable for different OData API calls, provided that the authentication remains the same.
The next thing to do is to use the destination in your workflow. In this example, I will use a very rudimentary workflow, whose only purpose is to familiarize you with how to invoke the OData API.
- Navigate to the workflow editor. You can do so by going to Services > Integration > Workflow. Alternatively, when you go to services, you can simply search for the Workflow service using the search box
- From there, click on Workflow Editor link to open the editor.
- Create a simple workflow that has at least one Service task from which we shall consume the OData API. I this example, the workflow looks something like this
Let’s now have a look at the Service Task ‘Get SFSF Content’ and see how we call the OData API.
As mentioned earlier, the URI for the OData was
The destination is configured as https://apisalesdemo4.successfactors.com/
That leaves us with the path to the OData API as odata/v2/TodoEntryV2?$format=json
Note, the URL is not to be decoded. The structure of the query remains as is, with all the spaces and special characters in the query.
Also observe, the parameter ‘format=json’ ensures that the response is received in JSON format, which can be consumed by the workflow.
- In the service task, go to the Service Task Properties à Details tab and provide the appropriate information
That’s about it. The response of this call will be added into the process context in the following path – context > sfsf > response
The response will be of type JSON owing to the parameter sent in the path – format=json
Just for reference, the workflow context will look something like this with the response:
You can see that this was quite simple and straightforward. Invoking an OData API of type GET and with basic authentication is as simple as it gets. In the next part of this blog, I’ll take you through calling an OData API of type POST without any request payload. So, stick around… Cheers