Many companies rely on business process management systems for their digital transformation initiatives. Beyond visual modeling languages, there is a need for an executable modeling language with data processing support and powerful abstractions for development. To overcome this gap, we developed a process scripting language called Factscript. In this paper, we present the Factscript language environment and showcase its application.
Business Process Management Systems (BPMS) [
In order to overcome the mutual weaknesses of the di erent languages, we
developed a process scripting language, called Factscript [
In this paper, we present the language environment of Factscript. The language environment supports the user during the design of the processes in Factscript, deploys the processes to an external execution engine, and executes the processes. Furthermore, we present a real-world application scenario, composed of two interconnected processes, for Factscript and the language environment. In the following, we discuss the features of our scripting language and introduce the language environment.
IntelliJ Editor Factscript Modeler
Factscript Process Model
Get Constructs Factscript Construct Definitions
Execution R Translate Process Translator
Event
Execution Helper Listeners Transition Listener Activity Start Listener
External Task
Deploy Model Register Listener R
R Execute
Listener Get Task
Execution Engine
Process Repository
BPMN Process Model
Read Model Execution Engine
Request Task
Execution
External Task Queue
For the development of the Factscript, we identi ed four requirements [
The language environment is composed of four top-level entities: editor, translator, execution engine, and execution helper. The editor entity is used for scripting a process in Factscript by using the Factscript constructs and syntax. Depending on the editor, the scripting is supported by auto-completion and syntax checking. After the process is de ned, the translator entity is used to transform the Factscript process into a format that can be interpreted by the execution engine. Eventually, the execution engine executes the process. Dependent on the functionalities of the used execution engine, di erent execution helper functions are required. The particular implementation of these entities is independent of each other and can be based on di erent tools.
At the current development state, the implemented language environment
for Factscript uses IntelliJ IDEA for the editor, translator, and execution helper
entities. These entities are implemented using Kotlin. Camunda BPM is used as
execution engine . Figure 1 depicts the architecture of the current
implementation. The language environment, as well as the Factscript construct de nitions
and example processes, can be accessed online4 and in [
4https://github.com/factdriven (commit tag ER-2020-Demo).
In the following, we present a real-world application scenario, supplementary to the one presented in the screencast of the Factscript environment. The screencast can be accessed at https://youtu.be/WBs-nC1S8OI.
The application scenario is composed of two processes: The rst one is an
order process, and the second one a payment process that is used by the order
process. Listing 1.1 shows the order process and Listing 1.2 the payment process
de ned in Factscript. A description of the semantic and syntax of Factscript can
be found in [
Listing 1.1: Order Process in Factscript 24 emit failure event { PaymentFailed ( orderId ) } 25 } 26 } 27 until (" Payment fully covered ?") condition { covered == total } 28 } 29 } or { 30 otherwise (" Yes ") 31 emit success event { PaymentRetrieved ( orderId ) } 32 }
(a) Order Process in BPMN 2.0 (b) Payment Process in BPMN 2.0 The order process (Listing 1.1) performs the following steps: (1) The execution is triggered by a ful ll order event (lines 1-4). (2) At the beginning of the process execution, an order ful llment started event is emitted (line 5). (3) Subsequently, the ordered goods are fetched from the inventory, and, in parallel, the payment is retrieved via the separate payment process (lines 6-20). If the payment fails, a compensation is triggered that returns the goods to the inventory (lines 16-19). (4) After the goods are available and the payment is fully covered, an order ready to ship event is triggered, and the goods are shipped (lines 21-22). (5) The process ends with a Order ful lled event (line 23).
The payment process (Listing 1.2) performs the following steps: (1) The execution is triggered by a retrieve payment event, which is emitted by the Retrieve payment activity of the order process (lines 1-4). (2) After the execution is triggered, the money is withdrawn from the customer's account (lines 5-12). (3) If not all of the money can be withdrawn (line 13), the customer's credit card is charged (lines 14-29). (4) If the credit card of the customer is expired (line 19), the customer has two weeks to update the credit card details. After the two weeks, the payment process fails, and the already withdrawn money is credited to the customer's account (lines 18-26). (5) After charging the credit card, it is checked if the payment is fully covered (lines 13). If not, the credit card is charged again. (6) If the payment is fully covered (lines 29-32), the process signalizes its end with a payment retrieved event.
This application scenario shows a part of the rich spectrum of constructs that the Factscript language provides and the possibility to create real-world scenarios with them. 4
In this paper, we presented the language environment for Factscript. The language environment provides the means to script processes by using the Factscript constructs, then deploys the processes to an external execution engine that is then used to execute the process. At the current level of maturity, the Factscript already ful lls all four requirements discussed in Section 2. Furthermore, the language environment, with Camunda BPM as an execution engine, fully supports all Factscript constructs. Since the Factscript and execution engine are independent of each other, the execution engine can easily be exchanged. As future work, we integrate Factscript with Amazon AWS Step Functions as a process execution engine.
Acknowledgement The concept and design of the Factscript as well as its implementation in Kotlin was done by Martin Schimak, plexiti GmbH.
This research is partially funded by FFG (ref. no. 876062).