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.