Comments

==Tom== You're invited to add comments, but please, add your name in the format as i showed at the beginning of this line.

If you want to start a discussion on a certain topic, please do that in the developers forum.

General updates to the language

Node names become process scoped

In jPDL 3, node names are scoped relative to the nesting level.  E.g. nodes could have the same name if they are in different superstates.  Now, the scope of the node names will be the full process definition.  So no two nodes can have the same name.

Only a fixed set of characters is allowed a..z, A..Z, 0..9, space, ,.;:!?|-_+=&%$�@

If the graphical designer wants to make a separation between the node name (that serves as the id) and the label of the node, it should use the annotation with key 'label'.  The graphical designer also can use the URLEncoder to allow for newlines to be inserted into node labels.

Graphical information merged into the process

Tooling should be configurable to show or hide the graphical information in the XML source view.

When people use the tooling to create the graphs, I'm sure they won't mind seeing the coordinates if they open the file in another editor.  As long as the xml doesn't get too verbose.

This also creates much easier interaction with files.  The alternative is to have a separate file.  In that case, the two files need to be kept in sync.  And the relative location of the two files becomes a convention.  Merging the graph information into the process file, makes it possible to name the files as any other file and move it and rename it just like any other file.  The implementation of the graphical designer will become easier as the graph information cannot get out of sync with the process information (think node renamings only in one of the two files)

Build and package information in the process

I would like the process file to include references to the class, forms and other files that need to be included in the process archive file.

E.g. then during assembly of the process archive, an ant task could be created that takes a process file and a classpath as input.  the ant task could then build the package from that.

Also the deployment preferences could optionally be included.

The designer will also be able to remember the included forms and class files for later packaging and deployment operations.

Version attribute in the process definition

Processes can optionally have a version.  A deployer tool (like a jboss deployer) can then automatically check if the version in the process sources is 1 higher then the highest version available in the database.  If that is the case the process is deployed, otherwise deployment is ignored. 

The designer tool could update the version attribute automatically if it's specified and after each deployment.  A preference could indicate wether the designer should include the version in newly created processes.

==Bernd==: Also ui attributes could be included as proposed in forum

Functional elements

Functional elements are elements that can be used as nodes or as actions.

In case functional elements are used as nodes, they can be decorated with a synchronizer or a propagator as explained at the end of this chapter.

java

• can be used as node

• can be used as action

• used to action in jPDL 3.  Now, java can be used as node and as action.

• Should support ActionHandler configuration with expressions (see jBPM Developers Forum)

java has :functionalElementProperties {FOOTNOTE DEF 1 1}

ejb (invoke a method on an ejb)

script

• Groovy

• Beanshell

• JRuby

• JSR 223

task

• can be used as node

• can be used as action

• can be defined on process level

Add direct support for approval tasks ?

==Bernd== Maybe subtasks should be skipped? It would be the easiest to just have tasks corresponding to a TaskNode with one Task in jPDL 3. If I need more tasks, I can use a fork. I think everything else is counter-intuitive

swimlane

• can be defined in process

ws-invoke

Based on JAX-WS

part

jbossesb-invoke

Based on JBoss ESB API's

Notes

• message-id should probably be generated based on the name of the process and/or either a database identifier or java.util.UUID

• to, reply-to and fault-to are either {service-category, service-name} pairs or EPRs

response

mule-invoke

Based on Mule API's

jms-send

Sends a message using JMS API's

jms-receive

Receive a message from a queue using JMS API's. 

TODO: Maybe building a configurable MDB is better for this.

invoke

• can be used as node

• can be used as action

Is one of following forms of service invocation:

• direct web service invocation

• jboss esb service invocation

• java service defined in the jbpm global configuration.  this decouples the process definition from the actual service being invoked.

rules

• fire all rules or a subset of the rules of a rulebase

• insert facts

• extract facts

sql

Execute a SQL database insert, update or delete

hibernate

A hibernate select and store one or more elements as process variables might make sense.

But probably an update would not make sense as you can have hibernate variables that are references to hibernate entities.  Updates are automatic in that scenario.

Not sure if this is a valid node/action type

email

Send an email. 

TODO: Check out our current email support, which is pretty good.  And compare it with Seam's email support.  I believe that Seam based it's email templates on facelets and it generates html emails.  Always make sure that the chosen mechanism can send notification and reminder emails for tasks.

Variable assignment (= variable assignment and transformation)

• XSLT transformation

• smooks transformation

FTP (get and put)

HTTP (get and post)

File (read and write)

Print (see javax.print)

PDF (generate a pdf with iText)

Excell spreadsheet generation

{FOOTNOTE RED #1 1} ! :functionalElementProperties

synchronizer

propagator

General Structural Elements

process

state

A wait state waits creates a Trigger object (and corresponding record in the DB if used with persistence)

for each outgoing transition.  Trigger name is the transition name.

Has all common attributes and elements.

(obsolete discussion:

==Bernd== I don't see the advantage of the merger. Why not keep the states as in jPDL 3?

==Tom== OK.  I realize the answer to that question is : Because we can.  Which doesn't make a lot of sense.  So let's keep them separate.

)

super-state

Has all common attributes and elements.

By default, the first one is the initial node of the super-state.

(should we add support for history states in super states?)

process-state

Make sure that the following is supported:

• configurable way to bind different end states in the subprocess to outgoing transitions of the sub process state

• configurable way to bind different variable values in the subprocess to outgoing transitions of the sub process state

Idea contributed by Paul Lorenz:

+Hello Tom,

I thought you might be interested in my master's project, for which I built a workflow engine. The bulk of the engine is probably not very interesting to you, but I've implemented a few (potentially) novel ideas. One which may interest you is the idea of composing graphs at load time, instead of (or in addition to) at runtime via nested processes. In this way multiple graphs, when loaded, are composed into a single, flat graph. This allows certain restrictions to be lifted (although has other drawbacks). If you are interested, the model documentation can be found at http://code.google.com/p/sarasvati/wiki/EngineConcepts (the composition section is near the end). The project is released under LGPL.

I always wanted to say thank you for your work on JBPM and your paper on PVM, which were helpful when I was designing my model, which takes ideas from petri-nets and PVM/JBPM.

cheers,

Paul Lorenz

+

transition

TODO: since transitions can now be wait states, I think that it should be possible to associate a task to a transition.  That way, transitions would support plain wait states (task is absent) and human task based wait states.   Cool, huh ?

Common node contents

Transitions or nested node elements are specified in each individual node type.

Control flow : Propagators

These are the node types that only implement syncrhonization behaviour

decision

Decision can have outgoing transitions or nested nodes.  Outgoing transitions and nested nodes are exclusive.

1. method expression that returns the transition name

2. conditions on the transitions

3. decision handler

fork

Fork can have outgoing transitions or nested nodes.  Outgoing transitions and nested nodes are exclusive.

1. method expression that returns the list of transitions to take or nodes to execute

2. conditions on the transitions

3. fork handler returning the list of transitions to take or nodes to execute

4. iterator for each transition

Forks are flat or nestable.  Flat is the default and means that only one set of concurrent executions can be active at a given time.  The advantage is that unstructured forks and joins are supported.  Nestable means that multiple forks can be executed in concurrency, in which case, the runtime engine must keep track of the 2 or more sets of concurrent executions.  Nestable forks do not support unstructured joining and require that every fork must have a matching join.  Nested forks should never have outgoing transitions and always be based on child nodes.

Flat fork refers to the way that the runtime execution tree is treated as a flat collection.

==Bernd== It should be configurable in the join under which condition it propagates (all incoming, 2 of 10, one, ...)

Control flow : Synchronizers

join

Joins a flat fork.

end-state

All common attributes and elements except timers.

Control flow : Others

while

• iterator

• condition

Synchronizers and Propagators

These are elements that can be optionally added to functional nodes. 

Propagators can specify how execution should be propagated after a functional node is executed.  Options for propagators are:

1. take the default outgoing transition (default propagator behaviour)

2. take the first transition for which the condition resolves to true

3. take all the transitions for which the condition resolves to true

4. propagate to the parent node

Synchronizers can act as a join before a functional node is executed.  Join behaviour can that way be included in the functional node itself.

I don't know yet what the proper configuration for a synchronizer should look like.

test-process

A test process refers to another process and applies some modifications to it so that it can be ran in a test environment.  E.g. Functional element behaviour can be skipped, stubbed out or configurations can be changed.

For test purposes, the changes can be applied statically, resulting in a new and updated process definition.  Whereas for other use cases, dynamic modifications need to be applied to a process definition (think runtime actions).   In the case of dynamic modifications, the modifications need to be maintained separate from the original process and they need to be applied at runtime, rather then at deployment time.