SCP Workflow Forms and the Role of Process Context

[nikolai_spogahn]

Last month SAP published Forms as part of SAP Cloud Platform Workflow (see New feature in SAP Cloud Platform Workflow – Forms and Monday morning thoughts: Workflow Forms and the definition of a developer). The idea behind it is to configure UIs for workflows on SCP in the SAP Web IDE and to generate SAPUI5 components with the so-called Forms Player during runtime according to the zero-code approach. The purpose of this blog entry is to bring Forms into line with BPM development on SAP Process Orchestration and to emphasize the meaning of the process context for this treatment.

Our long-term experience definitively makes clear that UI development is a significant cost driver in BPM implementation projects. On SAP PO we mainly applied two approaches to reduce such efforts:

• Usage of accelerated BPM (see aBPM – a solution extension offered by SAP Consulting)


• Build own toolboxes respectively frameworks for UI development

aBPM generates Java code (during design time) and SAPUI5 code (during runtime) out of an Excel file which defines the data model as well as the UI layout. Additionally, there are a lot of hooks in a Java controller to execute custom Java code for various UI and BPM events. Java APIs provide access to the entire UI and data model to extend the generated artifacts whenever required. Custom toolboxes try to reach the same: Declarative UI development and generation of the relevant artefacts – but they are not based on an Excel file but on XML for instance.

In addition to those two approaches there is another one that makes use of the built-in capabilities of SAP PO: It is possible to generate SAPUI5 components out of the process context and this is exactly the reason why we did not use it in our projects. We are following the best practice to keep the process context as lean as possible what is very important for versioning respectively migration – especially in agile projects where process instances in old versions are still running when new versions with UI adaptions are released (e.g. the UI should be extended by some elements with a new version but old process instances do not have these elements in their process context).

But with SCP Workflow Services the paradigm changed: Now we have JSON for data processing instead of XML. We do not have to define XML schemas and web service definitions based on WSDL anymore for BPM development. Now it is no problem to adapt such JSON documents used in the process context during runtime as we like. Such flexibility allows us to keep all the request data processed in our workflow within the process context and that’s the precondition for using Forms.

Keeping the data in the process context also affects the way we are developing monitoring tools: In (almost) every BPM project there is the requirement to implement some kind of process cockpit or request overview which provides a functional view on all running and completed workflow requests incl. search functionality, the capability to start workflows based on existing ones, to cancel running instances, and so on. aBPM for instance comprises the aBPM Cockpit to serve this purpose. Such cockpits are implemented based on the database where all the data of the workflow request is stored. Till now, this was not the process context because we just referenced the request data by using its ID in the process context. But from now on, our approach is to push the process context, which is now equal to the request data, into a document store by calling service tasks within the workflow, and to implement a process cockpit based on that.

However, Forms really looks promising when we tested it – but due to missing functionality, it is currently just an option for very simple workflows and for all other complexities we have to custom develop UIs as we did before. But we have to consider that this is just the first release of Forms and further functionalities will certainly follow with new releases. I am really looking forward to it.