Assign

What it does in BusinessWorks

Assign writes to a process variable declared on the process, named in <config><variableName>. The value comes from the activity’s input mapping, so it is an XSLT fragment evaluated against the current data space, not a literal. A variable can hold a whole schema-typed element, not only a scalar, and later activities address it as $Variable/... exactly like an activity output.

Scope is the job. Every Assign to the same variable overwrites it, and the last write before a read is the one that counts, which makes Assign the usual way of carrying a value across a long process without threading it through every mapping.

The Camel equivalent

<pd:activity name="Assign">
  <pd:type>com.tibco.pe.core.AssignActivity</pd:type>
  <pd:resourceType>ae.activities.assignActivity
  </pd:resourceType>
  <config>
    <variableName>Error</variableName>
  </config>
  <pd:inputBindings>
    <error>
      <errorCode>
        <xsl:value-of select="'1000'"/>
      </errorCode>
      <errorMessage>
        <xsl:value-of select="'Unsupported operation'"/>
      </errorMessage>
    </error>
  </pd:inputBindings>
</pd:activity>

// the whole activity, as emitted
.setProperty("Assign", constant(
  "<xsl:value-of select=\"'1000'\" xmlns:xsl=\"http:
   //www.w3.org/1999/XSL/Transform\"/>"))

Where the semantics diverge

The XSLT is stored, not evaluated. The rule takes the first non-empty input binding and passes its source text straight into constant(...). The exchange property ends up holding the string <xsl:value-of select="'1000'"/>, not 1000. Other rules in the generator do convert XSL: the Mapper rule runs it through the expression translator, but this one does not. Every Assign in the output is a literal fragment of the source file.

The property is named after the activity, not the variable. <variableName> is never read. An estate where three Assign activities write one variable produces three unrelated properties, and nothing reads the variable at all. Designer names repeated activities Assign 1, Assign 2, and the rule replaces the space, so the properties come out as Assign_1 and Assign_2: three distinct keys where the source had one variable.

Only the first field survives. Bindings are flattened to leaves in document order and the rule takes the first one. In the example above errorMessage is gone. A multi-field Assign, which is the normal case for anything holding a fault or a context record, comes out as a single string.

Long mappings are cut. Binding values are truncated at 800 characters when the process file is parsed, so a large xsl:choose reaches the property mid-element. The result still compiles, since it is only a string.

Type is lost either way. A BusinessWorks variable is a schema-typed element; an exchange property is an untyped object. Even with the value evaluated, XPath over it would not work without converting it back to a document first.

Treat every Assign in the output as a placeholder that records where a variable used to be. What replaces it depends on how the variable was read: a header when the value is scalar and used once, an exchange property with a real simple or xpath expression when it is read repeatedly, and a typed object on the exchange when it held a document.

What the toolchain does

A rule with internal conditions, so the report counts it as a caveat rather than a translation. It emits exactly one step: .setProperty("<sanitised activity name>", constant("<first binding value>")). Non-alphanumeric characters in the name become underscores, and a name starting with a digit is prefixed with x. When the activity has no usable input binding the value falls back to simple("${body}"), which captures whatever is on the exchange at that point.

No marker is emitted, which is worth saying plainly: an Assign that carries nothing forward looks the same in the generated code as one that works.