From BrickWikiTwo
Jump to: navigation, search

jPDL is an executable process language, supported by the JBoos jBPM workflow engine jBPM.


Node Lifecycle

  • each node execution passes through different events
  • they represent hook points to add custom logic
  • the base node supports the following events

Node Types

  • Activities to build the control flow together with Transitions
  • inherit from the generic node of the jBPM framework
  • include the so called Propagation Policies
  • i.e. Attributes in the XML process definition processdefinition.xml with corresponding Java classes of the jBPM framework

Start State


  • aloud only once in each processdefinition.xml file
  • only leaving transitions/NODE_LEAVE event

End State


  • alouds only once in each control flow path, i.e. in one Processdefinition.xml several End States could occure
  • only incoming transitions/NODE_ENTER event
  • attribute end-complete-process to flag a real end of the whole running process instance or only of the current executed path (c.f. Implicit Termination); i.e. in the case of a Process State Node
<end-state name="Kein Angebot erstellt" end-complete-process='true' />



  • most generic node
  • to display technical details in the process flow
  • i.e. the code needed to implement this function
  • if these details are important to the business analyst


  • code of the additional functionality
  • so called delegated actions,
  • delegated to external classes
<action class="com.sample.action.MessageActionHandler">

Task Node


  • special kind of wait state like the State Node
  • needs a real user to complete the activity
  • special capabilities are added to handle this
  • is a container of one or more task definitions
  • an assigned user could choose between more than one leaving transitions
  • User Interface is required
  • is inside a Task Node
  • could be one ore more
  • inside one Task Node they should be independent to each other
  • each Task could be assigned to a different user/role
  • the execution order of Tasks is arbitrary
  • the Tasks could be done in parallel (cf. Parallel Split)
  • is instantiated as a Task Instance
  • extended by four events
  • all Tasks inside a Task Node have to be completed to continue the execution to the next node
  • four property values are available to define the execution relation between the Tasks inside one Task Node with the property signal:
    • last
<task-node signal="last"></task-node> or only <task-node></task-node>
    • first
    • never
    • unsynchronized
  • if no Task is defined, the Task Node will not behave as a wait state (i.e. a automatic node)
    • last-wait: if no tasks are created, the execution will wait until tasks are created
    • first-wait: if no tasks are created, the execution will wait until tasks are created and the first task is completed
Human resources
  • one actor or a set of possible actors could be assigned
  • managed by the jBPM Identity Module
Properties/Classes of a Task
    • name
    • description
    • actorID
    • create
    • start
    • end
    • dueDate
    • priority
    • isCanceled
    • isSuspended
    • isOpen

Decision Node


  • to choose between different and exclusive paths (transitions) in more than one leaving transitions
  • evaluates runtime information or a simple evaluation is executed
  • works automatically without any human interaction
  • no wait state behaviour is possible
  • the DecisionHandler method interface could call external services or business rules
  • the default transition is the first defined in the list of transitions
  • if no transition is selected, the default transition will be executed
  • cf. Exclusive Choice
  • could be combined with a previous State Node to model an external activity with an evaluated result as an input to the Decision Node

Mail Node


  • to send an e-mail, when the process execution reaches the mail node
<mail-node name="send email" to="#{president}" subject="readmylips" text="nomoretaxes">
    <transition to="the next node" />
  • e-mail could be customised with templates
<mail template='sillystatement' actors="#{president}" />
  • e-mail templates could be filled with values of process variable incstances
  • needs a running e-mail server
  • configuration in the jbpm.cfg.xml file
  • should have exactly one leaving transition

State Node


  • represents wait state situations (cf. Task Node)
  • waits for external activities or systems
  • an external signal/event has to come in
  • the work is done outside the process execution, e.g. by human resources
  • functionally reduced
  • full node life cycle
  • no logical execution methods are available

Process State Node


  • to define a subprocess
  • the subprocess is linked to the Process State Node
  • the subprocess is a normal defined process, i.e. a second process definition file (Processdefinition.xml)
  • the subprocess is executed as a whole inside the Process State Node
  • i.e. a whole new (sub)process instance will be instantiated and automatically executed
  • the parent process will be in a wait state
  • the relation between parent and child process is based on the following definition information:
    • Subprocess Name
    • Used Variables (Name, Mapped Name, Read, Write, Required)
  • the relation between parent and child process is based on the following runtime information:
    • Process definition name
    • Version of the process definition(or latest version will be used)
    • Optional a variable mapping between parent and child process
  • the child process doesn't need any information about the parent process in its definition
  • i.e. reuse of child processes is possible
  • variables could be mapped between parent and child process (and vice versa)

Super State Node


  • to define different phases in one process
  • to group nodes hierarchical inside Super State nodes
  • to get an overview
  • enter (superstate-enter) and leave (superstate-leave) events are available
  • Events at the Super State border are:
node-leave -> superstate-leave -> transition -> superstate-enter -> node-enter
  • e.g. notification is possible, if a process instance reaches a Super State node
  • measurement of the duration of the grouped activities/tasks etc. is possible

Fork Node


  • to define a specific behaviour, not an activity
  • to split the process in parallel paths
  • to split the path into independent activities
  • all following activities are in concurrent execution
  • the execution path is splitted into several sub-execution paths
  • several child tokens are created, the parent-child relation will be maintained
  • the main process is stopped in the fork-node, it is waiting for all of its children
  • but its no wait state, the child tokens are generated immediately in a foreach loop
  • each leaving path is executed automatically, till a wait state is reached
  • the activities could/must be done in the same time
  • all activities need to be finished
  • cf. Parallel Split

Join Node


  • to wait, till all incoming activities have to be completed
  • all incoming activities have to be completed
  • only one leaving transition is available
  • when all child tokens arrive, a signal is sent to the root token to continue
  • the root token jumps from the Fork Note to the Join Node
  • to represent only business scenarios, no technical issues
  • cf. Synchronization

Task Management Modul

  • to handle the Task Nodes
  • to show and handle the instantiated Task Instances
  • to handle and to expose all required process information to the user

See also

Personal tools