OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: New Issue - Status of links after error in transitionCondition


Title: New Issue - Status of links after error in transitionCondition

Section 11.6.2 states that when an activity has multiple outgoing links, the order in which the status of the links and the associated transition conditions are evaluated is defined to be sequential, according to the order the links are declared in the <source> element.

The resolution for Issue 169 added text that stops the evaluation of the remaining links after the first fault. These other links will remain in an unset state. The problem is that these other links may cross the boundary of the scope that catches the fault and leave the target activities in a state where they'll never be executed due to the status of their links being unset.

Consider the following example:

<flow name="F1">
   <links>
      <link name="linkE1_causesFault"/>
      <link name="linkE2_neverEvaluated"/>
   </links>
   <scope name="S1">
      <flow name="F2">
         <empty name="E1">
            <sources>
               <source linkName="linkE1_causesFault">
                  <transitionCondition>
                      --- some expression that faults ---
                  </transitionCondition>
                   </source>
               <source linkName="linkE2_neverEvaluated"/>
            </sources>
         </empty>
         <empty name="E2">
            <targets>
               <target linkName="linkE1_causesFault"/>
            </targets>
         </empty>
      </flow>
      <faultHandlers><catchAll>...</catchAll></faultHandlers>
   </scope>
   <empty name="E3">
      <targets>
         <target linkName="linkE2_neverEvaluated"/>
      </targets>
   </empty>
</flow>

Here are the steps:
1. E1 completes normally.
2. E1's links are evaluated sequentially
3. The first link named "linkE1_causesFault" contains a transitionCondition that faults when it executes.
4. The remaining outbound links for E1 MUST NOT be evaluated and remain in unset state (as does the link that faulted)
5. Scope S1 catches the fault and does nothing
6. S1 completes
7.  Flow F1 cannot complete until E3 completes or goes dead path. E3 will not complete or go dead path until the state of its links are known.

This same section contains text that handles the case of the faulting link crossing a scope boundary. In this case, the link is set to false instead of being left in the unset state. This same text should apply to all of the unevaluated links that cross a scope boundary.

Submitters proposal:

Change the text introduced by Issue 169's resolution to account for unevaluated links that cross a scope boundary by requiring that they be set to false.

From:

If an error occurs while evaluating the transition condition of one of an activity's outgoing links, then all remaining outgoing links from that activity as well as their associated transition conditions MUST NOT be evaluated.  There is no difference in the status of the link that faults on transition condition evaluation and one whose transition condition has not been evaluated.

To:

If an error occurs while evaluating the transition condition of one of an activity's outgoing links, then all remaining outgoing links with targets within the source activity's enclosing scope MUST NOT have their transition conditions evaluated and remain in the unset state. If the target of a remaining outgoing link is outside the source activity's enclosing scope then the status of the link MUST be set to false. There is no difference in the status of the link that faults on transition condition evaluation and one whose transition condition has not been evaluated.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]