This demonstration introduces Caterpillar, an open-source Business Process Management System (BPMS) that runs on top of the Ethereum blockchain. Like any BPMS, Caterpillar supports the creation of instances of a process model (captured in the Business Process Model and Notation - BPMN) and allows users to track the state of process instances and to execute tasks thereof. The specificity of Caterpillar is that the state of each process instance is maintained on the Ethereum blockchain, and the workflow routing is performed by smart contracts generated by a BPMN-to-Solidity compiler. The compiler supports a wide array of BPMN constructs, including user, script and service tasks, parallel and exclusive gateways, subprocesses, multi-instance activities and event handlers. The target audience of this demonstration includes researchers in the area of business process management and blockchain technology.
Blockchain platforms such as Ethereum3 allow a set of actors to maintain a ledger
of transactions without relying on a central authority and to deploy scripts that
can be called by external actors to change the state of the ledger. These features
provide basic building blocks for executing collaborative business processes
between mutually untrusting parties [
This demonstration paper introduces Caterpillar, an open-source BPMS designed from the ground up, with the aim of combining the development convenience of a BPMS with the tamper-proofness of a blockchain platform. Like most contemporary BPMSs, Caterpillar supports the creation of instances of a
BPMN process model and allows managers and process workers to track the
state of process instances and to execute tasks thereof. The specificity of
Caterpillar is that the execution state of each process instance is maintained on the
Ethereum blockchain and the workflow routing is performed by smart contracts
generated by a BPMN-to-Solidity compiler [
Modeling
tools Compilation tools Solidity compiler
Models Metadata Service interfaces
Execution panel Event monitor Execution engine
Work item manager Instance registry (contract addrs)
Ethereum RPC (via web3.js)
WI mgr registry (contract addrs) Ethereum client
(e.g. geth)
The architecture of Caterpillar is presented in Fig. 1. The core of Caterpillar consists of the modules inside the dashed rectangle, namely the Compiler Tools, the Execution Engine, the Event Monitor, the Work Item Manager and repositories for process models, metadata, service interfaces and runtime data (specifically, process instance data and work item data).
The Compilation Tools module implements a comprehensive mapping from BPMN to Solidity. Given a BPMN model (in standard XML format), this module generates a smart contract (in Solidity), which encapsulates the workflow routing logic of the process model. Specifically, the smart contract contains variables to encode the state of a process instance, and scripts to update this state whenever a task completes or an event occurs. Caterpillar supports not only basic BPMN control flow elements (i.e. tasks and gateways), but also includes advanced ones, such as subprocesses, multi-instances and event handling. The Compilation Tools module is linked to a Modeling Tool, developed on top of Camunda’s BPMN modeler.4
Caterpillar’s Execution Engine provides operations to deploy a process model (i.e. to deploy the smart contracts generated by the Compilation Tools), to create instances of a deployed process model, to determine which tasks are enabled and to control and record their execution. The execution engine is also responsible for executing automated script tasks and for triggering external service calls whenever a service task is enabled. The Event Monitor listens to events generated by the blockchain and generates notifications whenever a transaction related
to a process instance is validated on the blockchain, so as to keep the other Caterpillar components updated. Caterpillar also provides a default Execution Panel (to create and track process instances) and a default Work Item Manager (to handle user tasks). The functionality of the Caterpillar engine is exposed via a REST API, allowing developers to implement their own execution panel or work list handler instead of using the default ones.
All core modules are implemented in Node.js and rely on standard Ethereum tools to compile the smart contracts (specifically using the Solidity compiler solc) and to interact with running instances of the smart contracts via an Ethereum peer node (specifically using the Ethereum client geth). 2
Caterpillar’s Engine provides a REST API that exposes three types of resources: models, that is BPMN models and compilation artifacts; processes, referring to the set of currently running process instances; and services, i.e. references to smart contracts and addresses used for interacting with external services. Table 2 shows the mapping of resource-related actions with the corresponding core module: white background for compilation tools, blue background for execution engine and yellow background for work item manager.
Once the caterpillar core is running, a user can submit a BPMN model using an HTTP POST request on the URI /models with a JSON message that includes the model name and the model serialized in the BPMN 2.0 XML format. To enable the process to interact with external services, a corresponding smart contract/address must have been previously registered using an HTTP POST request on /services. This is required because the service’s smart contract address is compiled into the process’s smart contract.
A new instance of a process can be created using an HTTP POST request on the URI /models/:mid, where :mid is the identifier provided when the process model was registered. As a result of this request, Caterpillar will return a hyperlink that refers to the newly created process instance in the HTTP header Location and an HTTP status 201. Such a hyperlink would have the form /processes/:pid, where :pid corresponds to the address assigned by Ethereum to refer to the instance of the process’ smart contract.
At any time, the state of a process instance can be queried by using an HTTP GET request on the URI /processes/:pid. From here, external actors can obtain the hyperlink to execute a User Task – if enabled. This execution occurs using an HTTP POST request on the URL /workitems/:wimid/:wiid. Note that the request is going to a workitems component which validates the user access rights before forwarding the call to the process instance contract.
The execution panel illustrates graphically the results of querying the state of a process instance and also allows the execution of user tasks by external actors. Here, every enabled task is visualized in dark green, while activities in execution are drawn in light green. A user may start the execution of an enabled task by clicking on it and submitting the required parameters, as shown in Fig. 2.
Only user tasks and catching messages are drawn in the execution panel, because the execution of other types of BPMN elements (e.g. gateways, throwing events, script tasks, etc.) is started internally by Caterpillar. For the demo, we will also use the debug information printed by Fig. 2. User task in Caterpillar in the terminal to keep track of internal ac- execution panel tivity (e.g. execution of script tasks) and interaction with external services. 3
Caterpillar is in its first release. However, the prototype extends and consolidates
ideas presented in previous works [
For the demo, we will use the simplified model of a loan assessment process shown in Fig. 3. To make the models executable, some code needs to be added, including: process variable definitions, solidity code for script tasks, and code specifying the exchange of information from/to user/service tasks. For example, one must specify the information an applicant must provide via the task Enter loan information. This is done by writing the following snippet in the BPMN documentation element under this task: (uint monthlyRevenue, uint loanAmount, uint propertyReferenceNumber) : (uint montlyRevenue, uint loanAmount, uint propertyReferenceNumber) > {montlyRevenue = montlyRevenue; loanAmount = loanAmount; propertyReferenceNumber = propertyReferenceNumber; } This snippet specifies that an applicant must provide the loan information, e.g. via a web form as shown in Fig. 2. The second part of the snippet is used to generate code that copies the information into process variables. Similar snippets are associated to the remaining tasks of the process model.
Assess Loan
Risk Appraise
Property Enter Loan Application
Assess Elegibility
Loan app accepted Loan app rejected
The source code of Caterpillar can be downloaded under the BSD 3-clause “New” or “Revised” License from https://github.com/orlenyslp/Caterpillar.5
Caterpillar’s code distribution contains three folders: (i) folder caterpillar core, which includes the implementation of the core components (engine, compilation tools, event monitor and work item manager); (ii) execution panel (implementation of the Execution Panel module); and (iii) services, which contains the implementation of the external services used in the demonstration. The repository contains all instructions needed to install the required dependencies and running the sample process model.
A screencast of Caterpillar can be found at https://youtu.be/zOmx5kD1Og0 . 5 The fourth author was not involved in the development or release of the Caterpillar software. Neither the publication of this paper nor the software release should be construed as granting any rights in relation to patents or patent applications held by CSIRO or by the authors of this paper.