Graph(图表)
1. Overview
A process definition represents a formal specification of a business process and is based on a directed graph. The graph is composed of (be composed of 由...组成) nodes and transitions. Every node in the graph is of a specific(明确的) type. The type of the node defines the runtime behaviour.(这个类型定义了运行时间行为。) A process definition has exactly(正确地) one start state.
A token is one path of execution.(token是一个执行路径) A token is the runtime concept that maintains(维护) a pointer to a node in the graph.
A process instance is one execution of a process definition. When a process instance is created, a token is created for the main path of execution. This token is called the root token of the process instance and it is positioned in the start state of the process definition.
A signal(信号) instructs(通知) a token to continue graph execution. When receiving an unnamed signal, the token will leave its current node over the default leaving transition. When a transition-name is specified in the signal, the token will leave its node over the specified transition. A signal given to the process instance is delegated to the root token.
After the token has entered a node, the node is executed. Nodes themselves are responsible for the continuation of the graph execution. Continuation of graph execution is done by making the token leave the node. Each node type can implement a different behaviour for the continuation of the graph execution. A node that does not propagate execution will behave as a state.
Actions are pieces of java code that are executed upon events in the process execution. The graph is an important instrument(工具) in the communication about software requirements. But the graph is just one view (projection) of the software being produced. It hides many technical details. Actions are a mechanism to add technical details outside of the graphical representation. Once the graph is put in place(在适当的位置), it can be decorated(装饰) with actions. The main event types are entering a node, leaving a node and taking a transition.
流程定义(process definition)
转变(transition)
节点(node) 节点-->>类型-->>运行时间行为
记号(token) 执行路径 --->节点
流程实例(process instance) 一个流程定义的一个执行
信号(signal) 通知流程继续进行
行为(action) 在流程执行事件之上的java运行代码
2.Process graph
The basis of a process definition is a graph that is made up of nodes and transitions. That information is expressed in an xml file called processdefinition.xml. Each node has a type like e.g. state, decision, fork, join,... Each node has a set of leaving transitions. A name can be given to the transitions that leave a node in order to make them distinct. For example: The following diagram shows a process graph of the jBAY auction process.
Below is the process graph of the jBAY auction process represented as xml:
<process-definition>
<start-state>
<transition to="auction" /> auction(拍卖)
</start-state>
<state name="auction"> 状态有两种转变 一种是转向salefork 一种是转向end
<transition name="auction ends" to="salefork" />
<transition name="cancel" to="end" />
</state>
<fork name="salefork"> 分支
<transition name="shipping" to="send item" /> 运送
<transition name="billing" to="receive money" /> 开出帐单
</fork>
<state name="send item">
<transition to="receive item" />
</state>
<state name="receive item">
<transition to="salejoin" />
</state>
<state name="receive money">
<transition to="send money" />
</state>
<state name="send money">
<transition to="salejoin" />
</state>
<join name="salejoin">
<transition to="end" />
</join>
<end-state name="end" />
</process-definition>
3. Actions
Actions are pieces of java code that are executed upon events in the process execution. The graph is an important instrument in the communication about software requirements. But the graph is just one view (projection) of the software being produced. It hides many technical details. Actions are a mechanism to add technical details outside of the graphical representation.[行为是一种在图形表现之外加入技术细节的机制 ] Once the graph is put in place, it can be decorated with actions. This means that java code can be associated with the graph without changing the structure of the graph. The main event types are entering a node, leaving a node and taking a transition.
Let's look at an example. Suppose we want to do a database update on a given transition. The database update is technically vital(重大的) but it is not important to the business analyst.
A database update action
public class RemoveEmployeeUpdate implements ActionHandler {
public void execute(ExecutionContext ctx) throws Exception {
// get the fired employee from the process variables.
String firedEmployee = (String) ctx.getContextInstance().getVariable("fired employee");
// by taking the same database connection as used for the jbpm updates, we
// reuse the jbpm transaction for our database update.
Connection connection = ctx.getProcessInstance().getJbpmSession().getSession().getConnection();
Statement statement = connection.createStatement("DELETE FROM EMPLOYEE WHERE ...");
statement.execute();
statement.close();
}
}
<process-definition name="yearly evaluation">
...
<state name="fire employee">
<transition to="collect badge">
<action class="com.nomercy.hr.RemoveEmployeeUpdate" />
</transition>
</state>
<state name="collect badge">
...
</process-definition>
Actions can be given a name. Named actions can be referenced from other locations where actions can be specified. Named actions can also be put as child elements in the process definition.
This feature is interesting if you want to limit duplication(复制) of action configurations (e.g. when the action has complicated{复杂的 难解的} configurations). Another use case is execution or scheduling of runtime actions.
Events
Events specify moments() in the execution of the process[事件指定了在流程执行中的片刻]. The jBPM engine will fire events during graph execution[jBPM引擎在图表执行时候将激活事件]. This occurs when jbpm calculats the next state (read: processing a signal)[这个集中在当jbpm打算下一个状态(读：传递一个信号)]. An event is always relative to an element in the process definition like e.g. the process definition, a node or a transition[一个事件总是与流程定义中一个元素相关的,例如流程定义、节点或者转变]. Most process elements can fire different types of events[大部分流程元素蚕激活不同类型的事件]. A node for example can fire a node-enter event and a node-leave event. Events are the hooks for actions[事件是行为的挂钩]. Each event has a list of actions[每一个事件有一个行为的列表]. When the jBPM engine fires an event, the list of actions is executed[当jBpm 引擎激活一个事件，行为列表被执行].
Event propagation 时间传播
Superstates create a parent-child relation in the elements of a process definition. Nodes and transitions contained in a superstate have that superstate as a parent. Top level elements have the process definition as a parent. The process definition does not have a parent. When an event is fired, the event will be propagated up the parent hierarchy. This allows e.g. to capture all transition events in a process and associate(交往) actions with these events in a centralized(集中的) location.
Script （脚本）
A script is an action that executes a beanshell script[脚本是执行beanshell脚本的一个行为]. For more information about beanshell, see the beanshell website. By default, all process variables are available in the script[默认的，所有过程变量在脚本中都是可用的]. After the script is executed, variable values of the script interpreter(解释器) can be stored (or created) in the process variables[在脚本执行之后，脚本解释器的变量值可以被存储（创建）在过程变量中]. For example:
<process-definition>
<event type="process-end"> //过程结束 事件类型
<script>
<expression>
a = b + c;
</expression>
<out variable='a' />
</script>
</event>
...
</process-definition>
The previous script will load all process variables in the interpreter. Then the expression is evaluated(求...的值), which requires that process variables b and c were present in the process variables when the script was executed. The out element specifies that the value of the scripting variable a has to be collected from the interpreter after the evaluation has completed and stored in the process variables (as variable a). When loading all the process variables into the interpreter or when there are variables that are not valid scripting variable names, you can specify the in variables analogue(类似情况) to the out variables.
Custom events[定制事件]
Note that it's possible to fire your own custom events at will during the execution of a process[注意在进程的执行中激活你的定制的事件是有可能的]. Events are uniquely(独特地) defined by the combination(联合) of a graph element (nodes, transitions, process definitions and superstates are graph elements). In actions, in your own custom node implementations, or even outside the execution of a process instance, you can call the GraphElement.fireEvent(String eventType, ExecutionContext executionContext);. The names of the event types can be chosen freely.
GraphElement.fireEvent(String eventType,ExecutionContext executionContext)
Superstates(超状态)
A Superstate is a group of nodes[超状态是一组节点]. Superstates can be nested recursively[超状态可以被递归嵌套]. Superstates can be used to bring some hierarchy in the process definition[超状态可以在进行定义中被用来产生层次]. For example, one application could be to group all the nodes of a process in phases(阶段). Actions can be associated with superstate events. A consequence(结果) is that a token can be in multiple nested nodes at a given time. This can be convenient to check wether a process execution is e.g. in the start-up phase. In the jBPM model, you are free to group any set of nodes in a superstate.
7.4.1. Superstate transitions
All transitions leaving a superstate can be taken by tokens in nodes contained within the super state. Transitions can also arrive in superstates. In that case, the token will be redirected to the first node in the superstate. Nodes from outside the superstate can have transitions directly to nodes inside the superstate. Also, the other way round, nodes within superstates can have transitions to nodes outside the superstate or to the superstate itself. Superstates also can have self references.
7.4.2. Superstate events
There are 2 events unique to superstates: superstate-enter and superstate-leave. These events will be fired no matter over which transitions the node is entered or left respectively. As long as a token takes transitions within the superstate, these events are not fired.
Note that we have created separate event types for states and superstates. This is to make it easy to distinct between superstate events and node events that are propagated from within the superstate.
Exception handling
The exception handling mechanism of jBPM only applies to java exceptions. Graph execution on itself cannot result in problems. It is only the execution of delegation(代理) classes that can lead to exceptions.
On process-definitions, nodes and transitions, a list of exception-handlers can be specified. Each exception-handler has a list of actions(每一个异常处理 一批行为). When an exception occurs in a delegation class, the process element parent hierarchy is serached for an appropriate exception-handler. When it is found, the actions of the exception-handler are executed.
Note that the exception handling mechanism of jBPM is not completely similar to the java exception handling. In java, a caught exception can have an influence(改变) on the control flow. In the case of jBPM, control flow cannot be changed by the jBPM exception handling mechanism. The exception is either caught or uncaught. Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. For caught exceptions, the graph execution continues as if no exception has occurred.
Note that in an action that handles an exception, it is possible to put the token in an arbitrary node in the graph with Token.setNode(Node node).
7.6. Process composition
Process composition is supported in jBPM by means of the process-state. The process state is a state that is associated with another process definition. When graph execution arrives in the process state, a new process instance of the sub-process is created and it is associated with the path of execution that arrived in the process state. The path of execution of the super process will wait till the sub process instance has ended. When the sub process instance ends, the path of execution of the super process will leave the process state and continue graph execution in the super process.
When a subprocess is started, start-variables allow feeding of data from the super process into the sub process. Two variable names can be specified for each start-variable : the super process variable name and the sub process variable name. When the sub process is created, the value of the super process variable is copied in the sub process variable. The reverse is done with end-variable's. End variables allow collection of the results of the sub process into the super process.