Bug 1015221 - Generated process which has an escalation definition uses the 'ID' attribute not the 'errorCode' to identify it in an event.
Generated process which has an escalation definition uses the 'ID' attribute ...
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
high Severity medium
: ER5
: 6.0.0
Assigned To: Marco Rietveld
Marek Baluch
Depends On:
  Show dependency treegraph
Reported: 2013-10-03 12:53 EDT by Marek Baluch
Modified: 2016-09-20 01:04 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:13:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Eclipse Project 418607 None None None Never

  None (edit)
Description Marek Baluch 2013-10-03 12:53:35 EDT
Description of problem:

See linked issue.
Comment 2 Kris Verlaenen 2013-10-03 18:04:13 EDT
Marco, it seems you changed the escalation handler to make sure escalations are referenced by escalationCode, not id.  I believe that may be incorrect, as escalationCode is just a string type, that would mean the type of escalationRef doesn't match.  I believe escalationRef in escalationEventDefinition probably needs to point to the id anyway.

It used to be like that, but you recently changed it:

I couldn't find a lot of examples, ended up bumping on one of yours even, which I believe is correct:
Comment 3 Marco Rietveld 2013-10-04 08:26:27 EDT
Hi Kris, 

Would you mind taking a look at table 8.42 in the BPMN2 spec? It looks like your initial implementation was incorrect, which was why I changed it. 

Comment 4 Marco Rietveld 2013-10-04 09:17:18 EDT

I also just looked in Silver's BPMN Method & Style (v2) and it says this, on page 232: 

"errorCode and escalationCode are simple strings to match throw-catch pairs. Throwing events must provide it, but it is optional for boundary events."
"An Error boundaryEvent will catch any error signal with matching errorCode thrown from a child level event, and similarly for Escalation."

Unfortunately, we don't yet support "general" error and escalation boundary events because there's no way to determine the origin of a thrown error or escalation event in the jbpm engine code (and wheyther or not it's from a child level event). Ironically, this is a very similar problem what we have with compensation. 

In any case, it seems pretty clear to me that escalationCode is the proper attribute to refer to the Escalation being caught. 

Comment 5 Marco Rietveld 2013-10-07 07:02:54 EDT
Waiting on Kris to confirm or deny that my comments above on the spec.
Comment 6 Kris Verlaenen 2013-10-07 08:12:44 EDT

I think the explanations above do make sense, and they refer to the behaviour of these nodes at runtime, but I don't think that they have any implications on the XML level that the errorCode must be used in references.

I do understand that different event nodes (throwing and catching escalation) are "paired" by using the same errorCode for both of them.  However, this imho doesn't implicate that the escalationRef (that an escalationEventDefinition uses to reference its escalation element, which contains the escalationCode) must be the escalationCode, and not the id of the escalation.  I believe that references must always use the id, an escalationCode simply is not unique so cannot be used for this purpose really.  

So to have a paired throwing and catching escalation event, I believe either 
 * both events have an escalationEventDefinition referring to the same escalation (by id, so same id for both) and therefore share the same escalationCode
 * both events have an escalationEventDefinition referring to a different escalation (by id, so each having a different id to refer to their specific escalation element), but these two escalations have the same escalationCode

Comment 8 Marek Baluch 2013-12-03 15:28:13 EST
Verified on ER5.

Note You need to log in before you can comment on or make changes to this bug.