=Paper=
{{Paper
|id=Vol-2716/paper17
|storemode=property
|title=A Process Scripting and Execution Environment
|pdfUrl=https://ceur-ws.org/Vol-2716/paper17.pdf
|volume=Vol-2716
|authors=Maxim Vidgof,Philipp Waibel,Jan Mendling,Martin Schimak,Alexander Seik ,Peter Queteschiner
|dblpUrl=https://dblp.org/rec/conf/er/VidgofWMSSQ20a
}}
==A Process Scripting and Execution Environment==
https://ceur-ws.org/Vol-2716/paper17.pdf
Judith Michael, Victoria Torres (eds.): ER Forum, Demo and Posters 2020 173
A Process Scripting and Execution Environment
Maxim Vidgof1 , Philipp Waibel1 , Jan Mendling1 , Martin Schimak2 , Alexander
Seik3 , and Peter Queteschiner3
1
Institute for Information Business, WU Wien, Austria
{firstname.lastname}@wu.ac.at
2
Plexiti, Vienna, Austria martin.schimak@plexiti.com
3
Phactum, Vienna, Austria {firstname.lastname}@phactum.at
Abstract. Many companies rely on business process management sys-
tems 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 environ-
ment and showcase its application.
Keywords: Process Modelling · DSL · Kotlin · Factscript
1 Introduction
Business Process Management Systems (BPMS) [3] support the implementation
of specific processes. Several BPMS solutions and languages have been proposed
in the past, e.g., BPMN [1], BPEL [4], Netflix Conductor or Uber Cadence,
each with strengths and weaknesses. While BPMN supports important control
flow patterns, it does not support proper data processing on the visual level.
On the other hand, languages like Netflix Conductor are process programming
languages with data processing support but are missing important abstractions.
In order to overcome the mutual weaknesses of the different languages, we
developed a process scripting language, called Factscript [6] and supportive tools.
Factscript is an executable, code-efficient, domain-specific language (DSL) that
builds on the strengths of different process languages.
In this paper, we present the language environment of Factscript. The lan-
guage 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, com-
posed of two interconnected processes, for Factscript and the language environ-
ment.
2 Language Environment
In the following, we discuss the features of our scripting language and introduce
the language environment.
Copyright © 2020 for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
174 M. Vidgof et al.
IntelliJ
Editor Factscript Modeler Execution Engine
Factscript Process Model
Deploy Model Process Repository
Get Constructs R Translate Process BPMN Process Model
Factscript Translator
Construct Execution Event Read Model
Register Listener
Definitions
On Task Execution Engine
Select Gateway R R
Execution Helper Request Task
Execute Execution
Listeners Transition Listener Activity Start Listener Listener
External Task External Task Queue
Get Task
Fig. 1: Implementation Architecture
For the development of the Factscript, we identified four requirements [6]:
(R1) efficient syntax, (R2) extensive control flow support, (R3) support of data
processing, and (R4) support of event processing. We followed the seven phases
of DSL development [2,5], which helped us to generate an efficient syntax (R1).
For (R2) we analyzed process modeling languages and their control flow support.
For extensive control flow support [8], we refer to BPMN. For data processing
(R3), we identify type safe variables and their manipulation directly in the pro-
cess definition as important. For (R4) we opted for BPEL as a basis with its
different message interaction possibilities [7]. Factscript, therefore, provides dif-
ferent constructs that permit a similar message interactions as BPEL does.
The language environment is composed of four top-level entities: editor, trans-
lator, execution engine, and execution helper. The editor entity is used for script-
ing a process in Factscript by using the Factscript constructs and syntax. De-
pending on the editor, the scripting is supported by auto-completion and syntax
checking. After the process is defined, 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, different execution helper functions
are required. The particular implementation of these entities is independent of
each other and can be based on different 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 implementa-
tion. The language environment, as well as the Factscript construct definitions
and example processes, can be accessed online4 and in [6].
4
https://github.com/factdriven (commit tag ER-2020-Demo).
A Process Scripting and Execution Environment 175
3 Application Scenario
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 first 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
defined in Factscript. A description of the semantic and syntax of Factscript can
be found in [6]. Figures 2a and 2b present the processes in BPMN 2.0.
Listing 1.1: Order Process in Factscript
1 on command FulfillOrder :: class emit {
2 success event Order Fulfille d :: class
3 failure event O r d e r N o t F u l f i l l e d :: class
4 }
5 emit event { O r d e r F u l f i l l m e n t S t a r t e d ( orderId , accountId , total ) }
6 execute all {
7 execute command {
8 F e t c h G o o d s F r o m I n v e n t o r y ( orderId )
9 } but {
10 on failure O r d e r N o t F u l f i l l e d :: class
11 execute command { R e t u r n G o o d s T o I n v e n t o r y ( orderId ) }
12 }
13 } and {
14 execute command {
15 R et ri ev e Pa ym en t ( orderId , accountId , total )
16 } but {
17 on failure PaymentFailed :: class
18 emit failure event { O r d e r N o t F u l f i l l e d ( orderId ) }
19 }
20 }
21 emit event { O r d e r R e a d yT o S h i p ( orderId ) }
22 execute command { ShipGoods ( orderId ) }
23 emit success event { Orde rFulfill ed ( orderId ) }
Listing 1.2: Payment Process in Factscript
1 on command Re t ri ev eP a ym en t :: class emit {
2 success event P a y m e nt R e t r i e v e d :: class
3 failure event PaymentFailed :: class
4 }
5 execute command {
6 W i t h d r a w A m o u n t F r o m C u s t o m e r A c c o u n t ( customer = accountId , withdraw = total )
7 } but {
8 on failure PaymentFailed :: class
9 execute command {
10 C r e d i t A m o u n t T o C u s t o m e r A c c o u n t ( customer = accountId , credit = covered )
11 }
12 }
13 select (" Payment fully covered ?") either {
14 given (" No ") condition { covered < total }
15 repeat {
16 execute command {
17 C h a r g e C r e d i t C a r d ( orderId , total - covered )
18 } but {
19 on failure C r e d i t C a r d E x p i r e d :: class
20 await first {
21 on event C r e d i t C a r d D e t a i l s U p d a t e d :: class having " accountId " match {
accountId }
22 } or {
23 on time duration (" Two weeks ") { " PT5M " }
176 M. Vidgof et al.
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 { P a y m e n t R e t ri e v e d ( orderId ) }
32 }
(a) Order Process in BPMN 2.0
(b) Payment Process in BPMN 2.0
Fig. 2: Order and Payment Process in BPMN 2.0
The order process (Listing 1.1) performs the following steps: (1) The execution
is triggered by a fulfill order event (lines 1-4). (2) At the beginning of the process
execution, an order fulfillment 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 fulfilled 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.
A Process Scripting and Execution Environment 177
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 Conclusion
In this paper, we presented the language environment for Factscript. The lan-
guage 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 fulfills all four requirements discussed in Section 2. Furthermore, the lan-
guage environment, with Camunda BPM as an execution engine, fully supports
all Factscript constructs. Since the Factscript and execution engine are inde-
pendent 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).
References
1. Business process model and notation (bpmn) version 2.0. Tech. rep. (2011)
2. Ceh, I., Crepinsek, M., Kosar, T., Mernik, M.: Ontology driven development of
domain-specific languages. Comp. Sci. Inf. Syst. 8(2), 317–342 (2011)
3. Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A.: Fundamentals of Business
Process Management, Second Edition. Springer (2018)
4. Jordan, D., Evdemon, J., Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B.,
Curbera, F., Ford, M., Goland, Y., et al.: Web services business process execution
language version 2.0. Tech. rep. (2007)
5. Mernik, M., Hrncic, D., Bryant, B.R., Javed, F.: Applications of Grammatical Infer-
ence in Software Engineering: Domain Specific Language Development. In: Scientific
Applications of Language Methods, vol. 2, pp. 421–457 (2010)
6. Vidgof, M., Waibel, P., Mendling, J., Schimak, M., Seik, A., Queteschiner, P.: A
Code-efficient Process Scripting Language. In: ER Conference Proceedings) (2020)
7. Weidlich, M., Decker, G., Großkopf, A., Weske, M.: BPEL to BPMN: the myth of a
straight-forward mapping. In: On the Move to Meaningful Internet Systems: OTM.
Lecture Notes in Comp. Sci., vol. 5331, pp. 265–282. Springer (2008)
8. Wohed, P., van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H., Russell, N.: On
the suitability of bpmn for business process modelling. In: Int. Conf. on business
process management. pp. 161–176. Springer (2006)