For jbpm, a workflow consists of some nodes and user-defined hander. A workflow starts from start-state and ends with end-state after several nodes (State, fork, milestone, process-state, demo-join) in the middle. Nodes are connected through Transient to specify the nodes to pass under the current node. When the node passes through, jbpm triggers the corresponding hander to complete the work specified by the user. Hander includes actionhander for various events; specify the node to specify the assignmenthandler for the actor; Define the hander for node work, including fork node forkhander, join node joinhander, and decisionhander for the demo-node, processinvocationhandler of the process-state node. Jbpm has a default implementation for hander. If you do not specify the corresponding hander, jbpm uses the default hander. When defining a workflow, You can first draw a UML state diagram based on the actual business process, and then write the processdefinition. XML-jbpm workflow definition file based on the activity diagram and jpdl. The node of the status chart can correspond to the corresponding node of jpdl, for example, the State corresponds to the state, the transition (fork) for the fork. When designing a process definition file, you can put some business processing in hander processing. Jbpm nodes are actually the activity details in the xpdl specification and are a special activity. The start-state and end-state nodes are processed by jbpm. jbpm starts the workflow from the start-state node and ends the workflow at the end-state node. The State node requires external participation before entering the next state. For example, the leave process requires approval from the manager. Join is equivalent to the join of activity transition. Fork is equivalent to the fork of activity transition. However, you can define how to join and fork. The default fork is equivalent to the and fork of xpdl, and each fork goes through. The default join is equivalent to the and join of xpdl. After all forks are reached, it enters the next node. Decisionhander determines the next node to pass. By defining the decisionhander, you can use the demo-node to implement automatic nodes, that is, the process is here, perform certain operations, and automatically enter the next node. Process-state is equivalent to subflow activity. processinvocationhandler is responsible for processing the process of calling sub-processes, such as the sub-process name and passed parameters. Jbpm does not specify the sub-process call process. It only provides a defaprocesprocessinvocationhandler and provides an example for calling. Milestone is a special node that is used to synchronize two execution paths. For example, after being executed to the milestone node, jbpm waits until a node in another path sends a signal that can continue, jbpm enters the next node of milestone. The node sends messages through milestonereachedactionhandler. All variables used in the workflow are described by variable, and the variable type is defined by type. The type definition must inherit the org. jbpm. Delegation. serializer interface. Variables are stored as strings in the database. Therefore, the type must provide a method for mutual conversion with the string type. The scope of jbpm variables is the workflow itself. When the process is executed to a node, the corresponding events of the node are triggered. Event types include process-start, process-end, State-enter, State-leave, State-after-assignment, milestone-enter, milestone-leave, demo-- enter, and demo-- leave., fork-enter, fork-every-leave, join-every-enter, join-leave, transition. The specific operations performed by the event are specified by inheriting the actionhander interface.
