Bug 1015221

Summary: Generated process which has an escalation definition uses the 'ID' attribute not the 'errorCode' to identify it in an event.
Product: [Retired] JBoss BPMS Platform 6 Reporter: Marek Baluch <mbaluch>
Component: jBPM CoreAssignee: Marco Rietveld <mrietvel>
Status: CLOSED CURRENTRELEASE QA Contact: Marek Baluch <mbaluch>
Severity: medium Docs Contact:
Priority: high    
Version: 6.0.0CC: kverlaen, smcgowan
Target Milestone: ER5   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-06 20:13:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marek Baluch 2013-10-03 16:53:35 UTC
Description of problem:

See linked issue.

Comment 2 Kris Verlaenen 2013-10-03 22:04:13 UTC
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:
https://github.com/droolsjbpm/jbpm/commit/dce8c01c36009521e6b4e59cb23ffafd2337261a#diff-5380748f8963db99f9a156e84fca7cbaL72

I couldn't find a lot of examples, ended up bumping on one of yours even, which I believe is correct:
https://github.com/mrietveld/jbpm-more-examples/blob/master/exception-handling/src/main/resources/intermediate-throw-escalation-process.bpmn2#L87

Comment 3 Marco Rietveld 2013-10-04 12:26:27 UTC
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. 

Thanks!
marco

Comment 4 Marco Rietveld 2013-10-04 13:17:18 UTC
Kris, 

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. 

Thanks,
Marco

Comment 5 Marco Rietveld 2013-10-07 11:02:54 UTC
Waiting on Kris to confirm or deny that my comments above on the spec.

Comment 6 Kris Verlaenen 2013-10-07 12:12:44 UTC
Marco,

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

Kris

Comment 8 Marek Baluch 2013-12-03 20:28:13 UTC
Verified on ER5.