Multiple roles

The show form process only involves one role, the owner role. When the process is created, a single worker is created within the owner's process client.

Many processes involve collaboration with another partner. In these cases, the owner process also contains a step to send a process to the other partner. The other partner will create a worker within their process client. This worker and the owner's worker will have the same process identifier, which means they can talk to each other through the connection.

Creating the flow

You can create a process model which defines a process that runs across multiple partners. This has to have two things that you don't need in a single role process:

• A participant box which identifies the tasks run by the other partner.

• Additional send and receive steps to pass data between the owner and the partner.

The process compiler will automatically create the step to send the process to the partner. However, the process flow must define what data is sent and received across each flow.

To illustrate a multiple role flow, we'll use an example of sending a form to the other partner to complete.

Each role/participant is represented by a box. You can set properties for each participant. Give the owner role and id of owner and the partner role an id of partner. It's also useful to provide names for the roles, which will label the diagram.

Make sure each of the tasks has a sensible identifier.

You then need to add properties to each of the flows and each of the tasks. We'll look at the auto-generated documentation to see the properties.

Properties to start the process and send the form

At the start of the process flow, the owner sends the blank form to the partner.

There are a few things to note here.

The send step type sends data to another partner. The data that we will send is a form definition, which we will define in the properties. The partner role and the action that should run at the partner end are looked up automatically:

• The role of ${target.send.target.role} means "Look for the target of a flow with a flow reference of send, and get the role reference from the step it targets."

• The remoteAction of ${target.send} means "Look for the target of a flow with a flow reference of send." We could use ${target.send.target.reference} instead, though that would be more cumbersome.

Note how we use a flow property to identify the recipient of a send. We could set the flow property to anything – say fred – in which case the role would be ${target.fred.target.role}.

Once the owner process has sent the form to the partner, it sets the status. This sets the status of the owner's worker and creates and event to record that the form has been sent.

This uses the set step type to set the status and create an event. The status is given in two parts – a reference followed by a name, with a slash inbetween. The reference is used for status rules, the name is used to show the status to the user.

Properties for the partner to receive the blank form

At the partner end, the incoming data is saved using the set step again.

The dataReference specifies that the incoming data should be stored in a data area with a reference of form.

Instead of setting status directly, status is specified as a concatenation of two other properties – statusReference and statusName, using a syntax of ${propery} to reference each. This lets us refer to the status reference of name separately, as well as using them together.

The actionRequired indicator is set to indicate that the partner needs to take action.

The remote indicator is set to permit this step to be called through a connection from the owner. If remote was not set, then the call to the partner would be rejected.

The flow to Complete form uses a status value of ${statusReference}. This is evaluated using the properties in the step, which means that if you change the reference you are going to use for the status, the status rules will automatically be updated. This will be used to generate a menu option for the partner to run.

Properties for the partner to complete the form and send it back

When the partner selects the Complete form option, they will start the Complete form flow.

The Complete form step uses the form step type to show a form. Instead of passing the form definition into the step, we use a dataReference to tell it to read the form from the form data area, and update the data in the form when the user submits it.

When the user presses submit, the Send completed form step is run. This is the same as the Send blank form step, but sends data to the owner. Instead of setting data, the dataReferenceFrom property is used to identify where to read the data from. (We could use a data property ${data:form} instead.)

Once the send is complete, the Set form completed status step updates the status and also turns the actionRequired flag off, so that the task is taken off the partner's action list.

Properties to receive the completed form

At the owner end, the completed form is received by a set step, which is very similar to at used in the partner flow to receive the form.

Once the form has been received, the owner can view it using the form step type. The readonly flag is used so that the owner can only read the results, not update them.

Assembling the process

You can import the file from Camunda in the same way as the simple flow. You'll also need a properties file to define the form for the sendBlankForm step.

Having created and imported the process, you can create a worker template and start process recipe in the same way as the simple form. When you create the worker template, you need to tell it what partner connections the process expects, and you can get it to auto-insert the name of the partner into the worker name.

List the roles that the process uses, in addition to owner, in the Connection roles section.

In the worker name, use the placeholder [role] (in our case [partner]), to insert the name of the selected partner connection. Then save the template, create a Start Process Recipe and attach the new recipe to a group profile.

You'll need a connection to a partner to use your flow. If you followed the instructions in Trying out connections to create a self connection, you can test it with that.

Testing the process

If you do this, the process flow should look something like this. This example uses a simple catering request form.

In the process client, you would have a menu option for the new process flow. When it starts, you need to select a partner, in our case Self.

The start process recipe will then ask a name for the new process. Because we used the [partner] placeholder, the name of the partner will be inserted automatically.

Use Submit to create and start the process. It will create a worker in your group, and if you look at the details of the worker you'll see the send event.

Completing the form

The partner (in our case, the Self group), will see a new worker which requires action. The menu will show the Complete form action, which brings up a form for them to complete and submit.

Once the form is submitted, the status will change and the worker will no longer be shown as requiring action (no longer in bold).

Viewing the completed form

Back at the owner, the status will have changed and the user will get an option to view the form.