The Create transition

As in classical Petri nets, the dynamics of CP-Nets come from transitions (represented as rectangles). Places in CP-Nets are linked to transitions via input and output arcs. Input arcs indicate that a particular transition may remove (consume) tokens from a particular

6.2 A CP-Net-based Execution Model 51 logs(e::es,eh) parent newcid cid aid+1 aid cs at coordinator eh 1`parent ++ create(a,e) Create [businessIDs(at,cs,cid)=SOME(bidcs,newcs,newcid), isParent(parent,at,bidcs,cs), started(parent), canCoordinate(coordinator,a,parent), requestCreate(aid,at,bidcs,newcs,parent,coordinator, cs,eh)=SOME(a,e::es)] conceptID ConceptId initConceptId() CONCEPTid activityID initActivityId() ACTIVITYid activitytype initActivityType() ACTIVITYTYPE activity rootActivity() ACTIVITY eventhistory [] EVENTLIST agent initAgents() AGENT businessfacts initFacts() FACTLIST

Figure 16: A CP-Net model of the Create transition

place, whereas a output arcs indicate that a transition may add (produce) tokens to a particular place. Informally, a CP-Net transition may fire (fire rule) when on each input place a required number of tokens can be found that together satisfy the guard condition of that transition. As a result of firing, a transition consumes a number of tokens on each input place and produces a number of tokens on each output place. The value and amount of tokens consumed and produced in place can be manipulated through the use of arc expressions.

TheCreate transition, depicted in Figure 16, is one of the most complex transitions in an activity life cycle as it involves many aspects:

• the determination of the activity type • the determination of the activity identifiers • the determination of the parent activity

• the determination of the agent who coordinates the activity • establishing whether the activity can be created

• logging the creation of an activity as an event in the event history In the remainder of this section these aspects are discussed consecutively.

The determination of the activity type of the activity that is about to be created can be modeled by consuming and producing anACTIVITYTYPEtoken from the activitytypeplace and binding it to the variable at. As the same token is consumed and produced by the createtransition, the incoming and outgoing arc are replaced by a bidirectional arc, that is both an input and an output arc. Because the ACTIVITYTYPE token is not timed, it can be consumed at the same modeling time for the creation of other activities. This pattern applies to the whole CP-Net, such that it allows for the desired behavior that activity state transitions can occur concurrently.

In the EM-BrA2CE Vocabulary activities have two identifiers: a non-business identifier and a business identifier. The determination of a non-business identifier is modeled using the “ID Manager” Pattern (Mulyar and van der Aalst, 2005). Initially theactivityID place stores one token with an integer value determined byinitActivityID(). Each time the Create transition fires, the token is consumed and used as an identifier for the activity to be created. In addition, the incremented integer value is produced on the output arc. By

6.2 A CP-Net-based Execution Model 52

incrementing and memorizing the last identifier value, the uniqueness of the non-business identifier can be guaranteed.

The determination of an activity business identifier is more complex as it involves real-world business concepts. In some cases, the creation of a activity will (in part) involve the creation of a new business concept whilst in other cases the creation of an activity only involves the identification of existing business concepts. For instance, when a customer applies for credit, the activityapplyForCredit might be identified by a new business concept of typecreditApplicationrepresenting the new credit application. In contrast, when a cus- tomer wants to modify the requested duration of the credit, the activityrequestChangemight be identified by the already existingcreditApplicationbusiness concept. This complexity is encapsulated within the guard condition businessIDs(at,cs,cid)= SOME(bidcs,newcs,newcid). The functionbusinessIDs(at,cs,cid)takes as input the variableat, a list of existing business concepts, bound to the variablecs and a unique identifier for new business concepts to be created, bound to variable cid. On its output the businessIDs either returns NONE when it fails to determine suitable business identifiers or a triple SOME(bidcs,newcs,newcid) with respectively the existing and newly generated business concepts andnewcidwith a properly incremented value ofcid.

Some activities can exist only within the life cycle of a (composite) parent activity, whereas other activities can also be created independent from a parent activity. The latter activities have rootActivity as their immediate parent. The logic of determining a proper parent for an activity to be created is encapsulated in the isParent(parent,at,bidcs,cs) guard condition. The input variableparentis bound to anACTIVITYtoken from theactivity place. Additionally, for a child activity to be created, it required that the coordinating parent activity has already started. This is expressed with the started(parent)guard con- dition.

Upon creation of an activity is is unclear who will eventually perform the activity until an activity is assigned to a particular agent. Until that period, the accountability for an activity can be attributed to the coordinating agent (human or system) who has created the activity. In order to determine the coordinating agent an AGENT token is consumed and produced from the agent place and bound to the coordinator variable. When activities are created within the context of a parent activity, the agent assigned to the parent activity is also the coordinator of the new child activity. For instance, when agentXhas been assigned to the parent activityhandleCreditApplicationhe is also identified as the coordinator of a newly created child activity reviewCredit. When, in contrast, an activity has therootActivityas parent, an agent can only create an activity when it has to role of an agent who can coordinate the particular activity. This logic is concealed in the canCoordinate(coordinator,a,parent) guard condition.

Additionally, a set of domain-specific business rules might determine whether the spec- ified activity can be created or not. The guard condition

requestCreate(aid,at,bidcs,newcs,parent,coordinator,cs,eh)=SOME(a,e::es)

is a hook that allows for the evaluation of business rules to check whether an activity with the specified features can be created. The creation of an activity might depend on the evaluation of strict business rules (hard constraints) and upon the freedom of choice of agents not to follow general guidelines (soft constraints) with regard to the creation of a particular activity. When no activity is to be created the function returns either NONE resulting in a failure of the guard condition or SOME(a,e::[]) for which e is bound to an event of typecreateRejected. When on the contrary an event must be created the function returns SOME(a,e::es). In this case a is bound to a new activity token that is produced in place activity. In addition,e is bound to an event of typecreated and es represents a list

6.2 A CP-Net-based Execution Model 53 1`parent++schedule(a,e,d) log(e,eh) eh cs 1`a++1`parent coordinator Schedule [active(a), hasParent(a,parent), d <= dueDate(parent), canCoordinate(coordinator,a,parent), requestSchedule(a,parent,coordinator,cs,eh,d)=SOME(e)] activity rootActivity() ACTIVITY eventhistory [] EVENTLIST agent initAgents() AGENT businessfacts initConcepts() FACTLIST

Figure 17: A CP-Net model of the schedule transition

of events that represents the newly created business concept identifiers (if any). The arc expression 1‘parent ++ create(a,e)returns the parent token and, in the case of a successful created event, a new activity token a. This activity token also receives a token time that indicates the earliest time at which another activity state transition can occur. In this way, time can be incorporated into the model. The eventsesare added as transaction events to the newly created activity. Only when the activity completes these transaction events are committed and affect the list of business concepts and facts cs.

Via the arc expressionlogs(e::es,eh)multiple events related to theCreatetransition are incorporated in the event history, bound to the variable eh. The event e is of the event type created or createRejected. Additionally, the events es, related to the newly created identifying business concepts also need to be added to the event history.