nPdl
What is nPdl
nPdl is the acronym for 'NetBpm process definition language'. It describes the format for expressing a business process. nPdl specifies the following
- how the business process logic should be expressed in xml
- how to express optional web-interface information to let the NetBpm web application generate web-forms for every step of the process
- how the execution of your .NET-classes can be coupled to the process logic
- how all the files for one business process are packed together in a archive
So nPdl is more then just an xml-schema. It describes how to express a business process in a process archive including the application integration aspect. The next image shows the basic terminology that is used in nPdl to express a business process.
Process archives
A process archive is a zipfile that contains xml-files, .NET assembly and other files. All the information in a process archive specifies one process definition. The assemblies in a process archive are associated with the process definition and are not visible outside that scope. (They are loaded with a process-definition-specific-classloader). Analogue to the classloading mechanism of web-archives and bean-archives.
/root
|
+- processdefinition.xml
|
+- web
| +- webinterface.xml
| +- activitydiagram.gif
|
+- lib
+- MyActions.dll
|
example of a typical layout of a process archive
Three names of a process archive are fixed :
- processdefinition.xml : must be in the root of the process archive and contains the process logic.
- lib : this folder contains .Net assemblies that are associated with this process definition. (the assemblies will be stored in the NetBpm database)
- web/webinterface.xml : this file is optional but if you want to add web-form generation to your pages, this must be the name of the file-name.
Process archives are deployed into the NetBpm application through e.g. the NetBpm web-application that uses file-upload, an nant-task or directly the interface of the definition component. The definition component will parse the process archive, store the information in the NetBpm-database and discard the process archive file. After a process has been deployed, users (or systems) are able to perform single activities through the execution component.
See also The NetBpm database
Process logic
This section explains the schema of the processdefinition.xml. The description of the schema use the type attribute and element.
Element : a element is an XML element
Property : a property is an attribute that can also be supplied as an element. It is possible to write a property as a XML property or a XML element. See the following example.
...
<image>
<name>myimagefile.gif</name>
<mime-type>image/gif</mime-type>
<width>345</width>
<height>53</height>
</image>
...
can also be expressed as
...
<image name="myimagefile.gif" mime-type="image/gif" width="345" height="53" />
...
or a combination of both notations.
|
properties can be supplied as attributes or as child-elements
Process definition
The process-definition is the document root tag. A process-definition contains the process logic for one business process. Only one process-definition is allowed in a processdefinition.xml.
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | is the name of the process definition. Note that this name is also used in the versioning mechanism |
| description | 0-1 | property | general purpose description of the business process |
| responsible | 0-1 | property | is the user responsible for this process |
| authorization | 0-1 | element | allows to specify a custom authorization implementation that can validate every action that is done through the execution or the admin components. see authorization |
| start-state | 1 | element | the unique start state of the process. see start-state |
| end-state | 1 | element | the unique end state of the process. see end-state |
| attribute | 0-n | element | the attribute defined here result in attribute instances created for the root-flow. see attribute |
| activity-state | 0-n | element | define the wait states where the process will have to wait on input or a trigger from human users or systems external to NetBpm. see activity-state |
| process-state | 0-n | element | defines a state in the process that corresponds with the complete execution of another process. see process-state |
| decision | 0-n | element | defines a choice between multiple paths of execution. see decision |
| concurrent-block | 0-n | element | defines a block with a fork, join and everything in between. Note that transitions cannot cross concurrent-block boundaries. see concurrent-block |
| action | 0-n | element | defines an action relative to the process-definition. The valid event-types for process-definition-actions are process-instance-start, process-instance-end and process-instance-cancel. see action |
Start-state
The start-state defines the starting point for the process definition. All process instances will start in the start-state. The rules for leaving transitions and attributeValues input for start-states are the same as for standard activity-states. For that explanation, please refer to Performing an activity. Note that it is not allowed for transitions to arrive in the start-state.
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | is the name of the start-state |
| description | 0-1 | property | general purpose description of the start-state |
| role | 0-1 | property | see Activity assignment |
| field | 0-n | element | can be used to restrict access to an attribute or make the input of an attribute-value required. see field |
| action | 0-n | element | defines an action relative to the activity-state. The valid event-types for start-state-actions are before-perform-of-activity and after-perform-of-activity. To schedule an action after the attributeValues are set and before the processing of the transitions, you have to put an action in the process-definition with event-type process-instance-start see action |
| transition | 1-n | element | are the transitions leaving this node. see transition |
End-state
Defines the end-state of this process definition. A process-definition would have an end-state.
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | is the name of the end-state |
Activity-state
An activity-state is a state in the process where you wait for an external party (human user or system). An activity-state specifies that the 'thread-of-execution' is outside the scope of the process engine. All actions that should be executed by the process engine in the context of a process instance should be modelled as actions
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | is the name of the activity-state |
| description | 0-1 | property | general purpose description of the activity-state |
| assignment | 0-1 | element | see Activity assignment |
| role | 0-1 | property | see Activity assignment |
| field | 0-n | element | can be used to restrict access to an attribute or make the input of an attribute-value required. see field |
| action | 0-n | element | defines an action relative to the activity-state. The valid event-types for activity-state-actions are before-perform-of-activity (which is before the attributeValues are stored in the attribute instances), perform-of-activity, after-perform-of-activity (which is after the engine has processed all transitions), before-activitystate-assignment, and after-activitystate-assignment. see action |
| transition | 1-n | element | are the transitions leaving this node. see transition |
Activity assignment
If you're not familiar with the organisation component read The organisation component.
To assign an activity-state to an actor, the process developer has 2 mechanisms
-
AssignmentHandler : an AssignmentHandleris an interface with one method.
When the execution arrives in an activity, first is checked if that activity-state
has an AssignmentHandler.
The AssignmentHandler interface If it does, the specified class is instantiated and the method is called. The implementation must then return the ID of the Actor that must be assigned to the activity. see the delegation principlepublic interface IAssignmentHandler { String SelectActor(IAssignmentContext assignerContext); } - role : if an activity-state does not have an AssignmentHandler, it must have a role specified. The value of a role for an activity must be the name of an attribute. As a consequence, you must declare an attribute of type 'actor' for the role. A role corresponds with a swimlane in the UML activity diagram. If both an AssignmentHandler and a role are specified, the AssignmentHandler will be used to select the actor and that actor is also stored in the attribute instance. If only a role is specified and no AssignmentHandler, the activity-state is assigned to the actor in the attribute instance specified by the role. Note that in the latter case the attribute instance may not contain a null-value.
Process-state
Specifies one process-state in the UML-activity-diagram. A process-state is a state in the process which corresponds to the execution of a another process-instance. We say that the parent process invokes a sub-process. When execution arrives in such a state, the sub- process will be started. The termination of the sub-process-instance triggers the parent process to regard the process-state as completed and continue execution.
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | The name of the process-state. |
| description | 0-1 | property | general purpose description of the process-state |
| process | 1 | property | The name of sub-process. Note that the latest version of the sub-process will be associated during deployment. If later new versions of the sub-process will be deployed, this will have no impact on the process-invocation. |
| actor-expression | 1 | property | specifies the actor that is used to start the sub-process-instance |
| process-invocation | 1 | element | see process-invocation element for details |
| action | 0-n | element | defines an action relative to the process-state. The valid event-types for process-state-actions are sub-process-instance-start, process-instance-start. see action |
| transition | 1-n | element | are the transitions leaving this node. see transition |
Attribute
Defines the attributes used in this process definition.
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | is the name of the attribute |
| description | 0-1 | property | general purpose description of the attribute |
| initial-value | 0-1 | property | the initial value for the attribute in serialized format. |
| serializer | 1 | property | For storing attribute .NET-objects into the database, they have to be serialized to text. This property specifies how the attribute .NET-objects get serialized. This must be a fully qualified .NET class name. Customised implementation must implement NetBpm.Workflow.Delegation.ISerializer |
| type | 1 | property | The type attribute values are in fact short names for predefined serializers. There are several 'built-in' types in NetBpm:
|
| parameter | 0-n | element | see parameter for details |
Decision
A decision selects one of multiple possible execution paths. To make a decision when an activity is being performed, the process modeller has 2 options :
- Leave the choice to the client. This is a situation where multiple transitions leave an activity. This means that the client has to supply the selected transition name in the PerformActivity(...) method.
- Let the engine decide automatically : In this case one transition leaves an activity and arrives in a decision-node. The decision will automatically (based upon the attributes and all desired external resources) make a decision about which leaving transition to take.
Both approaches can be combined.
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | The name of the decision. |
| handler | 1 | property | Implementation of DecisionHandler to decide which path (transition) to take |
| parameter | 0-n | element | see parameter for details |
| transition | 1-n | element | are the transitions leaving this node. see transition |
Process block
The common parts of a concurrent-block and a process-definition is a process-block. I'll explain the concurrent block : In process languages you have the block-structured approach (e.g. BPML) and the graph based approach (e.g. XPDL). NetBpm combines best of both worlds. Where possible, NetBpm allows graph-based approach (free transitions between nodes). This gets problematic when forking and joining therefor a fork always is associated with a join and those two define a concurrent block. No transitions can cross the concurrent block boundary. Concurrent blocks can be nested. Another communality of process definitions and concurrent blocks is the fact that they can define attributes : Attributes, defined in a process definitions are instantiated at process-instance-creation-time and attributes that are defined in a process block are instantiated for each flow that is forked at the beginning of the block.
Concurrent block
A concurrent-block exists of a fork, a join and all process elements that are defined in this concurrent-block. Note that transitions cannot cross concurrent-block boundaries except for transitions to the fork and transitions leaving the join. A concurrent block can also declare flow-local attributes.
| name | multiplicity | type | description |
|---|---|---|---|
| fork | 1 | element | is the fork of the concurrent block |
| join | 1 | element | is the join of the concurrent block |
| attribute | 0-n | element | specifies a flow-local attribute |
| activity-state | 0-n | element | see activity-state for details |
| process-state | 0-n | element | see process-state for details |
| decision | 0-n | element | see decision for details |
| concurrent-block | 0-n | element | concurrent-blocks can be nested recursively |
| action | 0-n | element | see action for details |
Fork
- Standard behaviour
- describe what the standard behaviour is
- standard behaviour does not require specification of a ForkHandler or JoinHandler
- A ForkHandler can start flows for leaving transitions. Note that more then one flow can be started for the same transition.
- Synchronization of flows :
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | the name of this fork |
| transition | 1-n | element | the multiple path of executions. Should be name of node |
| handler | 0-1 | property | Implementation of ForkHandler. Defines how the transitions should be forked. If not defined, each transition is forked sequentially |
| parameter | 0-n | element | see parameter for details |
Join
A join is used to synchronize multiple paths of execution that were created at the a fork.
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | the name of this fork |
| action | 0-n | element | see action for details |
| transition | 1-n | element | see transition for details |
| handler | 0-1 | property | Implementation of JoinHandler. Defines when parent-flow should be activated. If not defined, parent-flow will be activated when all flows arrives. |
| parameter | 0-n | element | see parameter for details |
Transition
specifies one transition in the UML-activity-diagram. To understand the restrictions of transitions, first a word about process blocks. A process block is a scope for attributes and nodes. A process-definition is process block. A concurrent-block is also a process block. Transitions may not cross process block boundaries. This means that all forked execution-paths (= flows) that are forked at a fork, have to be joined in the join of the same concurrent block.
| name | multiplicity | type | description |
|---|---|---|---|
| name | 1 | property | the name of the transition. |
| to | 1 | property | the name of the destination element of the transition. Can be an activity-state, a process-state, a decision, a fork or a join. (Should be name of Node in same process block) |
| action | 0-n | element | see action for details |
Action
An action is a piece of software that has to be executed by the process-engine within the context of a process execution. So actions are executed within the 'thread-of-execution' of the process engine. Examples of usages are e.g. sending an email, updating a database, getting some info from an SAP-system, ... The handler specifies a .NET-class that implements the NetBpm.Workflow.Delegation.IActionHandler interface. An action element also specifies when the action has to be esxecuted. The timing is determined by two factors : 1) the surrounding process element and 2) the event-type which specifies an event relative to the surrounding process element. Let's illustrate with an example
...
<decision handler="Yourproject.Decisions.HasBigSalary">
<action event="before-decision" handler="Yourproject.Actions.GetInfoFromSAP" />
</decision>
...
|
specification of an action before a decision is made
| name | multiplicity | type | description |
|---|---|---|---|
| event | 1 | property | |
| handler | 1 | property | |
| parameter | 0-n | element | see parameter for details |
| on-exception | 0-1 | attribute |
Authorization
The runtime model
Note that UML does not specify a runtime-model for activity diagrams. Since NetBpm is just a run-time executor of activity diagrams, we will need to clarify certain aspects of the activity-diagram modelling.
Performin an activity
- 1 leaving transition versus multiple leaving transitions
- performing an activity is a trigger
- while performing an activity, you can feed attributeValues into the process.
