The <assign> activity can be used to copy data from one variable to another, as well as to construct
and insert new data using expressions. The <assign> activity can also be used to copy endpoint
references to and from partnerLinks.
Each <assign> is made up of any number of <copy> entries which are each made up of a "to-spec"
(lvalue), and a from-spec (rvalue).
ignoreMissingFormData - (optional) Should the bpel:selectionFailure standard fault be suppressed?
yes - the <assign> activity validates all the variables deing modified by the activity.
If the validation fails the bpel:invalidVariables fault is thrown.
no - (default) do not validate the modified variables
<copy> - defines a lvalue, rvalue pair.
keepSrcElementName - (optional) should the element name of the destination (as selected by the
to-spec) be replaced by the element name of the source(as selected by the from-spec)?
yes - element names are replaced
no - (default) element names are not replaced
<from> - specifies the rvalue
<to> - specifies the lvale
<extensionAssignOperation> - a container for assignment extensions. If the element contained
within the extensionAssignOperation elements not recognized by ODE and is not subject to a
mustUnderstand="yes" requirement from an extension declaration then the element will be ignored.
From/To-Spec Variants
The <assign> activity copies a type-compatible value from the source("from-spec") to the destination
("to-spec"), using <copy> element. The from-spec must be one of the following variants:
<tovariable="BPELVariableName"extension="QName"/><!-- WSO2 BPS SPECIFIC -->
A to-spec must return an lvalue. If a to-spec does not return an lvalue then a bpel:selectionFailure will be
thrown. In the context of XPath, an lvalue is a node-list containing a single node from a variable or a
partnerLink identified by the to-spec (e.g. the XPath expression concat("foo""bar") is not an lvalue).
Assignment is an atomic operation; that is, either all <copy> s succeed, or no changes are made.
In WSO2 BPS each <copy> is atomic
part - (optional) if the type of this variable is a WSDL messageType this attribute may be used to
provide the name of a part within that variable. This attribute must not be used when the variable is
defined using XML schema types or element.
<query> element may be used to select a value from the source or target variable or message part.
The computed value of the query must be one the following:
a sigle XML node, for example an attribute or an element
test(i. e. a text node, CDATA section, string-valued XPath expression, etc..)
PartnerLink Variant
Allows manipulation of the endpoint references associated with partnerLinks.
For from-specs, the role attribute must be specified, while for the to-spec, the assignment is only possible
to the partnerRole, hence there is no need to specify the role. Therefore, the to-spec can only refer to a
<partnerLink> of which the declaration specifies the partnerRole attribute. The type of the value referenced
by partnerLink-style from/to-specs is always a <sref:service-ref> element.
An attempt during process execution to read a partner link before its partnerRole EPR is initialized results
in the bpel:uninitializedPartnerRole standard fault. Partner roles of partner links are read when they are
referenced in an <invoke> or the <from> part of a <copy> in an <assign> activity.
Property Variant
Allows data manipulation using properties. The property value generated by the from-spec is generated in the
same manner as the value returned by the bpel:getVariableProperty() function.
expressionLanguage - (optional) identifies the expression language.
expression - the expression; syntax is determined by the expression language
The computed value of the expression must be one of the following:
a single XML node, for example an attribute or an element
text(i. e. a text node, CDATA section, string-valued XPath expression, etc..)
Literal Variant
The literal variant allows a literal value to be given as the rvalue.
<from><literal>literal value</literal></from>
literal value - value to be assigned
The type of the literal value may be optionally indicated inline with the value by using XML Schema's
instance type mechanism (xsi:type). The literal content must be either a single element or text. An empty
<literal/> element is equivalent to an empty text node.
Empty Variant
Empty variant exist for extensibility purposes; it is not supported by WSO2 BPS.
<from|to/>
Insert Variant(non-standard extension)
Faults
bpel:invalidVariables - A modified variable does not conform to its schema and the validate flag was set to yes.
bpel:selectionFailure - The node(s) selected by a from/to-spec is (are) invalid. This includes cases when the to-spec returns a node that is not an lvalue, when multiple nodes are selected, or when no node is selected.
bpel:subLanguageExecutionFault - Evaluating the expression (in the expression variant), or the query (in the variable variant) generated an error. For example, if a divide-by-zero is attempted.
bpel:uninitializedVariable - The variable referenced in the from-spec has not been initialized.
bpel:mismatchedAssignmentFailure - The nodes selected by the to-spec and from-spec are not compatible. This could occur if for example an attempt was made to assign a text node to an element variable, or an element variable was assigned to a message variable.
Examples
The following assigns a childless element bar in namespace http://example.com to an element-typed variable myFooBarElemVar:
The following illustrates copying one variable (c1) to another (c2) as well as copying a variable part (address part of variable c1) to a variable of compatible element type (c3):