TL;DR: Process-driven software is a thing. And always was. Now proven in a real world business scenario with the help of Camunda SaaS and SAP BTP.
What does a key user want to implement a process-driven application?
- Not to become a Citizen Developer.
- Neither a low-code developer.
- Nor having to upskill to any developer-related ability for that matter.
Instead, the person wants to model processes. That should run business logic and provide UI screens to users. Without having to spec out technical APIs or implement protocol details. This is exactly what we achieved when integrating the Camunda SaaS suite with BTP services and runtimes.
BPMN and DMN
Even though the Business Process Model Notation (BPMN) has been around for 20 (!) years and is a widely recognized standard, it has yet to manifest its full potential in the SAP sphere. BPMN “will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner” (direct quote from https://www.bpmn.org).
Its counterpart for modelling decisions is DMN, the Decision Modelling Notation. “The primary goal of DMN is to provide a common notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements and then more detailed decision models, to (…) the businesspeople who will manage and monitor those decisions” (direct quote from the specification, https://www.omg.org/spec/DMN/1.5/Beta1/PDF).
It helps to think of DMN as “Excel light” as it provides an “if-this-then-that pattern”: if x is of value “foo” and y is of value “bar”, then the result shall be “foobar” – similar to using an IF formula in Excel 😸.
BPMN is easy to understand even without knowing the formal specification. Take this Pizza Delivery process as an example:
Just by looking at the elements, visual hints and texts, it is clear that “after waiting 30 minutes and complaining to the delivery service, when the pizza hasn’t arrived after an additional 20 minutes, the order is cancelled.”
It’s visual expressiveness qualifies BPMN not only as a notation standard, but also as a comprehensive documentation tool!
Which, in turn, is its greatest pitfall: if only used for documentation purposes, BPMN models tend to transition into the digital filing cabinet quickly. Sitting and collecting virtual dust rather than being constantly updated and referred to.
This is where Camunda comes in – an engine that can run BPMN and DMN models!
Camunda SaaS and SAP BTP
Camunda provides a cloud-based solution for both drawing and running BPMN- and DMN-models. In addition to the modelling capability, It provides so-called job workers representing a particular BPMN task of the model. Following the above Pizza example, the “Cancel Order” service task would create a job worker containing all relevant business and technical data to perform a cancellation of the order in IT systems.
It is now the task of a business logic runtime to perform the work associated with Camunda’s job worker – in our project, this is done by the CAP layer in SAP BTP. CAP is SAP’s “Cloud Application Programming Model” designed for building cloud-native applications. In our case, we utilized CAP’s Node.js flavour to provide Camunda with job workers, implementing the required business logic, including interaction with 3rd party and SAP S/4 HANA systems. Interfacing with the Camunda SaaS via gRPC creates a fault-tolerant, yet highly performant, integration between the business logic runtime and the process execution engine.
On top of the business logic, a UI5-based User Interface provides user input to the running BPMN process where necessary. The CAP runtime updates the UI along the BPMN process, keeping the business process in sync with user interaction. By using web sockets for refreshing UI elements, the user experience becomes instant and blazingly fast.
In addition to using OData- and REST-APIs for interacting with 3rd party and SAP systems, our solution uses the Event capabilities of BTP to both send and receive events from connected systems. This allows for quickly adding and removing event-capable business system, without having to connect APIs directly.
By providing a CAP implementation for all major BPMN tasks, a literal platform was created that allows a very generic execution of runtime logic for business tasks – which in turn puts the Modellers into the driver’s seat. By creating BPMN and DMN models, the Modeller build a software application without having to write code: the definition of “low-code software development”.
No code necessary: BPMN drives the software
By separating BPMN modelling and execution from BTP business logic runtime, the key users never have to bother with technical implementations of their business processes. They model BPMN and DMN on the Camunda layer, never being burdened with technical configurations.
Changes to the running application on BTP don’t require code changes and redeployments, but adjustments of the BPMN and DMN model only – an increase in flexibility and turn-around time benefitting the business users.
In case there are updates necessary to the business logic runtime on BTP, developers can independently proceed from the modellers, not disturbing their work on the subject matters.
No real SAP pendant no process-driven software
Is there something from SAP serving the same purpose? Yes and No.
“Yes”, because on a high level, there’s SAP Build Process Automation. It allows creating workflows and automations on BTP, similar to Camunda Modeller, and running them, similar to Camunda Process Orchestration.
“No”, because SAP Build Process Automation is not providing BPMN- and DMN-capabilities, but a proprietary modelling standard. This requires upskilling on that proprietary modelling language, resulting in a lock-in for the modellers: all process design will only work in Process Automation, they’re not portable, nor universally valid.
And again “No” because in terms of “orchestration” capabilities, Process Automation only provides a friction of the Camunda engine features. Controlling the workflow via APIs, interacting with other systems (S/4, 3rd party, etc) or in-process data handling is where Camunda truely shines. Also, Process Automation holds very few capabilities of running custom buiness logic in a process. It doesn’t follow the “job” pattern by handing out work to a technical runtime like Camunda does, but requires the “job” to run as part of the Process Automation execution. This quickly results in limitations for providing business logic results.
Summary
Our integration between Camunda SaaS for business process modelling and SAP BTP for runtime logic caters ideally to the target audiences: a well-know User Experience for end users, a domain-specific capability for key users, and a familiar environment for developers. All can work independent of each user, with code and models deployed separately, disjunct update cycles, and no hindering close coupling.
Could this be a sustainable solution for generically running BPMN- and DMN-processes in BTP? Absolutely. There’s no technical reason why the solution only works for a specific customer. In fact, the solution has been so well-perceived that ideas started circulating for productising the Camunda-BTP-integration as a BTP “Add-On” for customers.
We have already implemented this successfully. Read more about Costumer’s requirements and KPIs.
