ESBExit

Get Shared Variable

Reads engine-wide state. The generator emits setBody from an exchange property named after the reading activity, which is never the name the write used.

Caveat com.tibco.pe.core.GetSharedVariableActivity

What it does in BusinessWorks

Reads a Shared Variable resource named in <config><variableConfig>. The activity takes no input mapping, since the resource path is the whole configuration, and its output is the current value of the variable, addressable downstream as $GetVariable/... like any other activity output.

What “current” means comes from the resource. A Job Shared Variable returns this job’s copy, initialised from the resource default at job start. A plain Shared Variable returns the engine-wide value as it stands at the moment of the read, which is why reads of a variable that other jobs write are usually paired with a Critical Section.

The message being processed is untouched. Reading a variable adds an activity output; it does not replace anything.

The Camel equivalent

BusinessWorks 5.process
<pd:activity name="GetVariable">
  <pd:type>com.tibco.pe.core.GetSharedVariableActivity
  </pd:type>
  <pd:resourceType>ae.activities.getSharedVariable
  </pd:resourceType>
  <config>
    <variableConfig>/config/PoolState.sharedvariable
    </variableConfig>
  </config>
  <pd:inputBindings/>
</pd:activity>
Apache CamelJava DSL, generated
// the whole activity, as emitted
.setBody(simple("${exchangeProperty.GetVariable}"))

Where the semantics diverge

It reads its own name. The property is keyed on the reading activity, so the route asks for ${exchangeProperty.GetVariable}. The write, if the process had one, stored ${exchangeProperty.SetVariable}. Unless a writer happens to carry the identical Designer name, the read resolves to nothing. This is not a corner case: the two names are chosen independently by whoever drew the process, and the resource path that connected them is not read by either rule.

It overwrites the body. In BusinessWorks the value lands in the activity’s output slot and the message in flight carries on unchanged. .setBody(...) replaces the body, so from that step onward the payload is gone. Anything downstream that expected the original message: a marshal, an XPath, a .to(...) that sends it on, is now working on the variable, or on nothing.

An unset property is not an error. simple("${exchangeProperty.X}") on a property that was never set evaluates to null. The route runs, the body becomes empty, and the failure shows up later as an empty request or a null-pointer inside a bean. Compare BusinessWorks, where a Job Shared Variable always has the resource default.

Engine-wide reads have no equivalent at all. There is no shared store behind the property, so the question of what value a concurrent job would see does not arise. Neither does the answer.

Fix the write and the read together, or not at all. Deciding what the variable becomes (a header, a cached record, a database row) is the same decision described under Set Shared Variable, and doing it on one side alone leaves the route worse than it started.

What the toolchain does

A rule with internal conditions, counted as a caveat. It emits one step, .setBody(simple("${exchangeProperty.<sanitised activity name>}")), and reads nothing from the activity’s configuration. No marker is emitted, so a read that can never resolve looks identical to one that can.

Related activities