State of variables following bpel:invalidVariables fault
Switching the order of the paragraphs would make
this clearer - at least to me.
Here are the paragraphs in context:
The
optional keepSrcElementName attribute of the <copy>
construct is used to specify whether the element name of the
destination (as selected by the to-spec) will be replaced by the
element name of the source (as selected by the from-spec) during the
copy operation. See section 8.4.1, Replacement Logic of Copy
Operations.
The optional validate
attribute can be used with the <assign> activity. When validate is set to "yes", the <assign> activity validates all the variables being modified by the
activity. A WS-BPEL implementation MAY provide a mechanism to turn
on/off any explicit validation. E.g. validate
attribute at assign.
If the "validate" part of the assign activity fails, that
is, one of the variables is invalid against its correponding XML
definition, a standard fault of "bpel:invalidVariables" fault MUST be
thrown.
If there is any fault during the execution of an
assignment activity the destination variables MUST be left unchanged,
as they were at the start of the activity (as if the assign activity
were atomic). This applies regardless of the number of assignment
elements within the overall assignment activity.
The assign activity MUST be executed as if, for the duration of
its execution, it was the only activity in the process being executed.
Mark,
The way that I read is: yes the "bpel:invalidVariables"
fault (just like any fault happens during <assign>, e.g.
selectionFailure ) will revert variables back to original state before
the execution of <assign>.
The current text is relatively clear to me. If other people think the
text is still unclear, please feel free to voice suggested
clarification text.
Regards,
Alex Yiu
Mark Ford wrote:
The following two paragraphs are
from Section 8.4:
--- begin spec text ---
If there is any fault during the
execution of an assignment activity the destination variables MUST be
left unchanged, as they were at the start of the activity (as if the
assign activity were atomic). This applies regardless of the number of
assignment elements within the overall assignment activity.
If the "validate" part of the
assign activity fails, that is, one of the variables is invalid against
its correponding XML definition, a standard fault of
"bpel:invalidVariables" fault MUST be thrown.
--- end spec text ---
Does this fault cause the variables
to revert back to their original state? My first thought was that it
wouldn't since the first paragraph was probably written with the copy
operations in mind, however, it could be read either way.
Is this an issue or is it an action
item? Please advise.
Thanks.