Study
Andreas V. Hense
Bonn-Rhein-Sieg University oAS, Grantham-Allee 20, 53757 Sankt Augustin, Germany, andreas.hense@brsu.de
Abstract. The model presented here is part of a comparative evaluation
effort of paradigms and tools for business process modelling. The model is written in CSPm – a machine readable dialect of CSP – and covers the case study ”Procure to Pay” (P2P) [1]. This paper shows the step by step development of the P2P case study using CSPm. We use the refinement notion of CSP to show which communications are possible.
1
Introduction
The case study Procure to Pay (P2P) [1] is a typical business process that can be automated using a workflow management system. In another article of this comparative evaluation effort [4] we have shown how to automate P2P using the workflow managment system YAWL [10]. We have also shown [5] how to automate P2P using the S-BPM method [2].
Like YAWL, S-BPM is a full-fledged workflow system. The underlying para-digm of YAWL is Petri nets. The underlying parapara-digm of S-BPM is Communicat-ing Sequential Processes (CSP) [6]. We have built the model for P2P with CSP [6] or more precisely with the machine-readable version of CSP called CSPm [8, 9] because we wanted to see the differences between S-BPM and CSP and the essence of the P2P case study compared to the ATM case study [3].
CSPm is not a workflow management system but a formal calculus. CSPm has a notion of refinement that can be checked automatically. In order to keep the models at a reasonable size and to be able to use the refinement checker, some simplifications were necessary. The greatest simplification is that our model describes only one case of the business process. The functionality of a workflow management system of handling different cases and distributing the work to different participants is not contained in our model.
The complete CSPm source code for use with the Process Behaviour Ex-plorer (ProBE1) and the refinement checker FDR22 can be downloaded from our website3. 1 http://www.fsel.com/probe download.html 2 http://www.cs.ox.ac.uk/projects/concurrency-tools/ 3 http://www.bis.inf.fh-bonn-rhein-sieg.de/bpmcasestudies
2
2
Procure to Pay
In the case study P2P, a site engineer wants to rent some equipment. Together with other participants of his organisation, the equipment is ordered for rental and finally payed for.
The process contains five roles: a site engineer (SE), a clerk (CL), a supplier (SU), a works engineer (WE), and the finance department (FD). Following the recommendations of the S-BPM method [2] we start with a process overview showing the processes and their communication. The process overview in figure 1 shows processes and their communication4. It contains processes for each of the roles mentioned above. Furthermore, there is a process for the date because an extension request can only be issued one or two days before the end of the rental period. The CSPm model of P2P models the process for one process instance or one case.
A an example for a simple run through the process in CSPm syntax is shown in the following listing:
Listing 1.1.Simple P2P usage scenario
SIMPLE = eqRentReq . Dumper . 4 . 4 −> a v a i l C h e c k . Dumper . 1 . 2 . 4 . 4 −> a v a i l A n s w e r . t r u e −> appReq . Dumper . 1 . 2 . 4 . 4 −> appAnswer . t r u e −> p u r c h a s e O r d e r . Dumper . 1 . 2 . 4 . 4 −> d e l i v e r E q . Dumper . 1 . 2 . 4 . 4 −> t o c k −> t o c k −> t o c k −> t o c k −> dateReqSU −> dateAnswerSU . 5 −> s e n d I n v o i c e . Dumper . 1 . 2 . 4 . 4 . 1 −> appInvReq . 4 . 4 −> appInvAnswer . t r u e −> p a y I n v o i c e . 2 . 1 −> STOP
The site engineer requests a dumper for day 4 (days are a subset of integer numbers and the equipment rental request has the start and end day as its two last parameters). The clerk looks up a catalogue and asks supplier number 2 if the dumper with a price of 1 is available from day 4 until day 45. After receiving a positive answer from the supplier, he asks the works engineer for approval. After receiving the approval, he sends a purchase order to the supplier who in turn delivers the equipment to the site engineer.
We had started at day one. Now we advance the clock by four days using ”tock”. The supplier now asks for the date and sees that the rental is over.
4 In S-BPM processes are called subjects [2] 5
The data domains had to be kept to a mininum in order to achieve acceptable runtimes of the refinement checker.
4
He can now send an invoice with cost 1 to the clerk. The clerk asks the site engineer if the equipment has really been rented from day 4 until day 4. After a positive answer he checks that the price has been calculated correctly and pays the invoice.6
This concludes the simple scenario of what may happen in P2P. We will now proceed with the definition of the processes that make such a scenario possible.
2.1 The Site Engineer
The process of the site engineer is called SE and is contained in the following listing. There are three uses of the internal choice operator7which read as follows: the site engineer nondeterministically chooses an equipment, a from-date, and a to-date. Then he sends a corresponding equipment rental request and goes to a ”waiting mode” called SE wait. The waiting mode is parameterised with the equipment and the two dates. Since CSPm is essentially functional programming plus communication this is the way to ”remember” these parameters.
SE = |˜|eq : eqType@ ( |˜|from :{m i n r e n t . . maxrent}@( |˜|t o :{from . . maxrent}@( eqRentReq . eq . from . t o −> S E w a i t ( eq . from . t o ) ) ) )
While the site engineer is in the waiting mode, two things can happen: either he receives a ”copy” of the purchase order from the clerk and goes to mode ”SE expect” or he cancels the equipment rental request and goes back to the initial mode ”SE”.
S E w a i t (eRR) =
p u r c h a s e O r d e r ?eeRR −> S E e x p e c t ( eeRR )
[ ] c a n c e l −> SE
In the expecting mode, the site engineer waits for a message that the equipment has been delivered and goes to a renting mode.
S E e x p e c t ( eeRR ) = d e l i v e r E q ?eeRR −> S E r e n t ( eeRR )
6
The visualisation of this simple run as a UML sequence diagram [7] is left as an exercise.
7
The internal choice is denoted by u in CSP and by a sequence of three keyboard characters resemblinguin CSPm.
While the site engineer is in the renting mode, two things can happen. He may get a request from the clerk to approve the dates of an invoice sent previously by the supplier. Or he asks for an extension of the rental period. The latter is only possible before the end date of the rental. The extension request may be rejected by the supplier.
S E r e n t ( eeRR@@eq . p . s . from . t o ) = ( appInvReq ? f r o m I n v ? t o I n v −>
appInvAnswer . ( f r o m I n v==from and t o I n v==t o ) −> SE ) [ ] ( dateReqSE −> dateAnswerSE ?d −> ( i f ( d < t o and t o < maxrent ) t h e n ( |˜|newto :{( t o + 1 ) . . maxrent}@( extReq . eq . p . s . from . newto ) −> ( ( g r a n t E x t ? t r u e −> S E r e n t ( eq . p . s . from . newto ) ) [ ] ( g r a n t E x t ? f a l s e −> S E r e n t ( eq . p . s . from . t o ) ) ) ) e l s e S E r e n t ( eq . p . s . from . t o ) ) ) 2.2 The Clerk
When the clerk receives an equipment rental request from the site engineer he looks up the catalogue and extends the equipment rental request by a daily price and a supplier. CL = eqRentReq ? ( eq . from . t o ) −> |˜|p : d a i l y P r i c e @ ( |˜|s : s u p p l i e r @ ( CL rec ( eq . p . s . from . t o ) ) )
He then checks the availability with the supplier and goes to a waiting mode. CL rec ( eeRR ) =
a v a i l C h e c k . eeRR −> CL wait ( eeRR )
If the equipment chosen is not available, the clerk selects a different solution from the catalogue and returns to the previous mode. If the equipment is available he goes to a mode called ”CL avail”.
6
CL wait ( eeRR@@eq . p . s . from . t o ) = a v a i l A n s w e r ? :{t r u e} −> C L a v a i l ( eeRR ) [ ] a v a i l A n s w e r ? :{f a l s e} −> |˜|p : d a i l y P r i c e @ ( |˜|s : s u p p l i e r @ ( CL rec ( eq . p . s . from . t o ) ) )
Depending on the approval of the equipment he selects a different solution from the catalogue and returns to mode ”CL rec” or he proceeds.
C L a v a i l ( eeRR@@eq . p . s . from . t o ) = appReq . eeRR −> ( appAnswer ? :{t r u e} −> CL app ( eeRR ) [ ] appAnswer ? :{f a l s e} −> |˜|p : d a i l y P r i c e @ ( |˜|s : s u p p l i e r @ ( CL rec ( eq . p . s . from . t o ) ) ) )
Before sending the purchase order to the supplier he can receive a cancel request from the site engineer. This was one requirement of the case study.
CL app ( eeRR@@eq . p . s . from . t o ) = p u r c h a s e O r d e r . eeRR −> CL ord ( eeRR )
|˜| c a n c e l −> CL
In the next step, he receives an invoice from the supplier. As the clerk has not been informed of a possible extension of the rental period he asks the site engineer for the approval of the dates in the invoice. After that he checks if the calculation of the total is correct and tells the finance department to pay the invoice.
CL ord ( eeRR@@eq . p . s . from . t o ) = s e n d I n v o i c e ? e q I n v ? pInv ? s I n v ? f r o m I n v ? t o I n v ? p r i c e −> appInvReq . f r o m I n v . t o I n v −> ( appInvAnswer ? :{t r u e} −> ( i f ( p r i c e==pInv∗( t o I n v−f r o m I n v +1)) t h e n ( p a y I n v o i c e . s I n v . p r i c e −> CL)
e l s e CL )
[ ] appInvAnswer ? :{f a l s e} −> CL )
2.3 The Supplier
The supplier waits for an availability check or a purchase order. If he gets a purchase order he goes to the next mode.
SU = ( a v a i l C h e c k ? ( eeRR ) −> ( a v a i l A n s w e r . t r u e −> SU |˜| a v a i l A n s w e r . f a l s e −> SU) ) [ ] ( p u r c h a s e O r d e r ?eeRR −> d e l i v e r E q . eeRR −> S U d e l ( eeRR ) )
In the next mode he can receive an extension request. He can also ask for the date and send an invoice if the rental period is over.
S U d e l ( eeRR@@eq . p . s . from . t o ) = ( extReq ?eeRR −> ( g r a n t E x t . t r u e −> S U d e l ( eeRR ) |˜| g r a n t E x t . f a l s e −> S U d e l ( eeRR ) ) ) |˜|( dateReqSU −> dateAnswerSU ?d −> (
i f ( d>t o and to>=from )
t h e n ( s e n d I n v o i c e . eeRR . ( p∗( to−from +1)) −> STOP)
e l s e S U d e l ( eeRR ) )
)
2.4 The Other Processes
The works engineer simply accepts or rejects any approval request he receives. WE = appReq ?eeRR −> (
8
|˜| ( appAnswer . f a l s e −>WE) )
The finance department simply pays any invoice upon request. FD = p a y I n v o i c e ? s I n v ? p r i c e −>
FD
The date process has the current date as its internal mode. The date is incre-mented upon ”tock” messages from the environment up to a maximal value. When asked the date by the supplier or the site engineer it answers with the current date. Date = D( 1 ) D( i ) = t o c k −> ( i f i < maxdate t h e n D( i +1) e l s e D max ( i ) ) [ ] ( dateReqSE −> dateAnswerSE . i −> D( i ) ) [ ] ( dateReqSU −> dateAnswerSU . i −> D( i ) )
Once the date has reached the maximal value, the date process in mode D max does not accept any more ”tock” messages from the environment but still answers date requests by the site engineer or the supplier.
D max ( i ) = ( dateReqSE −> dateAnswerSE . i −> D( i ) ) [ ] ( dateReqSU −> dateAnswerSU . i −> D( i ) )
2.5 The Procure to Pay Process
The complete process is created by alphabetised parallel composition of all pro-cesses defined in the last sections. The respective alphabets are defined in the supplementary material on our website8. The parallel composition is shown in the next listing.
P2P = ( ( ( ( CL [ alphCL| |alphWE ] WE ) [ alphCL| |alphFD ] FD
8
) [ alphCL| |alphSU ] SU
) [ alphCL and SU| |alphSE ] SE
) [ alphCL and SU and SE| |a l p h D a t e ] Date
We can now prove that the scenario of listing 1.1 is indeed a behaviour of the P2P process.
a s s e r t P2P [ T= SIMPLE
2.6 Conclusion
We have started the modelling effort with the process overview in figure 1. Dur-ing the definition of the CSP processes many questions arose that would have been answered by subject matter experts in real life. The description of the case study P2P [1] fits on one page and cannot be a complete specification for the automation of the P2P process. Eliciting additional requirements during formal-isation of a problem happens in every software project.
The CSP specification that contains approximately 300 lines of code shows the following characteristics. The site engineer and the clerk are the central roles. The process definition of the site engineer consists of four mutually recursive equations that correspond to modes. These modes correspond to the states of the site engineer in [11].
The clerk has six modes.9 These modes correspond to the states of the site engineer in [11]. The internal state information that these processes need is an extended equipment rental request.
From the process definitions it is easy to derive UML sequence diagrams [7]. The tool ProBE allows us to explore all possible traces and FDR2 does trace refinement checks among others. The trace refinement checks can be used in this example for verifying if certain runs are possible.
It is relatively easy in CSP to inadvertedly produce deadlocks or livelocks during process definitions. FDR2 can check for the presence of these and give concrete traces that lead to a dealock or livelock. This feature was useful during the development of our model.
The automatic checking comes at a price: all data domains have to be finite and be of small cardinality in order to cope with combinatorial explosion.
One important aspect of the problem, namely the resource perspective, has not been modelled. The model contains only one case. Distributing the work to different participants with the same role etc. is therefore not part of the model. In this respect the model is much less complete than the CSP model of the ATM case study [3].
References
1. M. Dumas, M. L. Rosa, J. Mendling, and H. A. Reijers.Fundamentals of Business Process Management. Springer Berlin Heidelberg, Jan. 2013.
9
10
2. A. Fleischmann, S. Rass, and R. Singer. S-BPM illustrated: a storybook about business process modeling and execution. 2013.
3. A. V. Hense. CSPm models for the ”automated teller machine” case study. In Special Session on Comparative Case Studies, Kiel, 2015. submitted for publication. 4. A. V. Hense and R. Malz. Automation of the ”automated teller machine” case study with YAWL. In Special Session on Comparative Case Studies, Kiel, 2015. submitted for publication.
5. A. V. Hense and R. Malz. Automation of the ”procure to pay” case study with YAWL. InSpecial Session on Comparative Case Studies, Kiel, 2015. submitted for publication.
6. C. A. R. Hoare.Communicating sequential processes. Prentice/Hall International, Englewood Cliffs, N.J., 1985.
7. OMG. OMG unified modeling language (OMG UML), superstructure, Aug. 2011. Version 2.4.1.
8. A. W. Roscoe. The theory and practice of concurrency. Prentice Hall, London; New York, 1998.
9. A. W. Roscoe.Understanding Concurrent Systems. Springer, London ; New York, 2010.
10. A. H. M. ter Hofstede, W. M. P. van der Aalst, M. Adams, and N. Russell. Mod-ern Business Process Automation: YAWL and its Support Environment. Springer, Berlin, 1 edition, 2010.
11. S. Zenzaro. An ASM model for the ProcureToPay case study. InSpecial Session on Comparative Case Studies, Kiel, 2015. submitted for publication.
