Analysis of workflow participants and work item Modes

Guidance:
For the current workflow application, artificial nodes undoubtedly play a very important role. Because traditional collaborative office systems and more enterprise applications need to be involved in specific processes. This article mainly analyzes the participant modes involved in the manual nodes in the workflow application and the work item modes associated with them. Finally, it provides some solutions as a reference.
Let's talk about what a manual node is.
The concept of a manual node is relative to an automatic node. As the name suggests, a human node is a node that requires human participation. In the actual process, it is reflected in the work items completed by people and decision variables decided by people, these decision variables will affect the operation of the process (such as the selection of branches ). The automatic node is called by the workflow engine itself, and requires no human participation. Generally, it performs customized business operations. In comparison, artificial nodes are more applied in management processes, while automatic nodes are more applied in enterprise business processes.
There are three responsibilities for a manual node: the first is to determine the participants of the node; the second is to generate a work item that requires a person to process according to the participants; and finally, when the work item is completed by the participants, it will continue to trigger the flow of the process. When handling work items, participants can process the corresponding business and set process decision variables.
Next we will analyze the participant mode and work item mode involved in the manual node according to these three responsibilities.
1. Determine the participant Mode
In other words, it determines the participants of the node. There are two modes: Automatic Retrieval by the engine and specified by the end user.
1.1 Automatic Retrieval by engine
The so-called automatic acquisition of the engine is calculated by the actual node participants of the engine during runtime, without the participation of end users. This computation defines the participants of the node based on the process definition.
(1) directly designate a person, department, or role
This is the simplest and most direct case. When you define a node, you can directly select a person, department, or role in the user tree of the organization, and then perform the and or operation according to the definition during the runtime. Most workflow engines support this mode. However, it is obvious that it also has great limitations. It is static. Once the process definition is complete, the participants are fixed. Any changes in the runtime will not affect the participants, A simple requirement is the leave process. The Node participants must be the current applicant's department leaders. because the applicant is not certain During the definition period, it is impossible to specify the node participants, therefore, this model is far from meeting the user's slightly more complex needs.
(2) Call User-Defined computing participant code
In this case, the engine usually provides an interface or parent class. You need to implement or inherit this interface or parent class and then implement the corresponding method. This method usually passes an execution context parameter. The user code can access the information of the current process instance through this context, such as the current node status and workflow variables, then, the user can perform logical calculation based on the actual business and the information of the current process instance, and finally return the Id set of a participant. For the example of calculating the current requester department leader mentioned in the previous model, this model is very easy to implement, first obtain the current applicant ID, then, find the applicant's department based on the ID and then find the department leader.
When the actual process runs on the node, the code of the computing participant customized by the user is called. the ID of the participant returned by the method is the actual participant of the node.
This mode is the simplest for the implementation of the workflow engine, because it throws the greatest complexity to the user and uses the user code to calculate the actual participants. In fact, many open-source workflow engines use this method, such as jbpm. However, this method brings users the maximum flexibility, but also brings complexity and complexity. In particular, it is a headache to define a participant computing class for each manual node of each process in the face of a large number of process requirements. Coupled with the emphasis on business agility, changes in the business should be quickly fed back to the definition of the process, making it impossible for end users to write or modify the computing class of this participant. In addition, this is an aspect that users need to consider when considering the use of open source workflow engines or commercial workflow engines.
(3) Specify the participants of the previous Node
In fact, when you define a node, specify the participant as the participant of the previous node. When the process runs to the node, the engine automatically obtains the specified participant of the previous node as the actual participant of the node.
This mode is not difficult to implement. Most commercial workflow engines support this mode. It can meet some specific needs of users.
(4) more complex situations
Users' Requirements are always complex. The engine is to minimize this complexity, and process changes must be able to quickly keep up with business changes. Consider the following two more complex but common requirements. Requirement 1: the participant is the department leader of the current applicant and the position is vice president; requirement 2: The participant must be all the female colleagues in the testing department. Both of the two demand Modes 1 and 3 are not met. 2 is acceptable, but as mentioned, Mode 2 may be very cumbersome and cannot adapt to business agility. In fact, the complexity here is mainly reflected in: 1. Participants here may be determined during the runtime; 2. There may be many restrictions for participants, these conditions are not described by a simple department, role, or position.
For general workflow engines, they all choose the implementation of Mode 2 to allow users to implement their own logic. In some of the solutions below, we will see a better implementation method.
1.2 End user designation
The end user determines the node participants during the runtime. This is also a unique characteristic of China's national conditions. The most common mode is the submission page when a user submits a work item. on this page, the user selects a node (selected by most branch users) and the participants of the next node. This mode is not difficult in itself. The problem is that on the submission page, users must be provided with a range of options for the participants to select. The selection range is back to the engine's automatic acquisition mode mentioned above. This range also requires engine computing. So I went back to the four models I just discussed.
2. Participant Execution Mode
Now, you have obtained the node participants. The engine will generate work items based on this participant. Note that the participants here may be one person or multiple members ). Therefore, the execution mode of the participants can be understood as the generation mode of the work item.
2.1 Competition
When multiple participants participate in this node, competition will occur. A can do the same job, and B can do the same job, so competition arises. Whoever starts the job will be responsible for the job.
2.2 sequential participation
Multiple participants complete the work item in the specified order. After a is complete, B is complete, and then B is handed over to C.
2.3 participate simultaneously
Multiple participants process the work at the same time. After all the participants are completed, the process continues to flow backward. This mode is actually complicated, because it also involves a completion rule: Is the process flow after all participants complete the work item, or are there other rules? For example, two work items can be transferred, and 80% of work items can be transferred. We will discuss it later.
2.4 Server Load balancer
This is also a common requirement. This work can be done by both A and B, but a currently has 10 to-do work items, and B only has 2 to-do work items. Therefore, the user expects that the work will be completed by B. Here we need to implement a simple load balancing. In fact, this is only the simplest case of intelligent decision-making. The so-called intelligent decision-making refers to the ability of the system to analyze certain indicators (such as personnel processing efficiency and workload) and rules to determine the participants of the node.
3. Work Item completion Mode
This mode is valid when the participant execution mode is simultaneous participation. Before talking about this mode, let's talk about several special states that may exist in a work item, including pending, manually terminating, and delegating. Pending means that the work item is temporarily suspended. Pending will affect the flow of the process and cause the process to be suspended. Manual termination is a manual change to the state of the work item to terminate the execution. This person is usually an administrator. Manual termination will also affect the flow of the process. When all work items except the work item are completed, manual termination of the work item will trigger the flow of the process. The assignment is to assign the work item to others, and the work item is over. Manual termination and delegation are special statuses of the end of a work item.