Introduction

Use the modeler to create an example of workflow process: eclipse-con registration process.

Extend the modeler by adding the custom property "Participant".

Using the modeler: Eclipse-con registration process design

A very light and fictional process that does not match the actual process in place.

Stage 1: workflow with a single pool

Create a pool and call it EclipseConAttendee

Check out the palette and the diagram assistant.

Check out the ability to re-factor the diagram: change the type of activities.

Here is the kind of pool you can design.

BPMN Connection rules

At design time

It is not possible to draw an outgoing sequence edge from an end-event shape.

At build time

It is possible to force the diagram into breaking the rule above:
Connect to task in the same pool by a flow connection.
Change the type of the first activity into an end-event.

Let the eclipse builder starts the validation of the diagram. It will report and error in the problems view and directly on the faulty edge.

For example:

Stage 2: Attaching documents and forms to the process

A common feature consists of attahcing documents to the BPMN shapes.
The STP-BPMN modeler exposes extension points that makes this very easy.
As an example, the modeler is shipped with the ability to attach any kind of files.
It is able to validate whether the file does exist are not as part of its validation rules.

D&D interactions

Place inside the project where the diagram is developed a word document.
For example the ListOfTutorials.doc

Drag and Drop it on the shape "Choose a tutorial".

The validation builder: remove the file attached to a shape.

The validation is called during the build and adds a marker next to the shape to let the user know that the annotation has disappeared.
Bug #176336: currently not working!

Stage 3: service orchestration: BPMN pools and Messages

At this point, we don't have visibility over the workflow of the eclipse-con-organizers.

This is all good if the scope of the diagram is purely to document the registration in the attendee's point of view: he does not need to know the gritty workflow of the eclipse-con-organizers.

In some cases it is necessary to show both workflow executing in parallel and how they interact.
One solution to do this in BPMN is to use pools and messages.

The advantage of that solution is that it actually matches the actual execution of the process.

In the mean time, let's create another pool where we will design the workflow of the organizers of Eclipse Con.

This is for example what could be designed:

Although this is diagram certainly does display a lot more things at once things get complicated quickly.
There are several technics to keep things manageable.
For example we can collpase entire pools at once to be able to work on a single workflow:

Extending the modeler: defining a custom property

Participants

In this section, we are going to begin to play with the modeler and try to extend its use.

We want to add a participant to our shapes. A participant represents a person with a name and a role.

Adding a property tab to create your annotation

The easiest way to add a participant to your shape is to create a property tab to represent it and enable us to enter his name and his role.

You will need to add org.eclipse.ui.views.properties.tabbed, org.eclipse.stp.bpmn and org.eclipse.stp.bpmn.diagram into the dependencies of the plugin.

We need to make sure that the changes in the text fields are reflected in the EAnnotation. To do this, we need to add a ModifyListener on the text fields.
Plus we need to create a command or use an existing one to do the job of modifying the resource in a transaction.
We choose to create our own command, we could also have used a chain of commands with EMF.

Now we have the choice of extending AbstractGenericEAnnotationDndHandler or implement IGenericEAnnotationDndHandler.
Their main difference is that the IGenericEAnnotationDndHandler interface gives you access to the edit part, while the abstract implementation does the job of
grabbing the semantic element behind it.

Whichever you choose, your handler will have two implement two methods:

This method returns a IStatus status. If its severity is different of IStatus.OK, the drop will be cancelled. The status message field is also useful to create some messages that can be shown to the user.

Here is what our implementation of the accept method should look like:

The other method you need to implement is the performDrop method. This method gives you an access to the command that is going to execute the drop of the annotation. You can return false if yoiu want to cancel the drop at this point.