CHAPTER 8: BUSINESS PROCESS MANAGEMENT
8.1 I NTRODUCTION
Business process management is related with the execution and management of shared business processes across different administrative domains. The management of business processes is performed in a autonomous and distributed way and is fully performed by autonomous intelligent mobile agents without human intervention.
The execution of a shared business process starts by the end-user of the VE. The main operations that this role performs are:
• log into the web site of the VE representative that provides the shared business processes by using a standard web browser,
• execution of a shared business process and monitor of the status of the running process,
• management of a shared business process, i.e. suspension, resumption, or termination of a running business process.
In addition to the above user initiated operations, the following situations occur. When a running business process is completed, the results of the process, i.e. the output parameters of it, are returned to the user automatically. Furthermore, If during the execution of a process a problem occurs, then the process is aborted and the user is notified about this fact.
The execution and management of shared business processes, in the context of dynamic VEs, are performed from the following autonomous, intelligent, FIPA compliant agents.
• Personal User Agent (PUA) responsible for managing the requests of the end-users coming from the standard web browsers. This agent is located on the VE representative domain. Every user request is checked for authorization and then is forwarded to the Domain Representative agent (DR).
• Domain Representative (DR) responsible for managing the requests of the PUA, if the domain plays the role of the VE representative and the requests of the remote domains, if the domain plays the role of the VE partner. In both cases, the DR authenticates the requests by conducting the Contract Repository. If the request is an authorized one and is related to the instantiation of a new process, the DR creates a Workflow Provider Agent (WPA) that will serve the request, otherwise the corresponding existing WPA is located and the request is forwarded to him,
• Workflow Provider Agent (WPA) responsible for executing and managing an instance of a process or sub-process. The WPA replies to requests coming from the DR or informs the DR about the status of the process that it executes. Additionally, the WPA co-operates in an autonomous way with other WPAs during the execution of the business processes. Finally, the WPA controls the execution of atomic processes involved into the business process by invoking, requesting, or informing different Resource Provider Agents (RPA),
• Resource Provider Agent (RPA) responsible for carrying out one specific atomic process of the business process. One atomic process is a simple elementary processing unit that can be included into one or more business processes. An RPA agent always deploys existing resources or business objects provided by the domain in a distributed and interoperable way.
• Requestor Negotiation Agent (RNA) responsible for managing the partner search, negotiation, and selection process. When a WPA realizes that a remote process is required for the continuation of the currently executed business process, it creates automatically a RNA agent. This agent migrates to the virtual marketplace, selects the potential VE candidate partners, based on some constraints, and starts a negotiation process with them.
The result of the negotiation is an electronic contract that regulates this agreement.
• Provider Negotiation Agent (PNA) represents a VE candidate domain during the negotiation process and is responsible for the automated negotiations with other RNAs.
Additionally, PNAs manage the business process registration to the virtual marketplace and update the contract repository when a negotiation process has been successfully ended, i.e. a contract has been agreed upon.
Based on the above definitions, the reference architecture of the VE representative or the VE partner domain is depicted in the Figure 44.
Distributed Processing Environment Agent Platform &
Supporting Services
Grasshopper Mobile Agent Platform
Business Objects
&
Lecagy Services WPA
FIPA Add On
RPA DR
Distributed Processing Environment
ACC
AMS DF X
M L
PNA RNA
Business Process Repository Contract
Repository
Offer Repository PUA
Figure 44: Business Process Specification, Registration, and Management Reference Architecture
In general, a business process consists of sub-processes. Each sub-process consists of one or more sub-processes or one atomic process. For a given process, the father of this sub-process is called the super-process while a child of the process is called the sub-process. Every sub-process has one and only one super process and one ore more sub-processes. On the contrary, an atomic process has one super process and no one sub-processes. This hierarchical organization of processes and sub-processes leads to the formation of a directed graph.
Based on the operations provided to the user, a business process can be in different states. The different states of a business process are:
• ready, after the instantiation of the process and before the execution of it,
• running, during the execution of the process,
• suspended, when the process has been suspended by the user or other super process,
• resumed or running, when the process were previously suspended and has now been resumed,
• completed when the execution has been completed,
• terminated when the initiator of the process has requested to terminate the process,
• aborted when the process, sub-process, or an atomic process has declared that it can not perform its operation and thus it aborts itself.
The following state transition diagram reveals the different states and how the process can change states. The nodes in the diagram denote the states while the arrows represent transitions from one state to the other. The messages on the arrows represent the events that might trigger the transition of the process from one state to the other. The dotted arrows reveal that the process it self, without any external intervention, can transit from one state to other. This means that when a process has be en completed then it moves automatically, without any external intervention, to the terminated state. In a similar way, when a process has been aborted, it automatically moves into the aborted state. In all other cases, the process changes status after an external event generated by the end-user or the super process.
terminate abort
terminate complete
abort resume suspend ready run running
suspended
terminated aborted
completed
Figure 45: Process State Transition Diagram
When a process or sub-process changes state, then all the sub-processes should be informed accordingly. Therefore, when a business process is suspended, then all the running sub-processes and atomic processes should be suspended as well. In a similar way, when a process is resumed,
all the sub-process that have been suspended previously should also be resumed. Finally, if a process is aborted, then the execution of this process cannot be continued. In this case, the whole execution of the process should be aborted, i.e. all the sub-processes and atomic processes should also be aborted.
For example, when a request for suspension is arriving to a process, the process requests from its sub-processes to suspend. The sub-processes request from their sub-processes to suspend and so on. When the final level of processes within the same process is reached, then these sub-processes are suspended and they inform their super-sub-processes about their suspended state.
When all the sub-processes of a process reported that they suspended, then the process can also suspend and inform its super-process. The similar phenomenon occurs and in the case of resumption, completion and termination. The lowest level sub-processes are completed or terminated first and then the highest levels complete or terminate one by one until the initial starting process is reached. Finally, the process informs the end-user about its current state or results.
However, in the case of abortion, the algorithm is working in a different way. If one sub-process cannot continue its operation, it informs its super-process and then aborts. When the super process receives an abort message from one of its sub-processes, it requests from the other remaining sub-processes to abort. When all the sub-processes have been aborted, then the process informs its super process about this fact and finally aborts. If a super process receives an abort message, it functions in a similar way. The whole procedure is continuing until the initial process aborts and reports its state to the end-user.
In general, the following conditions are hold for the status of a process:
• a process is running when all of its sub-processes and atomic processes are running,
• a process is suspended when all of its sub-processes and atomic processes are suspended,
• a process is resumed or running again when all of its sub-processes and atomic processes are suspended,
• a process is terminated when all of its sub-processes and atomic processes are terminated,
• a process is aborted when at least one of the sub-processes or atomic processes is aborted,
• a process is completed when all of its sub-processes and atomic processes are completed.
This back tracking alterations on process and sub-processes status are depicted in the following Figure 46. The numbers on the arrows depict the order that the events occur while the direction the requestor and the receiver.
10:suspended
9:suspended 8:suspended
7:suspended 6:suspended
5:suspended
4:suspend 3:suspend
2:suspend 2:suspend
1:suspend
3: suspend
Figure 46: Process Status Mechanism
For every running business process a process instance is instantiated. This means that different instances of the same process can be executed and managed. Every instance of a process has a unique process id that differentiates it from the others. Although all of these instances are instantiated based on the definition of the business process, they are different due to the different input values that the users have provided for them. Therefore, a process instance is, in a similar way to object oriented systems, an object while a business process definition is the class specification. Process instances are executed and managed by autonomous, intelligent, FIPA compliant agents. In particular, a process or sub-process is managed and executed by a Workflow Provider Agent (WPA), while an atomic process is managed and executed by a Resource Provider Agent (RPA). This means that the execution and management of shared process instances is provided by a set of WPAs and RPAs that co-operate autonomously to accomplish the completion of the process.
The communication between WPAs and RPAs is performed by the exchange of FIPA compliant ACL/XML messages while the communication protocol used is the FIPA Request-Response protocol. The content of the messages is specified based on the inter and intra domain ontology.
The intra and inter domain ontology specifies all the messages that the autonomous agents can exchange during the execution and management of a business process. If the agents belong in the same administrative domain, then the intra-domain ontology is used. If the agents belong to different domains, then the inter-domain ontology is used.
In the following sections, the different agents participate in the execution and management of VE processes are presented and certain details regarding the internal architecture, the modules and the operations that they provide are explained.