BPMN 2.0 Structure (ii)

This is the 12th day of my participation in Gwen Challenge

Custom extension

The BPMN 2.0 standard is a good thing for all concerned. End users are not affected by vendor lock-in by relying on proprietary solutions. Frameworks, especially open source frameworks like Activiti, can implement a solution that is identical to (and often better than) the solutions of the big vendors; -). Thanks to the BPMN 2.0 standard, the transition from such a large vendor solution to Activiti was a simple and smooth one.

The downside of standards, however, is that they are always the result of many discussions and compromises between different companies (usually visions). As a developer reading BPMN 2.0 XML for process definitions, there are times when certain constructs or ways of doing things are too cumbersome. Because Activiti makes ease of development a top priority, we introduced something called the Activiti BPMN extension. These extensions are new constructs or ways of simplifying constructs that are not in the BPMN 2.0 specification.

Although the BPMN 2.0 specification explicitly states that it is made for custom extensions, we ensure that:

The prerequisite for this custom extension is always a simple transformation of the standard way of doing things. So when you decide to use custom extensions, you don’t have to worry about having no fallback.

When using custom extensions, this is always indicated explicitly by providing activiti: namespace prefixes for new XML elements, attributes, and so on.

Therefore, it is entirely up to you to use custom extensions. Several factors influence this decision (use of graphic editors, company policy, etc.). We only provide them because we believe there are points in the standard that can be done more simply or efficiently. Feel free to provide us with (positive and/or negative) feedback on our extensions, or post new ideas for custom extensions. Who knows, one day your idea might be in the specification!

activity

Events are used to model what happens during the lifecycle. Events are always visualized as a circle. In BPMN 2.0, there are two main categories of events: catch or throw events.

Capture: When the process execution reaches the event, it waits for the trigger to occur. Trigger types are defined by internal ICONS or type declarations in XML. The capture event is visually distinguished from the throw event by the unfilled inner icon (white).

Throw: Triggers when the process execution reaches an event. Trigger types are defined by internal ICONS or type declarations in XML. The throw event is visually distinguished from the capture event by filling it with black internal ICONS.

An event definition

Event definitions define the semantics of events. There is no event definition and events are “nothing special”. For example, a start event without an and event definition does not specify what the start process is. If we add an event definition to a start event (such as a timer event definition), we declare what “type” of event starts the process (in the case of a timer event definition, the fact that a certain point in time has been reached).

Timer Event Definition

A timer event is an event triggered by a defined timer. They can be used as start events, intermediate events, or boundary events. The behavior of time events depends on the business calendar used. Each timer event has a default business calendar, but you can also define a business calendar on the timer event definition.

<timerEventDefinition activiti:businessCalendarName="custom">.</timerEventDefinition>
Copy the code

Where businessCalendarName points to the business calendar in the process engine configuration. When the business calendar is omitted, the default business calendar is used.

A timer definition must contain only one of the following elements:

Time date. This format specifies, in ISO 8601 format, a fixed date when the trigger is triggered. Example:

<timerEventDefinition>
    <timeDate>2011-03-11T12:13:14</timeDate>
</timerEventDefinition>
Copy the code

Time Duration. To specify how long a timer should run before firing, you can specify timeDuration as a child of timerEventDefinition. The format used is ISO 8601 (as required by the BPMN 2.0 specification). Example (interval lasting 10 days) :

<timerEventDefinition>
    <timeDuration>P10D</timeDuration>
</timerEventDefinition>

Copy the code

Time period. Specify the repetition interval, which is useful for periodically starting the process or for sending multiple reminders for expired user tasks. The time period element can have two formats. The first is the cycle duration format prescribed by the ISO 8601 standard. Example (3 repetition intervals, each lasting 10 hours) :

There is also the possibility of specifying the EndDate for the optional attribute timeCycle or either at the end of the time expression as follows: R3/PT10H/ EndDate. When the end date is reached, the application stops creating additional jobs for this task. It accepts a static value of the ISO8601 standard (for example, “2015−02−25T16:42:11+00:00”) or a variable {EndDate}. When the end date is reached, the application stops creating additional jobs for this task. It accepts a static value of the ISO 8601 standard (for example, “2015-02-25T16:42:11+00:00”) or the variable EndDate. When the end date is reached, the application stops creating additional jobs for this task. It accepts a static value of the ISO8601 standard (for example, “2015−02−25T16:42:11+00:00”) or a variable {EndDate} as a value

<timerEventDefinition>
    <timeCycle activiti:endDate="2015-02-25T16:42:11+00:00">R3/PT10H</timeCycle>
</timerEventDefinition>
Copy the code

<timerEventDefinition>
    <timeCycle>R3/PT10H/${EndDate}</timeCycle>
</timerEventDefinition>
Copy the code

If both are specified, the system uses the end date specified as the attribute.

Only BoundaryTimerEvents and CatchTimerEvent currently support EndDate.

In addition, you can specify a time period using cron expressions, and the following example shows that triggers fire every 5 minutes, starting at the full hour:

0 0/5* * *?Copy the code

See this tutorial to use cron expressions.

Note: The first symbol represents seconds, not minutes in normal Unix CRon.

Loop durations are better suited for dealing with relative timers, which are calculated for a specific point in time (for example, when a user task starts), whereas CRon expressions can handle absolute timers – especially useful for timer start events.

You can use expressions defined by timer events so that you can influence the timer definition based on process variables. The procedure variable must contain an ISO 8601 (or crON for loop type) string for the appropriate timer type.

<boundaryEvent id="escalationTimer" cancelActivity="true" attachedToRef="firstLineSupport">
  <timerEventDefinition>
    <timeDuration>${duration}</timeDuration>
  </timerEventDefinition>
</boundaryEvent>
Copy the code

Note: When the job or asynchronous execution timer is enabled, only start (i.e. JobExecutorActivate or asyncExecutorActivate needs to be set to true in activiti.cfg.xml, because work and asynchronous execution are disabled by default).