sequence
Recently, activiti is used to implement a more complex workflow function. After writing, I have many thoughts, and my understanding of workflow seems to have opened a new window. Since the main means of transportation for commuting to and from get off work every day is the subway, a sudden whim connects the concepts in the workflow with the concepts in the transportation. This article does not elaborate on the basic concepts of workflow, but records some thoughts on workflow business applications and a description of my ideal workflow.
Imagination
My ideal workflow should be as intuitive as a bus stop sign or a prompt diagram of a running station in a subway car. Clearly and intuitively define the train running line and passing station information, in fact, the current workflow framework has done this. In addition, if there is a screen in the workflow that can dynamically display the station where the subway is currently running, like a subway car running line status diagram, this will greatly improve the convenience of the running status of the workflow instance. In this screen, not only can you get the approval task line information defined by the global process, but you can also monitor which task node the process instance runs to, just like riding in a subway car. You can look up at the subway station bar on the car. Knowing which stations this subway runs through, and the current driving position, click on a task node to get the information of the personnel participating in the task node, and you can directly view the historical approval information of the task on this map. Deciding whether the process continues, terminates, or dials back to a certain node can be directly operated on the way to this station. There is no need to view flowcharts, receive tasks, review tasks, and view historical tasks like the current processes implemented in the industry. These operations need to be completed at the same time, which requires frequent switching. It is necessary to master the use of this process. Clearly remember the entry of these damn tedious operation pages. . . . . . Unfortunately, the current workflow framework has not yet achieved this level. Viewing process definition information and viewing process instance running status are scattered and unconnected, which is actually very unfriendly to users participating in the process and very inhumane.
Back to reality
Dreams are necessary, what if someone realizes it? Back to reality, leave some space to summarize my own understanding of the characteristics of workflow
(1) Approval mode The
approval mode can be broadly divided into active mode and passive mode. The passive mode refers to the clear designation of the approver of the next node when processing the current task. The next approval is actually a passive acceptance of the task. Active mode means that after the process engine creates an approval task for a process instance, all members of the group to which this task belongs are visible, and these members take the initiative to process the task. In fact, changing the angle of description, the concept of this active and passive mode can also be exchanged.
(2) Task flow mode The
task flow mode can be divided into single-line mode, single-line condition mode, multi-line parallel mode, and multi-line condition parallel mode. Activiti provides an exclusive gateway to support the realization of a single-line conditional mode, a parallel gateway to support the realization of a multi-line parallel mode, and an inclusive gateway to implement a multi-line conditional parallel mode.
(3) Regarding the use of
sub-process business scenarios. In fact, most of the business scenarios that need to be implemented with sub-processes can be implemented through parallel gateways. If it can be implemented with a parallel gateway, don't use sub-processes. Sub-processes are complicated to implement, which increases the complexity of the process and handles abnormal operation of the process.
(4) The difference between countersignature tasks and parallel tasks The
technical realization principle of countersignature tasks is multi-instance tasks, and the realization principle of parallel tasks is task fork and join. It can be seen that the principles are similar. A designated proportion or number of approvers agree that a countersigned task can pass, while a parallel task means that parallel tasks must pass before they can reach any node after the parallel.
(5) The difference between consent, rejection, rejection, release, and designated agent operations in task operations.
The most commonly used of these operations should be the approval and rejection operations, even if the two task operations of a process are necessary. So, let's talk about the differences in the operation of the tasks of dismissing, releasing, and assigning agents! The task handler found that the historical processing result of the task did not meet expectations, and wanted to call back to specify a certain historical node for reprocessing—rejected; the task handler received or assigned a task, and found that the task could not be processed, The assigned task is returned to the state to be assigned and re-assigned-released; the task handler finds that he has no time to process the assigned task, and then assigns the assigned task to another person-the agent.
(6) Interaction between process instance and program, and task handler The
typical application scenario of interaction between process instance and program is to dynamically specify the approval position or approver of the corresponding task node by configuring business logic processing components in the user task node In addition, there is less of a process, which is the process business execution logic that is called after the process approval is completed; the operations performed by the business personnel involved in the task approval on the task, including the designation of the next approver and the business information associated with the new process. . . and many more. . .
(7) The data display related to the process instance should be hierarchical
The concept of hierarchy is often seen in the architecture. The difference in business processing services can improve the reuse rate of business system services, reduce the coupling of business functions, and improve the scalability of business applications. To achieve this goal, the first thing to do is to layer, design and display data in layers. Data at different levels must not be coupled together and displayed in the same dimension. For example, the task list displayed on the process to be approved task page should only display the information of the approval task, such as the name of the task, the id of the process instance, the next approver, the creation time of the task, the initiator of the process, and the link to view the historical task node Approval information. In addition, it is absolutely impossible to include the business data information processed by the process task. If it is included, the development process is small. If the number is large, then this page will eventually get out of control. Because the business data processed by different processes is diverse and may have no commonality at all, it is not in the same business dimension. Therefore, the business information field in the task list is definitely a big hole in the design. Business data should be displayed in the task details form, which is a private information display window for each process. If the general purpose of this place is to be implemented dynamically, it can also be connected to a task detail page. This will greatly increase the space for personalized expansion of different processes.
Just write so much, I have to get off work. This article on workflow is certainly not as systematic and comprehensive as activiti practice. It aims to record what I think from the perspective of actual business development experience. . . . . . . . . . . . . . .
END. . . .