| Related information: "JBPM Learning Notes (V3.2 Environment Deployment)" "JBPM Learning Notes (process design and control)" Overview: JBPM (JBoss Business Process management business process Management) is an open source, flexible, and extensible executable process language framework covering business process management, workflow, service collaboration, and more. JPDL is one of the process languages built on the JBPM framework. Tasks are provided in JPDL, pending status (wait states), timers (timers), automatic processing (automated actions) ... , and through the graphical process definition, it is very intuitive to describe the business process. JPDL can be deployed in any application environment in the Java language, javase application (SWING/SWT), Java EE application (application Server) JPDL composition of the distribution contract The latest version of the current JPDL is 3.2.2, you can at the following address: http://labs.jboss.com/jbossjbpm/jpdl_downloads/ Get the official download package. The download package is divided into two kinds, one is the standard package (Jbpm-jpdl-3.2.2.zip) only about 20M, one is the package (Jbpm-jpdl-suite-3.2.2.zip) will be near 80M. The biggest difference is that the package has a configured JBoss service, download the decompression, you can run directly. JPDL's core package (Jbpm-jpdl.jar) It is a typical jar file that covers the operational APIs for process definitions and Run-time process instance context environments. In the simplest example of a business process, JPDL stores the process definition in an XML-formatted definition file, loads the memory at runtime, records the complete business instance and the environment variables of the execution process in memory, and completes all operations. Obviously, in practical applications, process information must be persisted in the database. JPDL uses Hibernate as an API for its object persistence. Graphical Process Designer plugin (jbpm-jpdl-designer-3.1.2.zip) It is an eclipse-based graphic editing plug-in. It enables visual customization of business processes without having to manually edit the XML files. The plug-in also provides a process definition upload feature that can be published to a JPDL system that runs online. JPDL Identity Pack (Jbpm-identity.jar) It is a lightweight expansion package for JPDL, and it simply implements user identity authentication and authentication mechanisms, such as group groups, user users, license rights permission, and so on. If your application environment requires simple user authentication management, it is very suitable for you. JPDL Web Console (Jbpm-console.war) It is a standard Web application (using JSF technology) and provides a monitoring program for the implementation of the JPDL platform (monitoring of the JPDL database). The program allows administrators to easily maintain JPDL databases, manage process definitions, and perform process instances. At the same time, it also provides a simple getting started DEMO, easy for beginners to understand JPDL. Other related catalogs In the unpacked directory, there are some files that are useful /config This directory holds the default profile for JPDL, including Hibernate.cfg.xml, Jbpm.cfg.xml (JPDL primary profile, default is empty), Jbpm.mail.templates.xml (mail template profile), log4j.properties (log configuration file) /db This directory holds JPDL SQL files that are initialized to tables for different databases. Here to say, jbpm.jpdl.mysql.sql under the MySQL batch run, there will be error prompts, because the statement after the lack of ";" Number, you need to revise it before you can use it. / Designer (available in a package) This directory holds the graphical Process designer plugin /examples This directory holds a simple example of JPDL /doc This directory to store JPDL documentation, including user guides, Java API documentation, etc. /server (available in the package) the directory has a configured JBoss and console program, and Windows double-click Start.bat to execute immediately. The database uses Hsql and is stored under/server/server/jbpm/data. JPDL Business Process Model understand business processes in real life Below we have a simple departmental borrowing process to understand the real business process concept, the flowchart is as follows: The diagram above expresses an abstract process definition It is called abstraction because it does not represent the exact performer. When the above borrower is materialized as "John", the department head becomes the John's department manager "Dick", and when the finance is clearly "Harry", the process definition is materialized and becomes a process instance (process Instance). In addition, the people involved in the process are referred to as participants (Actor), where participants are called tasks, and the materialization of each task in the process instance is called a task Instance ; The conversion process from one task (node) to another (node) is called flow (Transition) , whereas in a process, a program's predetermined behavior, such as sending a message, is called an activity (action). Through the examples above, we understand some of the proper terminology and concepts in the business process. Next, we will describe the process object model defined in JPDL from the perspective of programming. In JPDL, the modeling of the process is divided into two parts, one is the static model part for the "process definition", and the other is the Run-time dynamic model for the specific "process instance". In this chapter, we will detail the object of JPDL and the corresponding database design. static process Definition Model
| number |
PD-001 |
| Object |
Flow definition Entity (process definition) |
| Description |
A process definition entity is an object-oriented definition of a process abstraction, as shown in Figure 002. In a system, users can define and save multiple process definition entities, such as: reimbursement process definition, leave process definition, personnel recruitment process definition, etc. Each process definition can also have several different versions, such as: for the same reimbursement process, there are two process definitions before and after revisions, and are stored in the JPDL library. The user can obtain the corresponding process definition through the process name and version number. By default, the system enables the latest process definition. |
| Java Objects |
Org.jbpm.graph.def.ProcessDefinition |
| Database Tables |
Jbpm_processdefinition This table stores the common information defined by the process, such as the process name, version number |
| Table Association Description |
Jbpm_processdefinition table, each record has its own database serial number Id_jbpm_processdefinition FOREIGN key (Foreign keys): Startstate_ is associated with Jbpm_node (process node) tables. The plus key points to the starting Node ID in the process definition |
| number |
PD-002 |
| Object |
Process node (node) |
| Description |
A process node is an abstract, object-oriented definition of process/behavior in a process, as each box in Figure 002 represents a node. Nodes have two primary responsibilities: first, to implement a specified behavior, which in JBPM is to execute a set of Java code, and second, to transmit and maintain the continuation of the process, until the end point is reached. In the JPDL node design, the system opens up the full user behavior model, and the programmer can realize the custom business function based on these behavioral interfaces. In JPDL, the system predefined a series of node types, while also allowing programmers to develop their own node types. |
| Java Objects |
Org.jbpm.graph.def.Node |
| Database Tables |
Jbpm_node The table stores the definition information for the node. |
| Table Association Description |
Jbpm_node table, each record has its own database serial number Id_jbpm_node FOREIGN key (Foreign keys): Processdefinition_-The other key describes the process definition object ID that node is subordinate to subprocessdefinition_- The other key specifies a sub-process initiated by the node. The sub-process must complete the execution process before the main process leaves the current node. Action_-The addition key specifies the ID of the node action class Superstate_-The foreign key is a autocorrelation key that points to the parent node ID of the node. Multiple nodes in a sub-process are subordinate to the same parent process node. decisiondelegation_– The foreign key specifies the decision class ID of the endpoint delegate (the so-called delegation decision class is the Java class that determines the next flow of the process according to the user's business logic) |
node Type Cheung Solution: A Task node (task-node) task node is one or more tasks that represent a person's involvement. So when the process runs to a task node, it generates "task instance objects (tasksinstances)" and adds them to the participants ' task list, after which the nodes wait until the participants complete their task, and the process continues to execute downward. Status Node (state) The state node is a typical wait state. Unlike task nodes, a state node does not add a task instance to the task list. This is useful when the business process needs to wait for the intervention of the external system. Assume the following: When entering the node, send a message to the external system via the Node-enter event, and then the node enters the wait state; When the external system completes processing and sends a message, this will cause the operation of a token.signal () method to be triggered. This method reactivate the waiting process to continue the downward flow. The decision node (decision) determines the function of the nodes, as it is named, to determine the direction of the business process. There are two different modes of adjudication, and the difference between the two is determined by the "who": the variables within the process, or the external entities that provide the basis for the decision. When it is necessary to determine the direction of process execution, use the "decision node (decision)". There are two ways to specify a decision condition. The simplest is to add a conditional element to the steering (transitions) condition, either as an El expression or a BeanShell script that returns a Boolean value. In the course of the operation, the decision junction point is first rotation the conditional steering (leaving transitions), rotation the order is specified in the XML file. When the first condition is found to return to true, the exit is selected. If all the condition judgments in the table Exchange are false, select the turn in the first position in the XML file as the exit. Another approach is to define an expression that returns the name of the transition at the decision node, using the expression to evaluate the returned name, and decide which transition to choose. The other way is to set the "process (handle)" element at the node. Specify a Java processing class on the node that implements the Decisionhandler interface, which determines the export direction of the process by returning the name of the selected transition. When determining the exit of a node is given by an external program, it is recommended to use multiple transition or nodes with a waiting state. An external trigger can be used to end a wait state and provide a transition decision. Branch Node (fork) The role of branch nodes is to split a single execution process into multiple concurrent execution processes. The default behavior is to generate a child token for each sub-process and establish a parent-child relationship between the child token and the dominant Chenggen token. merge nodes (join) As opposed to the branch of the Fork node, the join node points the branch. The default behavior pattern is when all branches (branches derived from the same fork) reach the node, the join node ends the child token on those branches and finds the token of the upper-level process through the parent-child relationship on the token. Spread this token through the only transition. If only a portion of the branch token arrives, the join node is in the waiting state. Common Node (node) Common class nodes are mainly used to provide users to customize their own program code. A common node has an action child element that is executed when the process reaches that node. You can execute any code you want by implementing the Actionhandler interface. In addition, common nodes are also responsible for the continuation of the process. On the flowchart, a common node is used to express the business-related processing logic that a user cares about, and action (as mentioned below) allows for the addition of program processing beyond the business logic, which is not visible on the flowchart and is not cared for by business process analysis.
| number |
PD-003 |
| Object |
Process steering (transitions) |
| Description |
Process steering is a state transition process that describes the process from one node to another, so a shift must have a source node and a target node. In JPDL, the transition is the only one, the node depends on the transition name to distinguish the path to the next node, when there are multiple transition with the same name in a node, the first transition will be selected. In the process of node turning, the default transition is the first position in the transition list. |
| Java Objects |
Org.jbpm.graph.def.Transition |
| Database Tables |
Jbpm_transition the table stores the steering object in the process definition. |
| Table Association Description |
Jbpm_transition table, each record has its own database serial number Id_jbpm_transition FOREIGN key (Foreign keys): Processdefinition_-This foreign key points to the process definition object ID from_ to which transition belongs-the foreign key points to the transition source node ID to_ -The foreign key points to the transition target Node ID |
| number |
PD-004 |
| Object |
Action |
| Description |
actions refer to a series of j that run in a process event Ava code. Flowchart is an important means of communication of software requirements, but it is only a projection of software requirements, hiding a lot of technical implementation details. Actions are a mechanism for adding technical implementation details to a flowchart, which complements and modifies the flowchart. This means that Java code can be associated with it without changing the flowchart structure. Actions are bound to the process through events, and the main events commonly used include: entering nodes, leaving nodes, and turning. Note that the actions associated with the events and actions in node are different. Actions in events are triggered by event triggering, which is a typical observer pattern and does not affect the flow of flow control. The action in node takes responsibility for the process delivery. In addition, the actions can be named. The actions can be referenced anywhere by the name of the actions. Named actions can be used as common child elements defined by the main process. This feature will improve the reuse of the actions definition. |
| Java object |
org.jbpm.graph.def.Action |
| database table | The
jbpm_action the table stores the action objects in the process definition. |
| Table Association description |
|
