Process

A BPMN process is a flow of actions, called activities, leading from some initial start event to some end state, marked by an end event. A process model may be descriptive, in which only the names of the actvities and events are modeled, along with all possible paths from initiating event to end state, or it may be executable, provided with additional modeling details sufficient to automate the activity flow on a BPMN engine. Both descriptive and executable processes use the same diagram notation, so "what you draw is what you execute".

Collaboration

A process model may define more than one process. A single process diagram may depict two or more processes exchanging information via message flows. In such a diagrtam, the pool shape represents a participant in a collaboration, meaning the information exchange. Such a diagram is called a collaboration diagram.

In a collaboration diagram, if there is 1:N instance correspondence between the participants, the pool shape with the N instances may be decorated with a multi-instance participant marker of three vertical bars.

Executable Process as a Service

In executable models, a process is the unit of execution. On the Trisotech platform, the process is exposed as a REST service for invocation by either another process or some external client application.

In a collaboration model, if both processes are modeled, each is deployed as a separate service. Also, when a Call Activity is used to invoke another process as a "reusable subprocess", both the original process and the called process are deployed as separate services.

collab1

In the collaboration diagram above, 2 pools have been created and each one represents a process that can be deployed as a service.

Data Inputs and Outputs

Like any service, a process service has inputs and outputs, represented in the model by process variables. In executable models these are visualized in the process diagram. A Data input represents a variable populated by the invoking client at runtime, and a Data output represents a variable returned by the service. Other process variables called data objects are used within the process logic but are not returned by the service.

In the diagram above, Process1 has data input In1, data output out1, and data object Data obj1. Process2 has an incoming start message flow request instead of a data input, and outgoing message flow response instead of a data output.

In addition, a special variable called End is associated with each process. It lists all the labels of the end event or events reached during the service execution.

Deployment

After configuring the logic of the activities, gateways, and events, including the data mapping, we can deploy both processes in one click. To do that, we need to click the checkbox to make both Process1 and Process2 executable.

deploy

Straight-Through vs Long-Running Process

We can make a distinction between two kinds of processes:

  • A Straight through process starts from a Start event and quickly ends by reaching an End event. It may not contain any tasks requiring human interaction, events that wait for something to happen, or invocation of any long-running services. In the example above, Process2 is a straight through process.

  • A Long running process contains User tasks, events that wait, or long-running services, each of which creates a resume point at which the state of the process is persisted. Upon the appropriate human interaction or event occurrence, that resume point can then be used to resume the process. In the example above, Process1 is a long running process. A resume point is created when it reaches User1 and another when it reaches User2. The ability to create long-running services is a key reason for BPMN’s wide adoption as an automation language.