Using scratchpad areas in LocalEnvironment

The LocalEnvironment tree includes a subtree called Variables. This is always created, but is never populated by the message flow. Use this area for your own purposes, for example to pass information from one node to another. You can create other subtrees in the LocalEnvironment tree if you choose.

Start of changeThe advantage of creating your own data in a scratchpad in the LocalEnvironment is that this data can be propagated as part of the logical tree to subsequent nodes in the message flow. If you create a new output message in a Compute node, you can also include all or part of the LocalEnvironment tree from the input message in the new output message. End of change

Start of changeTo ensure that the information in the LocalEnvironment is propagated further down the flow, the Compute mode property of the Compute node must be set to include LocalEnvironment as part of the output tree (for example, specify LocalEnvironment and Message). See Setting the mode for further details about Compute mode.End of change

However, any data updates or additions that you make in one node are not retained if the message flows backwards through the message flow (for example, if an exception is thrown). If you create your own data, and want that data to be preserved throughout the message flow, you must use the Environment tree.

You can set values in the Variables subtree in a Compute node that are used later by another node (Compute, Database, or Filter) for some purpose that you determine when you configure the message flow.

Start of changeBecause LocalEnvironment is not in scope in a Compute node, InputLocalEnvironment and OutputLocalEnvironment must be used instead.End of change

Start of changeFor example, you might use the scratchpad in the LocalEnvironment to propagate the destination of an output message to subsequent nodes in a message flow. Your first Compute node determines that the output messages from this message flow must go to WebSphere MQ queues. Include the following ESQL to insert this information into the LocalEnvironment by setting the value of OutputLocation in the OutputLocalEnvironment:
SET OutputLocalEnvironment.Variables.OutputLocation = 'MQ';
End of change
Start of changeYour second Compute node can access this information from its input message. In the ESQL in this node, use the correlation name InputLocalEnvironment to identify the LocalEnvironment tree within the input message that contains this data. The following ESQL sets queueManagerName and queueName based on the content of OutputLocation in the LocalEnvironment, using InputLocalEnvironment:
IF InputLocalEnvironment.Variables.OutputLocation = 'MQ' THEN
   SET OutputLocalEnvironment.Destination.MQ.DestinationData.queueManagerName = 'myQManagerName';
   SET OutputLocalEnvironment.Destination.MQ.DestinationData.queueName = 'myQueueName';
END IF;
End of change

Start of changeIn the example queueManagerName and queueName are set for the Destination subtree in the output message. The Compute mode of the second compute node must be set to include the LocalEnvironment tree in the output message. Configure the MQOutput node to use the destination list that you have created in the LocalEnvironment tree by setting property Destination Mode to Destination List.End of change

For information about the full list of elements in the DestinationData subtree, see Data types for elements in the DestinationData subtree.

Related concepts
Message flows overview
LocalEnvironment tree structure
ESQL overview
Related tasks
Designing a message flow
Related reference
Compute node
Database node
Filter node
Data types for elements in the DestinationData subtree
ESQL reference
SET statement