BPMN21 — Inconsistencies and contradictions concerning Escalation element

ANTECEDENTS:

i) Chapter/Section 8.3.4. Page 83. Table 8.42. Row “name”. It says:
“name : string”
It means that “name” is mandatory.

ii) Chapter/Section 8.3.4. Page 83. Table 8.42. Row “escalationCode”.
“escalationCode: string”
It means that “escalationCode” is mandatory.
When describing this attribute three cases are identified:

• End Event
• Intermediate Event within normal flow
• Intermediate Event attached to the boundary of an Activity

iii) Chapter/Section 10.4.1. Page 242. It says:
“A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger …. If no catching Event is found for an error or escalation trigger, this trigger is unresolved.”

iv) Chapter/Section 10.4.2. Page 250. Table 10.86. Row “Escalation”. It says:
“Escalation Event Sub-Processes implement measures to expedite the completion of a business Activity, should it not satisfy a constraint specified on its execution (such as a time-based deadline). The Escalation Start Event is only allowed for triggering an in-line Event Sub- Process. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass EscalationEventDefinition, then the Event is an Escalation Start Event and uses an arrowhead marker…”

v) Chapter/Section 10.4.3. Page 255. Table 10.88. Row “Escalation”. It says:
“This type of End indicates that an Escalation should be triggered. Other active threads are not affected by this and continue to be executed. The Escalation will be caught by a Catch Escalation Intermediate Event with the same escalationCode or no escalationCode which is on the boundary of the nearest enclosing parent Activity (hierarchically). The behavior of the Process is unspecified if no Activity in the hierarchy has such an Escalation Intermediate Event.”

vi) Chapter/Section 10.4.4. Page 263. Table 10.90. Row “Escalation”. It says:
“This type of Event is used for handling a named Escalation. If attached to the boundary of an Activity, the Intermediate Event catches an Escalation. In contrast to an Error, an Escalation by default is assumed to not abort the Activity to which the boundary Event is attached...”

vii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row “Escalation”.
Six Escalation Event Definitions are shown:
Start Event Sub-Process (Interrupting and non-interrupting)
Intermediate Event attached to the boundary of an Activity (interrupting and non-interrupting)
Intermediate Event within normal flow
End Event

viii) Chapter/Section 10.4.5. Page 275. Table 10.97. Row “escalationRef”. It says:
“escalationRef: Escalation [0..1]”
It means that “escalationRef” is optional.

COMMENTS:

In the name of an Escalation is mandatory, it means that the expression “named Escalation” carries no information, because every Escalation “is named”. Furthermore, the name of the Escalation is not used to identify it, the attribute escalationCode is used instead.
Then:

• in (vi) the sentence “This type of Event is used for handling a named Escalation” is incorrect.

In (ii) the attribute escalationCode should be optional ([0..1]), because sometimes escalationCode is not supplied (according to descriptions in Tables 8.42 and 10.88; it is mandatory only when the processType attribute of the Process is set to executable).

In (ii) Start Event Sub-Process (Interrupting) is not identified in, but it is in (vii).

In (ii) when describing End Event, it is said “If the Result is an Escalation, then the escalationCode MUST be supplied (if the processType attribute of the Process is set to executable). This “throws” the Escalation.” It is confusing because the Escalation is actually thrown when an instance of Escalation (the “escalationRef” of the EscalationEventDefinition) is thrown.

In (iii), according to meta-model a catching Escalation Event may not have an Escalation instance associated or can be associated to an Escalation instance without escalationCode. In both cases “no catching Event is found”, but it is not clear whether both situations must be treated equally or not.

In (iv) nothing is said about the presence or absence of escalationCode as in (v).

In (v) it can be deduced that when an Escalation is thrown by the End Event it must contain an escalationCode. But it not clear if an Escalation End Event must or must not throw an Escalation (which is optional, see viii). Besides, the Escalation can be catching by a Event Sub-Process, what it is not mentioned in (v).

In (vi) the expression “named Escalation” is used, which (as stated above) is incorrect. Furthermore, nothing is said about the presence or absence of escalationCode as in (v).

In (viii) attribute escalationRef is optional, but there no rules concerning when and where an Escalation should be thrown. Nothing is said about processType attribute of the Process. So, it is possible that “processType attribute of the Process is set to executable” and no Escalation is provided, in consequence no escalationCode could be supplied.

Summary of problems:

• The name of the Escalation cannot be used to match Escalations, escalationCode must be used instead.
• According to some descriptions escalationCode must be optional.
• According to the meta-model escalationRef is optional, but it is not clear when and where this attribute should be provided.
• Escalation is described as if it were used by Events only, but in the future it could used by others elements (as Error is used by Events and Operations).

SUGGESTIONS:

• Remove all references to “named Escalations” and the use of attribute “name” as a matching mechanism.
• Define whether escalationRef (in EscalationEventDefinition element) will be optional or not.
• Define whether escalationCode (in Escalation element) will be optional or not.
• Describe all rules concerning escalationRef and escalationCode in Tables 10.86, 10.88 and 10.90 (where Escalation Start Event, Escalation End Event and Escalation Intermediate Event are described).
• Remove from Tables 8.42 and 10.97 (where Escalation and EscalationEventDefinition are described) the rules concerning Events (remember that Escalations could be used by other elements too).

At least these issues should be clarified:

a) If the processType attribute of the Process is set to executable, must escalationRef or escalationCode be supplied? or both?
b) If escalationRef (in EscalationrEventDefinition element) is optional:

• Is escalationRef optional for a throwing Escalation End and Intermediate Events?
• Is escalationRef optional for a catching Escalation Start and Intermediate Events?
  If this is the case, what happens when an Escalation arrives?

c) If escalationCode (in Escalation element) is optional:

• Is escalationCode optional for a throwing Escalation End and Intermediate Events?
• Is escalationCode optional for a catching Escalation Start and Intermediate Events?

d) Can two instances of Escalation share the same escalationCode?

• If the modeler want to match two Escalations Events (one throwing and one catching),
  must he/she provide the same Escalation to both EscalationEventDefinitions or two different Escalations with the same escalationCode? (According to the meta-model both alternatives are allowed, see Figure 10.82)