CHAPTER 8: BUSINESS PROCESS MANAGEMENT
8.2 P ERSONAL U SER A GENT
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.
request from the user is translated into a legitimate ACL/XML message following the intra-domain ontology and sent to the Domain Representative (DR) agent for further fulfilment.
The main operations of the PUA agent are the following: the user, using a normal Web browser, logs into the VE representative web site and selects one VE business process for execution. The VE representative web site initially checks if the user is authorized13 to use this process and then requests from him to provide values for the input parameters of the process. After the user has provided values for the input parameters, the execution of the process can start. This request for process execution is forwarded to the Personal User Agent (PUA), which creates a legitimate ACL/XML message with the name of the process, the instance id, and the input parameters and values, and sends it to the Domain Representative (DR) agent for further fulfilment. The DR agent gets the request and starts the execution of the corresponding process. When the execution of the process has been started, the user can always suspend the process, resume the process if it was previously suspended, terminate the process or ask for the status of the process. All the above mentioned requests are managed initially by the VE representative web server and are then forwarded to the PUA.
The following figure depicts these interactions. The requests from the user are forwarded from the web site to the PUA through a normal TCP/IP connection, i.e. the web server and Java servlets open a TCP/IP socket connection with the PUA and forwards to him the request.
VE Representative Domain
FIPA ACL/XML
TCP/IP Web HTTP
browser
Web Server Java Servlets u s e r
FIPA Grasshopper
DPE PUA
Customer Domain
DR
Figure 47: Personal User Agent Interaction Model
The PUA maintains for each user of the VE representative the list of processes that have been initiated by him. This information is stored into the Active User Repository (AUR). The AUR stores for every user the process instances, the status of each process instance, and input and output values. Whenever a new process instance is instantiated, a new entry is created into the AUR in relation to a user. When a process instance is completed, the corresponding process instance entry is deleted from the AUR. If the user requests to suspend, resume, or terminate a process instance, the current status of the process instance is also stored into the AUR.
The Active User Repository consists of the following three key entities, namely:
13 Subscription of the user to the VE services is performed off-line in a manually way. The off-line subscription is considered out of the scope of the thesis. However, the interesting reader can get more information about on-line and off-line subscription on http://www.fokus.gmd.de/research/cc/platin/projects/
• Active User Repository (AUR) which provides the main operations to the PUA, like management of active users and process instances
• Active User (AU), which provides operations for the management of process instances of a particular user like create process instance, retrieve all instances, etc.
• Process Instance Status (PIS), which provides operations for the management of a particular process instance, like update process status instance, get and set instance name, etc.
The class model of the Active User Repository and the relationships among the main entities is depicted in the following Figure 48.
Active User Repository getActiveUser() setActiveUser() deleteActiveUser() getAllActiveUsers()
Active User getAllInstances() createInstance() deleteInstance() modifyInstance() 0..*
1 0..*
1
P a r a m e t e r s n a m e
t y p e value constraint
( f r o m b u s i n e s s p r o c e s s d e f i n i t i o n l a n g u a g e ) I n p u t P a r a m e t e r s
( f r o m b u s i n e s s p r o c e s s d e f i n i t i o n l a n g u a g e )
1 1
1 1
Process Instance Status getInstanceName() setInstanceName() getInstanceStatus() setInstanceStatus() g e t P r o c e s s N a m e ( ) s e t P r o c e s s n a m e ( ) getInputParameters() setInputParameters() getOutputParameters() setOutputParameters() 1 0..*
1 0..*
0..*
1
Output Parameters ( f r o m b u s i n e s s p r o c e s s d e f i n i t i o n l a n g u a g e )
1 1 1
1
0..*
1 1
0..* 1
0..*
Figure 48: Active User Repository Class Model
In addition to the key entities of a FIPA compliant agent, the PUA agent contains the following key modules:
• INDO XML Parser: responsible for parsing the content of the FIPA ACL messages based on the intra-inter domain ontology,
• INDO Message composer: responsible for composing the appropriate response FIPA ACL-XML messages related to the DR agent. The structure of the messages is based on the inter-domain ontology,
• Decision manager: responsible for controlling the basic operations of the agent, communicating with the Active User Repository and the other entities
• TCP/IP server: responsible for getting the requests of the users from the web site and for initiating the necessary actions. It also forwards back the web site the results of the requests.
In the following picture the internal architecture of the PUA agent and the relationships among the basic modules is depicted.
TCP/IP S e r v e r
I N D O X M L P a r s e r
D e c i s i o n M a n a g e r
Active User Repository
Message C o m p o s e r
Personal User Agent
Communication
M a n a g e r Java Invocations
FIPA ACL/XML
A C L P a r s e r T
C P
TCP/IP requests from the Web site
Figure 49: Personal User Agent Internal Architecture
In the following sequence diagram, the internal steps that the PUA is undertaking to start a business process for a given user are provided. The other type of operations, like suspend, resume and terminate a process instance or ask the status of a process instance are performed in a similar way. Initially, a start process instance request is generated by the end-user and sent to the PUA through a TCP/IP connection. The TCP/IP server of the PUA agent gets the request of the user and forwards it to the Decision Manager. The Decision Manager identifies the nature of the request, i.e. to a start process, creates a new entry in AUR, and composes a start process ACL/XML message that the Communication Manager sends to the DR agent. When the process instance has started (see section about DR), the DR agent informs the PUA agent, by sending a FIPA ACL/XML inform message, about the successful instantiation of the process instance, i.e.
the process instance is running. The Communication Manager forwards it to the Decision Manager, which parses it with the help of ACL and XML parser. Afterwards, the PUA checks semantically the message, updates the AUR and forwards the response to the TCP/IP server. The TCP/IP server forwards the request to the web server and finally to the user.
: TCP/IP server : Decision Manager
: Active User Repository
: message composer
: Communication Manager
: ACL Parser : XML Parser
check request( )
setActiveUser( )
composeStartProcessRequest( )
send message( )
forward message( ) parse ACL( )
parse XML( )
checkMessage( ) setActiveUser( )
informUser( )
Figure 50: Start Process Sequence Diagram
In a similar manner, when a particular process instance has been completed, the DR agent sends to the PUA agent a FIPA ACL/XML message informing him that the process instance has completed. The message contains the name of the process, the instance id, and the set of output parameters and values of the process. The PUA agent parses the message using the ACL and XML parser and checks the type of inform message. Since the message is completed, the Decision Manager informs the Active User Repository by setting the status of the process and the output parameters and values. In the sequel, the Decision Manager informs the user about the new status of the process and the output results. The internal steps that the PUA performs to provide this operation are depicted in the following figure.
: XML Parser : TCP/IP server : Decision
Manager
: Active User Repository
: Message composer
: Communication Manager
: ACL Parser
informUser( )
parse ACL( ) parse XML( )
checkMessage( ) getActiveUser( )
updateProcessStatus( )
compose inform message( )
Figure 51: Process Instance Completes Sequence Diagram
In the following section, details about the functionality and internal modules of the DR agent and how it operates to perform its key operations are provided.