For JBPM, workflow consists of some nodes and user-defined Hander. A workflow starts from Start-State, and the middle has passed several nodes (State, Fork, Milestone, Process-State, Decision and Join), and finally ended over the end-state. The nodes are connected by transient, indicating that the nodes you want later below. After the node, JBPM triggers the corresponding Hander to complete the user's designated work. Hander includes an actionHander; specifying a node specifies an action actor's AssignmentHandler; defines the Hander of the Node, including the form node forkHander, Join Node JoinHander, Decision's DecisionHander, Process-State node's ProcessInvocationHandler. JBPM has default implementations for Hander. If the user does not specify the corresponding Hander, JBPM uses the default Hander.
When defining a workflow, you can draw the UML status map according to the actual business process, then write the ProcessDefinition.xml-JBPM workflow definition file according to the active map and JPDL. The node of the state diagram can correspond to the corresponding node of the JPDL, such as the state corresponding to state, conversion (bifurcated) for Fork. When the process definition file is designed, you can put some business processes in the Hander process.
The JBPM node is actually the refinement of Activity in the XPDL specification, which is a special Activity. Start-state and end-state nodes are processed by JBPM, and JBPM starts a workflow from the Start-State node, ending the workflow in End-State.
The State node is to be external to access to the next state, such as the steps that require manager approval in the fake process.
Join is equivalent to the Join, fork is equivalent to the Activity Transition, but how Join and Fork are used, users can define themselves. The default fork is equivalent to the XPDL and forks, each branch is walking; the default Join is equivalent to the XPDL and Join, and all the bifurcation arrive will enter the next node.
Decision is equivalent to the judgment in the programming language, determines the next node to go by DecisionHand. By defining DecisionHand, users can implement automatic nodes with the Decision node, that is, the process here, perform certain operations, automatically enter the next node.
Process-State is equivalent to subflow activity, processinvocationhandler is responsible for handling the procedure of the specific call subformation, such as sub-process name, passing parameters, etc. JBPM does not specify the calling process of the sub-process, just provides a defaultProcessInvocationHandler, gives an example of a quote.
Milestone is a special node for synchronizing two execution paths. For example, after execution to the Milestone node, JBPM is waiting, after a node on another path will continue, JBPM enters Milestone's next node. . The node sent a message via MilestOneReachedActionHandler.
All variables used in the workflow are described by Variable, and the variable type is defined by Type. Type definitions must be inherited org.jbpm.delegation.serializer interface. The variable is stored as a string in the database, so the type is to provide a method of converting each other with a string type. The scope of the JBPM variable is the workflow itself. When the process is executed to a node, the corresponding event of the node will trigger the node. Event types include process-start, process-end, state-enter, state-leave, state-off-assignment, milestone-enter, milestone-leave, decision-enter, decision-leave, fork-enter, fork-every-leave Join-every-enter, join-leave, transition. The event is implemented, and the user specifies by inheriting the ActionHander interface.
