IBM ACE V12 Developer: Developing Message Flows with ESQL and Java

Developing message flows with ESQL and Java

This domain tests message-tree navigation, ESQL modules and procedures, and JavaCompute integration with the ACE Java API. You must know the difference between InputRoot, OutputRoot, Environment, LocalEnvironment, and Shared variables, and how a JavaCompute node propagates an assembly.

Core rules

• ESQL field references are case-sensitive and array subscripts start at 1. Use [] cardinality when iterating repeating fields.
• Create output structure before assigning it: CREATE FIELD OutputRoot.XMLNSC.Order; then set children.
• Use Environment for per-message data that should survive nodes; use LocalEnvironment for routing and destination lists; use Shared variables for read-mostly cache data.
• A JavaCompute class extends MbJavaComputeNode and implements evaluate(MbMessageAssembly inAssembly). Build or modify the output assembly, then call propagate(inAssembly, outAssembly) exactly once on the success path.
• Catch and handle exceptions deliberately; do not swallow them and continue with a half-built tree.

Worked example

A JSON order contains repeating lines. In ESQL, declare an integer index, loop over InputRoot.JSON.Data.lines.Item[], copy quantity and price to OutputRoot.XMLNSC.Order.Line[i], and accumulate a total in a variable. Set the total field after the loop. In Java, obtain the input assembly, create an MbElement for the output root, copy the required fields, attach the new assembly to the output message, and propagate. If validation fails, throw an exception or route to a failure terminal.

Traps

Forgetting that ESQL arrays are 1-based causes off-by-one errors. Assigning to OutputRoot without creating the parent loses data. A JavaCompute node that never calls propagate produces no output. Using LocalEnvironment as a general-purpose cache is wrong; use Shared variables.