SAP recently launched the Workflow as a Service offering on SAP Cloud Platform. Click here to learn more about the service features and capabilities.
The Workflow service is quite a useful tool to build your very own customized workflows to cater to your requirements. If you are already familiar with BPMN (Business Process Management Notation), you should feel at home working with Workflow Service. There are some interesting blogs (here) you could refer to learn more about 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.
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