BPMN21 — Inconsistencies and contradictions concerning Error element

ANTECEDENTS:

i) Chapter/Section 8.3.3. Page 82. Table 8.41. Row “name”. It says:
“name : string”
It means that “name” is mandatory.

ii) Chapter/Section 8.3.3. Page 82. Table 8.41. Row “errorCode”. It says:
“errorCode: string”
It means that “errorCode” 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 8.4.3. Page 105. It says:
“An Operation defines Messages that are consumed and, optionally, produced when the Operation is called. It can also define zero or more errors that are returned when operation fails.” (see Figure 8.36, p.104, Table 8.66, p. 106).

iv) 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.”

v) Chapter/Section 10.4.2. Page 250. Table 10.86. Row “Error”. It says:
“The Error 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 ErrorEventDefinition, then the Event is an Error Start Event and uses a lightning marker (see the figures to the right). Given the nature of Errors, an Event Sub-Process with an Error trigger will always interrupt its containing Process.”

vi) Chapter/Section 10.4.3. Page 255. Table 10.88. Row “Error”. It says:
“This type of End indicates that a named Error should be generated. All currently active threads in the particular Sub-Process are terminated as a result. The Error will be caught by a Catch Error Intermediate Event with the same errorCode or no errorCode 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 Error Intermediate Event. The system executing the process can define additional Error handling in this case, a common one being termination of the Process instance.”

vii) Chapter/Section 10.4.4. Page 263. Table 10.90. Row “Error”. It says:
“A catch Intermediate Error Event can only be attached to the boundary of an Activity, i.e., it MAY NOT be used in normal flow. If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified. Note that an Error Event always interrupts the Activity to which it is attached, i.e., there is not a non-interrupting version of this Event. The boundary of the Event thus always solid (see figure on the right).”

viii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row “Error”.
Three Error Event Definitions are shown:
Start Event Sub-Process (Interrupting)
Intermediate Event attached to the boundary of an Activity (interrupting)
End Event.

ix) Chapter/Section 10.4.5. Page 274. Table 10.96. Row “error”. It says:
“error: Error [0..1]”
It means that “error” is optional. (By the way, its name should be errorRef, see Figure 10.80, p.274).

COMMENTS:

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

• in (vi) the sentence “This type of End indicates that a named Error should be generated” is incorrect.
• in (vii) the sentence “If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified” is incorrect.

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

In (ii) Intermediate Event within normal flow is identified, but it is incorrect, because it doesn’t exist as it is stated in (vii) and (viii). Furthermore, Start Event Sub-Process (Interrupting) is not identified in (ii), but it is in (viii).

In (ii) when describing End Event, it is said “If the result is an Error, then the errorCode MUST be supplied (if the processType attribute of the Process is set to executable) This “throws” the Error.” It is confusing because the Error is actually thrown when an instance of Error (the “errorRef” of the ErrorEventDefinition) is thrown.

In (iii) it is said that Operations use Errors too. Nevertheless, Errors are described as if they were associated only with Events.

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

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

In (vi) the expression “named Error” is used, which (as stated above) is incorrect. It can be deduced that when an Error is thrown by the End Event it must contain an errorCode. But it not clear if an Error End Event must or must not throw an Error (which is optional, see ix). Besides, the Error can be catching by a Event Sub-Process, what it is not mentioned in (vi).

In (vii) the expression “named Error” is used, which (as stated above) is incorrect. It seems that “name” is used instead of “errorCode”. It is not clear what happen when no Error is associated to de EventDefinition: Does it react as if an Error without errorCode where associated?

In (ix) attribute errorRef is optional, but there are no rules concerning when and where an Error 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 Error is provided, in consequence no errorCode could be supplied.

Summary of problems:

• The name of the Error cannot be used to match Errors, errorCode must be used instead.
• According to some descriptions errorCode must be optional.
• According to the meta-model errorRef is optional, but it is not clear when and where this attribute should be provided.
• Error is described as if it were used by Events only, but it used by Operation too.

SUGGESTIONS:

• Remove all references to “named Errors” and the use of attribute “name” as a matching mechanism.
• Define whether errorRef (in ErrorEventDefinition element) will be optional or not.
• Define whether errorCode (in Error element) will be optional or not.
• Describe all rules concerning errorRef and errorCode in Tables 10.86, 10.88 and 10.90 (where Error Start Event, Error End Event and Error Intermediate Event are described).
• Describe rules concerning the use or Errors by Operations in section 8.4.3.
• Remove from Tables 8.41 and 10.96 (where Error and ErrorEventDefinition are described) the rules concerning Events (remember that Errors are used by Operations too, and in the future more BPMN element could used Errors too).

At least these issues should be clarified:

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

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

c) If errorCode (in Error element) is optional:

• Is errorCode optional for a throwing Error End Event?
• Is errorCode optional for a catching Error Start and Intermediate Events?

d) Can two instances of Error share the same errorCode?

• If the modeler want to match two Error Events (one throwing and one catching),
  must he/she provide the same Error to both ErrorEventDefinitions or two different Errors with the same errorCode? (According to the meta-model both alternatives are allowed, see Figure 10.80.)