A CSPm Model for the Procure to Pay Case Study

Transcription

1 A CSPm Model for the Procure to Pay Case Study Andreas V. Hense Bonn-Rhein-Sieg University oas, Grantham-Allee 20, Sankt Augustin, Germany, 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 paradigm of YAWL is Petri nets. The underlying paradigm of S-BPM is Communicating 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 Explorer (ProBE 1 and the refinement checker FDR2 2 can be downloaded from our website download.html

2 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 communication 4. 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 > availcheck. Dumper > availanswer. true > appreq. Dumper > appanswer. true > purchaseorder. Dumper > d e l i v e r E q. Dumper > tock > tock > tock > tock > datereqsu > dateanswersu. 5 > s e n d I n v o i c e. Dumper > appinvreq > appinvanswer. true > payinvoice > 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 4 5. 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.

3 Fig. 1. Process overview of P2P 3

4 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 operator 7 which 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 : { minrent.. maxrent}@( to : { from.. maxrent}@( eqrentreq. eq. from. to > SE wait ( eq. from. to 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. SE wait (err = purchaseorder?eerr > SE expect (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. SE expect (eerr = d e l i v e r E q?eerr > SE rent (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 in CSP and by a sequence of three keyboard characters resembling in CSPm.

5 5 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. SE rent (eerr@@eq. p. s. from. to = ( appinvreq? frominv? toinv > appinvanswer. ( frominv==from and t o I n v==t o > SE [ ] ( datereqse > dateanswerse? d > ( i f ( d < to and to < maxrent then ( newto : { ( to maxrent}@( extreq. eq. p. s. from. newto > ( ( grantext? true > SE rent ( eq. p. s. from. newto [ ] ( grantext? f a l s e > SE rent ( eq. p. s. from. to e l s e SE rent ( eq. p. s. from. to 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. to > p : dailyprice@ ( s : supplier@ ( CL rec ( eq. p. s. from. to He then checks the availability with the supplier and goes to a waiting mode. CL rec (eerr = availcheck. 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 6 CL wait p. s. from. to = availanswer? : { true } > CL avail (eerr [ ] availanswer? : { f a l s e } > p : dailyprice@ ( s : supplier@ ( CL rec ( eq. p. s. from. to Depending on the approval of the equipment he selects a different solution from the catalogue and returns to mode CL rec or he proceeds. CL avail (eerr@@eq. p. s. from. to = appreq. eerr > ( appanswer? : { true } > CL app (eerr [ ] appanswer? : { f a l s e } > p : dailyprice@ ( s : supplier@ ( CL rec ( eq. p. s. from. to 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. to = purchaseorder. 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. to = s e n d I n v o i c e? eqinv? pinv? sinv? frominv? toinv? p r i c e > appinvreq. frominv. toinv > ( appinvanswer? : { true } > ( i f ( p r i c e==pinv ( toinv frominv +1 then ( payinvoice. sinv. p r i c e > CL

7 7 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 = ( availcheck?(eerr > ( availanswer. true > SU availanswer. f a l s e > SU [ ] ( purchaseorder?eerr > d e l i v e r E q. eerr > SU del (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. SU del (eerr@@eq. p. s. from. to = ( extreq?eerr > ( grantext. true > SU del (eerr grantext. f a l s e > SU del (eerr ( datereqsu > dateanswersu? d > ( i f (d>to and to>=from then ( s e n d I n v o i c e. eerr. ( p ( to from +1 > STOP e l s e SU del (eerr 2.4 The Other Processes The works engineer simply accepts or rejects any approval request he receives. WE = appreq?eerr > ( ( appanswer. true > WE

8 8 ( appanswer. f a l s e > WE The finance department simply pays any invoice upon request. FD = payinvoice? sinv? p r i c e > FD The date process has the current date as its internal mode. The date is incremented 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 = tock > ( i f i < maxdate then 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 processes defined in the last sections. The respective alphabets are defined in the supplementary material on our website 8. The parallel composition is shown in the next listing. P2P = ( ( ( (CL [ alphcl alphwe ] WE [ alphcl alphfd ] FD 8

9 9 [ alphcl alphsu ] SU [ alphcl and SU alphse ] SE [ alphcl and SU and SE alphdate ] 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. During 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 formalisation 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 The visualisation of these as a UML state diagram [7] is left as an exercise.

10 10 2. A. Fleischmann, S. Rass, and R. Singer. S-BPM illustrated: a storybook about business process modeling and execution A. V. Hense. CSPm models for the automated teller machine case study. In Special Session on Comparative Case Studies, Kiel, 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, submitted for publication. 5. A. V. Hense and R. Malz. Automation of the procure to pay case study with YAWL. In Special Session on Comparative Case Studies, Kiel, submitted for publication. 6. C. A. R. Hoare. Communicating sequential processes. Prentice/Hall International, Englewood Cliffs, N.J., OMG. OMG unified modeling language (OMG UML, superstructure, Aug Version A. W. Roscoe. The theory and practice of concurrency. Prentice Hall, London; New York, A. W. Roscoe. Understanding Concurrent Systems. Springer, London ; New York, A. H. M. ter Hofstede, W. M. P. van der Aalst, M. Adams, and N. Russell. Modern Business Process Automation: YAWL and its Support Environment. Springer, Berlin, 1 edition, S. Zenzaro. An ASM model for the ProcureToPay case study. In Special Session on Comparative Case Studies, Kiel, submitted for publication.