In this blog, I wanted to give a walk through of the new Workflow service on SAP Cloud Platform. This was one of the most awaited services on the Platform and no surprise, there was lot of excitement when the service was announced GA last month. I had lot of people ask questions on the capability and feature set of this service. Hence, I have tried to capture some screenshots and explain briefly some of the key functionalities.

The need for a Workflow Service in the Cloud Platform

The Cloud Platform is positioned as an Innovation platform where customers can build brand new apps or extend existing systems – be it on-premise or in the cloud.

There are several scenarios where customers build brand new applications on the Cloud Platform which only rely on the database and UX services provided by the platform. Automating tasks in such scenarios can be challenging. One of the scenarios I hear frequently, is the need to expose a portal to suppliers and have an approval mechanism to commit the updates they make using the Apps hosted on the supplier portal.

To give another example, assume there is a bank looking to rollout a mobile application for their customers to request for a loan.  Generally, the mobile app would trigger the APIs directly in the backend banking system. The logic behind the calculation of credit score, auto approval of loan, UI of approval tasks etc would be embedded within the core banking system. This would work, however, this leave lot of custom development within the core banking system and will impact the maintenance of the system overall.

With the Workflow service, we could redefine the same as shown below

Step 1: Retrieves customer details through APIs which are already exposed form the backend system.

Step 2: Calculate the credit score rating which could be maintained in Business Rule Service

Step 3: If credit score is not so great, customer relationship manager gets to review the request and can either decline the request (step 5) or approve the request (step 6) and the relevant business records get created in the backend system using exposed APIs

Step 4: If credit score is great, auto approval process trigger the update of relevant business records in the backend system using exposed APIs.

Hence, in this process there is only a need to ensure that there are APIs which are available to expose customer details and loan origination.

The workflow service is not only limited to brand new Cloud Platform apps or on-premise systems. This could also be used to extend processes in other Cloud solution. Assume, there is one level approval step which comes as a default in a Cloud solution like Field Glass. Using the exposed APIs, it’s now possible to change the approval process to a multi-step process. After the first level of approval, all the remaining level of approvals can be done using the Workflow service on the Cloud Platform.

The Workflow service is already tightly integrated with the Cloud Platform’s integration services. There are APIs already available to perform things like invoking the Workflow service, retrieving tasks details etc. There is detailed blog which shows how to trigger workflows from Integration services by Archana Shukla

Prerequisites

As a perquisite, you would need SAP Cloud Platform Portal service. This provides the Fiori Launchpad where all the approval and monitoring applications will run.

Once you subscribe to the workflow service, you will get a set of Fiori Apps which would allow the administration, monitoring of the Workflows as well as an App for end users to action the tasks.

Workflow Editor

When you launch the Workflow service, you will notice a BPMN based web editor which can be used for modelling your scenario. There are four sections. If you have used Cloud Platform Process Integration service, you will be able to find lot of similarities.

(1) The BPMN palette contain the list of objects which you can use to model your scenario

(2) The Properties section list the related properties of each object which you use in the scenario

(3) You can use the save option to download the metadata of the Workflow model or deploy it to the Cloud Platform. Once you deploy the workflow, it will be available in the Fiori App “Monitor Workflow Definitions”.

(4) Canvas where you would model the workflow scenario.

Let’s take a closer look at the key objects which are available to model a workflow.

Events:

These below events are supported by the Workflow service. As the name indicates, the Start and End events mark the beginning and end of the Workflow.

User Task:

A user task is to be used when you want a user to perform an action during the workflow scenario. Notice there are several sections in the properties editor. You can configure the text to be displayed for the task in the My Inbox App. You can also define who the recipients are for this particular task and finally in the user Interface section, you can refer to SAPUI5 components which will provide the UI for the task within the My Inbox App. These SAPUI5 apps need to be deployed in the Cloud Platform.

Service Task:

A Service task is to be used when you want the system to perform some tasks. This would ideally be APIs which would be invoked to either cloud or on-premise solutions. When invoking APIs exposed from on-premise systems, the Cloud Connector can be leveraged. In the below example, SM2 is the backend system which I have configured as destination in SAP Cloud Platform cockpit and this service task invokes an API to retrieve a customer detail. Supported REST operations are GET/POST/PUT/DELETE.

Script Task:

A script task is to be used when you want the system to execute a script based. This could be used to process an input from the workflow context and store the output as a variable which could be used in the following steps. You can use Java script to read and modify context variables of the Workflow service.

Clicking on “Open Script” take you to another screen where you will use insert your scripts.

To know more about how to use read and set the workflow context, you can look at these examples in SAP Help.

Gateways:

Gateways are used in the workflow service to control the flow of execution. An Exclusive gateway is used to model a decision whereas parallel gateways are used to either split the flow into multiple paths or merge multiple incoming paths. There are options to use expressions in order to define

Workflow Apps

As I mentioned earlier, once you subscribe to the Workflow service, your account will automatically get provisioned with the below Fiori Apps. You should be able to find them in the catalog and add them your Launchpad.

My Inbox:

You probably know the My Inbox App which has been available on the Cloud Platform for a while. The Workflow service uses the same My Inbox App for end users to actions their workflow items. You would need to develop the UI for each of your tasks as UI5 components and these UIs would be displayed within the My Inbox App when the user selects the relevant task.

Monitor Workflow Definition

Unlike My Inbox, this Fiori App is meant for Administrators. It can be used to view all the deployed workflow scenarios. An administrator can view all the instances of a particular workflow and also start a new instance by providing a JSON payload. There is also an option to download the metadata of the workflow model which can be imported into the Workflow editor to view the model

Monitor Workflow Instance

This is another Fiori App meant for administrators to view all the workflow instances. If a particular workflow instance has gone into error, the administrator can view the error details from within the App.

I hope this blog gave you an overview of the capability of the service. The workflow service is for sure going to add more flexibility to the cloud platform allowing customers to automate some of their processes and thereby differentiate themselves.

Please bookmark the SAP Help documentation for the Workflow Serivce which would get updated with new features added during the bi-weekly updates.