Websphere Business Integration Message Broker 6.

INTRODUCTION
WebSphere Message Broker and WebSphere Event Broker belong to a family of business integration products that is available from IBM. Business integration is the coordination and cooperation of all your business processes and applications. It involves bringing together the data and process intelligence in your enterprise, and harnessing these so that your applications and your users can achieve their business goals.

Business integration
You can connect customers, suppliers, partners, and service providers, with continuing security and control, to enable newly built and re-engineered applications for more effective business processes (for example, Supply Chain Management). You can make mergers and acquisitions a success by integrating dissimilar IT infrastructures from more than one company so that they can work together as a single entity.

Contd
You can react more quickly to market trends and opportunities because your IT systems are flexible and dependable, and no longer constraining. You can overcome the barriers of diverse computer systems, geographic boundaries, time differences, language and format differences, and different methods of working.

Transports
The main components of WebSphere Message Broker and WebSphere Event Broker (the broker, the Configuration Manager, the User Name Server, and the Message Brokers Toolkit) communicate using WebSphere MQs communications protocol, WebSphere MQ Enterprise Transport, or, if you implement WebSphere MQ Everyplace, WebSphere MQ Mobile Transport.

Transports Contd
Your business applications, which can be on any of more than thirty industry platforms including those from IBM, Microsoft, and Sun Microsystems, Inc., can connect to the broker using WebSphere MQ protocols, or using other protocols, such as WebSphere MQ Telemetry Transport, WebSphere MQ Real-time Transport, WebSphere MQ Multicast Transport, WebSphere MQ Web Services Transport, or WebSphere Broker JMS Transport

Transports Contd
The benefit of using WebSphere MQ protocols (WebSphere MQ Enterprise Transport or WebSphere MQ Mobile Transport) is that they provide assured, once-only delivery of messages between the components.

WebSphere MQ protocols provide rich support for applications:

The Message Queue Interface (MQI) and Application Messaging Interface (AMI) are supported in several programming languages. The point-to-point (including request/reply and client/server) and publish/subscribe application communication models are supported.

Contd
The complexities of communications programming are handled by the messaging services and are therefore removed from the application logic. The applications can access other systems and interfaces through adapters and gateways to products such as Lotus Domino, Microsoft Exchange/Outlook, SAP/R3, and CICS and IMS/ESA products.

WebSphere Event Broker

WebSphere Event Broker provides an optimized publish and subscribe function within a limited WebSphere Message Broker framework. It provides highperformance nonpersistent publish and subscribe functionality to clients that are connected using various transports.

WebSphere Message Broker.

WebSphere Message Broker incorporates WebSphere Event Broker and extends its function to provide a powerful message broker solution driven by business rules. Messages are formed, routed, and transformed according to the rules defined by an easy-to-use graphical user interface (GUI).

Contd
Diverse applications can exchange information in dissimilar forms, with brokers handling the processing required for the information to arrive in the right place in the correct format, according to the rules that you have defined. The applications do not need to know anything except their own conventions and requirements.

Contd
Applications also have much greater flexibility in selecting which messages they want to receive, because they can specify a topic filter, or a content-based filter, or both, to control the messages that are made available to them. WebSphere Message Broker addresses the needs of business and application integration by managing the flow of information.

Contd
In addition to the function of WebSphere Event Broker, it provides services, which allows you to: Route a message to several destinations, using rules that act on the contents of one or more of the fields in the message or message header. Transform a message, so that applications using different formats can exchange messages in their own formats.

Contd
Store a message, or part of a message, in a database. Retrieve a message, or part of a message, from a database. Modify the contents of a message; for example, by adding data extracted from a database.

Contd
Exploit a public interface to develop message processing node types that can be incorporated into the broker framework to complement or replace the supplied nodes, or to incorporate node types developed by Independent Software Vendors (ISVs). Enable instrumentation by products such as those developed by Tivoli, using system management hooks.

WBIMB Technical Overview

Contd
There are two ways in which WebSphere Message Broker can act on messages. Message routing Messages can be routed from sender to recipient based on the content of the message.

Contd
The message flows that you design control message routing. A message flow describes the operations to be performed on the incoming message, and the sequence in which they are carried out. Each message flow consists of: A series of steps used to process a message. The steps are defined in message flow nodes.

Contd
Connections between the nodes, defining routes through the processing. Connections are made using message flow node connections. IBM supplies built-in nodes and samples for many common functions. If you require additional functions, you can write your own user-defined nodes.

Contd
You create message flows in the Message Brokers Toolkit; an integrated development environment and broker domain administration console. Message transformation Messages can be transformed before being delivered:

Contd
They can be transformed from one format to another, perhaps to accommodate the different requirements of the sender and the recipient. They can be transformed by modifying, combining, adding or removing data fields, perhaps involving the use of information stored in a database. Information can be mapped between messages and databases. More complex manipulation of message data can be achieved by using Extended SQL (ESQL).

Create the run time

The work of routing and transforming messages takes place in a broker. Brokers contain a number of execution groups; processes in which message flows are run. Brokers are grouped into broker domains. Each domain is coordinated by a Configuration Manager. There can be many brokers, and each can be running on a different system. This provides protection against failure, and can separate work across different divisions in a business.

Contd
The system administrator creates the Configuration Manager with a command line instruction. The Configuration Manager uses an internal repository to store information relating to its broker domain. The system administrator similarly creates one or more brokers, linking each to a particular Configuration Manager, thus making them part of the domain controlled by that Configuration Manager. Each broker uses a database to store the information it needs to process messages at run time.

Contd
The Configuration Manager also displays the users and groups in the Access control lists that you use to set user permissions, see Publish/subscribe.

Develop applications
After the system administrator has created and connected the components of the broker domain, an application developer creates and modifies message flows and message definitions using the workbench. Different perspectives in the workbench are used to develop message flows and message sets as well as to administer one or more broker domains.

Contd
A repository can be used to provide access control and version control. A repository also allows multiple developers to work on the same resources in parallel.

Deploy applications to the run time

When message flows and message sets have been created using the workbench, executable data can be deployed (transferred) to one or more brokers. You can deploy data in one of two ways: From the workbench Using a shell command

Contd
When you deploy message flows and message sets, they are compiled and enveloped in a broker archive (bar) file, and sent to the Configuration Manager. The bar file has configurable system properties. You can override properties such as queue and database names, without the need to change source files or redevelop the message flow. This makes it easier to move definitions between systems.

Contd
The Configuration Manager opens the envelope, removes the contents, makes a record of the information that it has received, and routes the information to the appropriate brokers. (The envelope is discarded when the information it contains has been retrieved.) Each broker stores the information in its own local database. This means that, when a broker has sufficient information, it can continue processing messages even if it is no longer connected to its Configuration Manager.

Contd
The Configuration Manager coordinates all activity (for example, changes to a message set) between the workbench and brokers within its domain. WebSphere MQ messaging is used between the workbench, the Configuration Manager, and the brokers.

Publish/subscribe
The simplest way of directing messages is to use point-to-point messaging, by sending messages directly from one application to another. Publish/subscribe provides an alternative style of messaging. A publishing application sends a message about a named topic to a broker. The broker passes the published message to those applications that have registered an interest in that topic. The publisher and the subscriber are unaware of the others existence.

Contd
The broker handles the distribution of messages between publishing applications and subscribing applications. Applications can publish on, or subscribe to, many topics as well as apply more sophisticated filtering mechanisms. An optional User Name Server in the broker domain controls who is authorized to publish or subscribe to topics. You set up and administer topic-based security from the workbench.

Client environment
The Message Brokers Toolkit is an integrated development environment and graphical user interface based on the Eclipse platform. Application developers work in separate instances of the Message Brokers Toolkit to develop message sets and message flows. The Message Brokers Toolkit also communicates with one or more Configuration Managers, and is used to manage broker domains. The Message Brokers Toolkit can be installed on Windows and Linux (x86 platform).

The workbench
When you start the Message Brokers Toolkit, a single window is displayed. This is the workbench, which contains one or more perspectives.

Perspectives
A perspective is a group of views and editors that shows various aspects of the resources in the workbench, and helps you to complete specific tasks. You can switch perspectives, depending on the task at hand, and customize the layout of views and editors. Switch between perspectives by clicking Window Open Perspective Other and clicking the name of the perspective to which you want to switch.

Contd
The Message Brokers Toolkit contains the following perspectives: Broker Application Development perspective
This is the default perspective that is displayed the first time that you start the Message Brokers Toolkit. Application developers work in this perspective to develop and modify message sets and message flows. Broker Administration perspective This is a broker administration console that communicates with one or more Configuration Managers. Administrators work in this perspective to manage the resources (also referred to as domain objects) in the broker domain that are defined on one or more Configuration Managers.

Contd
Debug perspective This is where application developers test and debug message flows. Plug-in Development perspective This is where application developers develop plug-ins for user-defined extensions. Data perspective This is where application developers import relational database schemas for ESQL content assist and validation.

Development repository
You can use any repository supported by Eclipse with WebSphere Message Broker. Many repositories provide features such as version control and access control of files, and make it easier for teams to work on shared resources. Because the Message Brokers Toolkit is based on the Eclipse platform, you can access Eclipsesupported repositories directly from the Message Brokers Toolkit.

Runtime environment
The runtime environment is the set of resources that exist at run time, including the Configuration Manager, brokers, and execution groups. The following figure shows the relationship between the resources that exist at run time, and how they interact with the workbench. The following are the main runtime components in WBIMB. Broker. Execution Group Broker Domain Configuration Manager User Name server

Contd

Brokers
A broker is a set of execution processes that hosts one or more message flows to route, transform, and enrich inflight messages. Applications send messages to the broker using WebSphere MQ queues and connections. The broker routes each message using the rules defined in message flows and message sets, and transforms the data into the structure required by the receiving application.

Execution groups:
The broker uses sender and receiver channels to communicate with the Configuration Manager and other brokers in the broker domain. An execution group is a named grouping of message flows that have been assigned to a broker. The broker enforces a degree of isolation between message flows in distinct execution groups by ensuring that they execute in separate address spaces, or as unique processes.

Contd
Each execution group is started as a separate operating system process, providing an isolated runtime environment for a set of deployed message flows. A single default execution group is set up ready for use when you create a reference to a broker in the workbench. By setting up additional execution groups, you can isolate message flows that handle sensitive data such as payroll records, or security information, or unannounced product information, from other non-sensitive message flows.

Contd
Within an execution group, the assigned message flows run in different thread pools. You can specify the size of the thread pool (that is, the number of threads) that are assigned for each message flow by specifying the number of additional instances of each message flow. If you create additional execution groups, you must give each group a name that is unique within the broker, and assign and deploy one or more message flows to each one.

Broker domains
A broker domain is one or more brokers that share a common configuration, together with the single Configuration Manager that controls them. You install, create, and start one or more brokers, and an optional User Name Server, in a broker domain. You can configure more than one broker domain, each managed by its own Configuration Manager.

Contd
The Configuration Manager uses an internal repository to store and share information about the resources and components in the domain. You create the physical components of a broker domain using command line instructions, and then configure and administer the broker domain using the Broker Administration perspective in the workbench.

Configuration Manager
The Configuration Manager is the interface between the workbench and an executing set of brokers. It provides brokers with their initial configuration, and updates them with any subsequent changes. It maintains the broker domain configuration. The Configuration Manager is the central runtime component that manages the components and resources that constitute the broker domain.

Contd
The Configuration Manager has four main functions: Maintains configuration details in an internal repository. This internal repository provides a central record of the broker domain components. Deploys the broker topology and message processing operations in response to actions initiated through the workbench. Broker archive (bar) files are deployed through the Configuration Manager to the execution groups within a broker.

Contd
Reports on the results of deployment and the status of the broker. Communicates with other components in the broker domain using WebSphere MQ transport services. You must install, create, and start a Configuration Manager for each broker domain. You can install, create, and start more than one Configuration Manager on one or more machines.

Contd
Resources associated with a Configuration Manager: When you create the Configuration Manager runtime component, the following resources are also created:
An internal repository.

Contd
A WebSphere MQ queue manager (unless one exists already) on the same physical system as the Configuration Manager. A queue manager can be shared with a single broker. A set of fixed-name queues, defined to the queue manager that hosts the Configuration Manager.

User Name Server

The User Name Server is an optional runtime component that provides authentication of users and groups performing publish/subscribe operations.

Contd
If you have applications that use the publish/subscribe services of a broker, you can apply an additional level of security to the topics on which messages are published and subscribed. This additional security, known as topic-based security, is managed by the User Name Server. It provides administrative control over who can publish and who can subscribe.

Contd
For example, if a client application publishes messages containing sensitive company finance information, or personnel details, the User Name Server can be used to restrict access to those messages. The User Name Server interfaces with operating system facilities to provide information about valid users and groups in a broker domain.

Message Flows

Overview
A message flow is a sequence of processing steps that execute in the broker when an input message is received. You define a message flow in the workbench by including a number of message flow nodes, each of which represents a set of actions that define a processing step. The connections in the flow determine which processing steps are carried out, in which order, and under which conditions.

Contd
A message flow must include an input node that provides the source of the messages that are processed. You must then deploy the message flow to a broker for execution. When you want to exchange messages between multiple applications, you might find that the applications do not understand or expect messages in exactly the same format.

Contd
You might need to provide some processing between the sending and receiving applications that ensures that both can continue to work unchanged, but can exchange messages successfully.

Message flow projects

A message flow project is a specialized container in which you create and maintain all the resources associated with one or more message flows. You can create a message flow project to contain a single message flow and its resources, or you can group together related message flows and resources in a single message flow project to provide an organizational structure to your message flow resources.

Contd
Message flow project resources are created as files, and are displayed within the project in the Navigator view. These resources define the content of the message flow, and additional objects that contain detailed configuration information, in the form of ESQL modules and mappings, for one or more nodes within the message flow.

Message flow nodes

A message flow node is a processing step in a message flow. It receives a message, performs a set of actions against the message, and optionally passes the message on to the next node in the message flow. A message flow node can be a built-in node , a user-defined node, or a subflow node. A message flow node has a fixed number of input and output points known as terminals. You can make connections between the terminals to define the routes that a message can take through a message flow.

Contd
Built-in node A built-in node is a message flow node that is supplied by WebSphere Message Broker. The built-in nodes provide input and output, manipulation and transformation, decision making, collating requests, and error handling and reporting functions.

Contd
User-defined node A user-defined node is an extension to the broker that provides a new message flow node in addition to those supplied with the product. It must be written to the userdefined node API provided by WebSphere Message Broker for both C and Java languages.

Contd
Subflow A subflow is a directed graph that is composed of message flow nodes and connectors and is designed to be embedded in a message flow or in another subflow. A subflow must include at least one Input node or one Output node. A subflow can be executed by a broker only as part of the message flow in which it is embedded, and therefore cannot be independently deployed.

Message flows And ESQL

A message flow represents the set of actions performed on a message when it is received and processed by a broker. The content and behavior of a message flow is defined by a set of files that you create when you complete your definition and configuration of the message flow content and structure:

Contd
The message flow definition file <message_flow_name>.msgflow. This is a required file and is created automatically for you. It contains details about the message flow characteristics and contents (for example, what nodes it includes, its promoted properties, and so on).

Contd
The ESQL resources file <message_flow_name>.esql. This file is required only if your message flow includes one or more of the nodes that must be customized using ESQL modules. You can create this file yourself, or you can use it to be created for you by requesting specific actions against a node.

Contd
You can customize the following built-in nodes by creating free-form ESQL statements that use the built-in ESQL statements and functions, and your own user-defined functions: Compute -- Database Filter

Connections And Terminal

Connections A connection is an entity that connects an output terminal of one message flow node to the input terminal of another. It represents the flow of control and data between two message flow nodes.

Contd
Terminals A terminal is the point at which one node in a message flow is connected to another node. Use terminals to control the route that a message takes, depending whether the operation performed by a node on that message is successful. Terminals are wired to other node terminals using message flow node connections to indicate the flow of control.

Message Tree
A message tree is a structure that is created by one or more parsers when an input message bitstream is received by a message flow or by the action of a message flow node. A message is used to describe: A set of business data exchanged by applications A set of elements arranged in a predefined structure. A structured sequence of bytes

Contd
WMB routes and manipulates messages after converting them into a logical tree. The process of conversion, called parsing, makes the content and structure of a message obvious, and simplifies later operations. After the message has been processed, the parser converts it back into a bitstream.

Contd
WMB supplies a range of parsers to handle the many different messaging standards in use. In some cases WMB will be able to parse your message automatically. Alternatively, the MRM provides a powerful method of modeling messages that you need to process. After a message has been parsed, it can be processed in a message flow.

Contd
The logical tree contains identical contents to that of the message but is easier to manipulate within the message flow. The message flow nodes provide an interface to query, update or create the content within the tree.

How the message tree is populated

The message tree is initially populated by the input node of the message flow. When the input node receives the input message, it creates the Properties tree (the first subtree of the message tree) and populates this with the node properties that you have configured in the message flow. It then examines the contents of the input message bit stream and creates the remainder of the message tree to reflect those contents.

Contd
This process depends to some extent on the input node itself, which is governed by the transport across which the message is received. WebSphere MQ Enterprise Transport, and WebSphere MQ Telemetry Transport protocols

Contd
If your application communicates with the broker across these protocols, and your message flow includes the corresponding MQInput, or SCADAInput node, all messages that are received must start with a Message Queue Message Descriptor (MQMD) header. If a valid MQMD is not present at the start of the message, the message is rejected and no further processing takes place.

Contd
The input node first invokes the MQMD parser and creates the subtree for that header. A message can have zero or more additional headers following the MQMD, and these are chained together, with the Format field of one header defining the format of the following header, up to and including the last header, which defines the format of the message body.

Contd
If there is an MQRFH and MQRFH2 header in the chain, the name/value data in either of these two headers can also contain information about the format of the following data. If the value specified in Format is a recognized parser, this always takes precedence over the name/value data. The broker invokes the appropriate parser to interpret each header, following the chain in the message.

Contd
The broker ensures that the integrity of the headers that precede a message body is maintained. The format of each part of the message is defined, either by the Format field in the immediately preceding header (if the following part is a recognized WebSphere MQ format) or by the values set in the MQRFH or MQRFH2 header: The format of the first header is known, because this must be MQMD.

Contd
The format of any subsequent header in the message is set in the Format field in the preceding header. The format of the body corresponds to the message domain and the parser that must be invoked for the message body (for example, XML). This information is set either in the MQRFH or MQRFH2 header, or in the message domain property of the input node that receives the message.

Contd
The original value in that field is stored in the Domain field within the MQRFH or MQRFH2 header to retain the information about the contents of the message body. If there is no MQRFH or MQRFH2, the information is stored in the Properties tree. For example, if the MQRFH2 header immediately precedes the message body and its Format field is set to XML, indicating that the message body must be parsed by the generic XML parser, the MQRFH2 Domain field is set to XML, and its Format field reset to MQFMT_NONE.

Contd
If the message has an MQRFH or MQRFH2 header, the domain that is identified in the header (either in Format or the name/value data) determines the parser that is associated with this message. If the message does not have an MQRFH or MQRFH2 header, or the header does not identify the domain, but the properties of the input node, stored in the Properties tree, indicate the domain of the message, the parser specified by the input node property is used. You can specify a user-defined parser.

Contd
If the message domain cannot be identified by header values or by properties of the input node, the message is handled as a binary object (BLOB). The BLOB parser is associated with the message. A BLOB can be interpreted as a string of hexadecimal characters, and can be modified or examined in the message flow by specifying the location of the subset of the string.

Contd
The message body is not parsed for performance reasons; it is possible that the configuration of the message flow does not require the message body to be parsed. The body is parsed only when a reference is made to its contents during the message flow.

Tree contents after an exception:

The contents of the message tree are updated if an exception is raised. If no exception occurs while processing the message, the tree structure and content received by an individual node is determined by the action of previous nodes in the flow. If an exception occurs in the message flow, the content of the four trees depends on the following factors:

Contd
1. If the exception is returned to the input node, and the input node catch terminal is not connected, the trees are discarded. If the message is within a transaction, it is returned to the input queue for further processing. When the message is processed again, a new tree structure is created. If the message is not within a transaction, it is discarded.

Contd
2. If the exception is returned to the input node and the catch terminal is connected, the Message and LocalEnvironment trees that were created originally by the input node, and propagated through the out terminal, are restored, and any updates that you made to their content in the nodes that followed the input node are lost.

Contd
The Environment tree is not restored, and its contents are preserved. If the nodes following the input node include a Compute node that creates a new LocalEnvironment or Message tree, those trees are lost. The ExceptionList tree reflects the one or more exceptions that have been recorded.

Contd
3. If the exception is caught within the message flow by a TryCatch node, the Message and LocalEnvironment trees that were previously propagated through the try terminal of the TryCatch node are restored and propagated through the catch terminal. Any updates that you made to their content in the nodes that followed the TryCatch node are lost.

Logical tree structure

The logical tree structure is the internal (broker) representation of a message. When a message arrives at a broker, it is received by an input node that you have configured in a message flow. Before the message can be processed by the message flow, it must be interpreted by one or more parsers that create a logical tree representation from the bit stream of the message data.

Contd
The tree format contains identical content to the bit stream from which it is created, but it is easier to manipulate within the message flow. Many of the built-in message flow nodes provide an interface for you to query and update message content within the tree, and perform other actions against messages and databases to help you to provide the required function in each node.

Contd
Three interfaces are provided: ESQL, a programming language that you can code in the Compute, Database, and Filter nodes. Java, a programming language that you can code in the JavaCompute node.

Contd
Mappings, a method of achieving transformation from input to output structures, available in the DataDelete, DataInsert, DataUpdate, Extract, Mapping, and Warehouse nodes. The tree structure created by the parsers is largely independent of any message format (for example, XML). The exception to this is the subtree that is created as part of the message tree and that represents the message body. This subtree is message dependent, and its content is not further described.

Contd
The input node creates the logical tree, which consists of four subtrees: Message Tree Environment Tree LocalEnvironment Tree ExceptionList Tree The first of these trees is populated with the contents of the input message bit stream. the remaining three are initially empty. Each of the four trees created has a root element. The root element has no parent.

Message tree:
The message tree is a part of the logical message tree in which the broker stores its internal representation of the message body. The root of a message tree is called Root. The message tree is always present, and is passed from node to node within a single instance of a message flow. The message tree includes all the headers that are present in the message, in addition to the message body

Contd
If the message has been received across the WebSphere MQ Enterprise Transport, WebSphere MQ Mobile Transport, or WebSphere MQ Telemetry Transport, the first header (the second element) must be the MQMD. Any additional headers included in the message appear in the tree in the same order as in the message. The last element beneath the root of the message tree is always the message body.

Contd
The message tree structure is shown below. If the input message is not a WebSphere MQ message, the headers shown might not be present. If the parser that created this tree is a user-defined parser, the Properties tree might not be present.
Root

Properties

MQMD

Other header

Body

Element1/ Format1

Element2/ Field2

Element 3/ Field3

Contd
The Body tree, a structure of child elements (described below) that is determined by the parser, represents the message content (data). The message body might be: MRM, if you have modeled the message. XML, if the message is self-defining. A value that identifies a user-defined parser.

Properties parser:
The properties folder is the first element of the message tree and holds information about the characteristics of the message. The root of the properties folder is called Properties. It is the first element under Root. All message trees generated by the built-in parsers include a properties folder for the message.

Contd
If you create your own user-defined parser, you can choose whether the parser creates a properties folder. However, for consistency, you are recommended to include this action in the user-defined parser. For example, the MQRFH2 header contains information about the message set, type, and format. These values are stored in the properties folder as MessageSet, MessageType, and MessageFormat.

Contd
When the message flow processing is complete, the properties folder is discarded.

Environment tree:
The Environment tree is a part of the logical message tree in which you can store information while the message passes through the message flow. The root of the Environment tree is called Environment. This tree is always present in the input message; an empty Environment tree is created when a message is received and parsed by the input node. You can use this tree as you choose, and create both its content and structure.

Contd
The Environment tree differs from the LocalEnvironment tree in that a single instance of it is maintained throughout the message flow. If you include a Compute node in your message flow, you do not have to specify whether you want the Environment tree to be included in the output message. This happens automatically, and the entire contents of the input Environment tree are retained in the output Environment tree, subject to any modifications that you make using ESQL in the node.

Contd
Any changes that you make are available to subsequent nodes in the message flow, and to previous nodes if the message flows back (for example, to a FlowOrder or TryCatch node). You are recommended to create information in the Environment tree within a subtree called Variables (although this is not enforced).

Contd
There is one situation in which WebSphere Message Broker refers to (but never creates) a field in this tree. If you have requested data collection for message flow accounting and statistics, and have indicated that accounting origin basic support is required, the broker checks for the existence of the field Environment.Broker.AccountingOrigin. If the field exists, the broker uses its value to set the accounting origin for the current data record.

Contd

Evnironment

Variables

Bread

Wine

Cheese

Colors

Country

Name

Currency

LocalEnvironment tree:
The LocalEnvironment tree is a part of the logical message tree in which you can store information while the message flow processes the message. The root of the LocalEnvironment tree is called LocalEnvironment. This tree is always present in the input message: an empty LocalEnvironment tree is created when a message is received by the input node.

Contd
Use the LocalEnvironment tree to store variables that can be referred to and updated by message processing nodes that occur later in the message flow. You can also use the LocalEnvironment tree to define destinations (that are internal and external to the message flow) to which a message is sent..

Contd
WebSphere Message Broker also stores information in LocalEnvironment in some circumstances, and references it to access values that you might have set for destinations.(Contrast this to the Environment tree). The figure below shows the LocalEnvironment tree structure. The children of Destination are protocol-dependent.

Contd
If the message is parsed by another built-in parser, or by a user-defined parser, the tree structure below the Destination element has different content than that shown in the figure.
LocalEvnironment

Variables

Destination

WrittenDestin ation

MQ

MQDestinatio nList

RouterList

Defaults

DestinationD ata

Defaults

DestinationD ata

DestinationD ata

Contd
Variables

This subtree is optional. If you create local environment variables, you are recommended to store them in a subtree called Variables. It provides a work area that you can use to pass information between nodes. This subtree is never inspected or modified by any supplied node.

Contd
Variables in the local environment can be changed by any subsequent message processing node, and persist until the message flow goes out of scope and the node that created it has completed its work and returns control to the previous node.

Contd
The variables in this subtree are only persistent within a single instance of a message flow. If you have multiple instances of a message passing through the message flow, and need to pass information between them, you must use an external database.

Contd
Destination

This subtree consists of a number of children that indicate the transport types to which the message is directed (the Transport identifiers), or the target Label nodes that are used by a RouteToLabel node.

Contd
Transport information. Transport information is used by some input and output nodes. If the message flow includes an MQOutput node, each element is a single name element, MQDestinationList. If more than one element exists, each is processed sequentially by the node.

Contd
Routing information The child of Destination is RouterList. It has a single child element called DestinationData, which has a single entry called labelName. If you are using a dynamic routing scenario involving the RouteToLabel and Label nodes, you must set up the Destination subtree with a RouterList that contains the reference labels.

WrittenDestination
This subtree contains the addresses to which the message has been written. Its name is fixed. It is created by the message flow when a message is propagated through the out terminal of an output node. It includes transport specific information (for example, if the output message has been put to a WebSphere MQ queue, it includes the queue manager and queue names).

Contd
If the out terminal of the output node is not connected to another node, this subtree is not created. The topic for each output node contains more information about the contents of WrittenDestination for WebSphere MQ and WebSphere MQ Everyplace.

ExceptionList tree:
The ExceptionList tree is a part of the logical message tree in which the message flow writes information about exceptions that occur when a message is processed. The root of the ExceptionList tree is called ExceptionList, and the tree consists of a set of zero or more exception descriptions.

Contd
The ExceptionList tree is populated by the message flow if an exception occurs. If no exception conditions occur during message flow processing, the exception list associated with that message consists of a root element only.

Contd
This is, in effect, an empty list of exceptions. The ExceptionList tree can be accessed by other nodes within the message flow that receive the message after the exception has occurred. You can modify its contents only in the Compute node. If an exception condition occurs, message processing is suspended and an exception is thrown.

Contd
Control is passed back to a higher level, that is, an enclosing catch block. An ExceptionList is built to describe the failure condition, and the whole message, together with the LocalEnvironment and the newly-populated ExceptionList, is propagated through an exception handling message flow path.

Contd
The child of the ExceptionList is always RecoverableException. There is normally only one child of the root, although more than one might be generated in some circumstances. The child of the ExceptionList contains a number of children, the last of which provides further information specific to the type of exception, which can be one of:

Contd
RecoverableException ParserException ConversionException UserException DatabaseException

Correlation names in nodes that create an output message:

If you are coding ESQL for a Compute node, the correlation names are different because there are two message trees involved: the input message and the output message. The correlation names in ESQL within these nodes are: Environment The structure that contains the current global environment variables available to the node. Environment can be read and updated. InputRoot The root of the input message.

Contd
InputBody The last child of the root of the input message. This is an alias for InputRoot.*[<]. InputProperties The standard properties of the input message.

Contd
InputDestinationList The structure that contains the local environment variables for the message passing through the node. Use the correlation name InputDestinationList for backward compatibility; if compatibility is not required, use the preferred name InputLocalEnvironment.

Contd
InputExceptionList The structure that contains the exception list for the message passing through the node. InputLocalEnvironment The structure that contains the local environment variables for the message passing through the node.

Contd
OutputRoot The root of the output message. In a Compute node, there is no correlation name OutputBody OutputDestinationList The structure that contains the local environment variables being sent out from the node. Use the correlation name OutputDestinationList for backward compatibility; if compatibility is not required, use the preferred name OutputLocalEnvironment

Contd
OutputExceptionList The structure containing the exception list that the node is generating. While this correlation name is always valid, it has meaning only when the Compute Mode property of the Compute node indicates that the Compute node is propagating the ExceptionList. OutputLocalEnvironment The structure that contains the local environment variables being sent out from the node.

Parsers
A parser is a program that interprets the bit stream of an incoming message and creates an internal representation of the message in a tree structure. It also regenerates a bit stream for an outgoing message from the internal message tree representation. A parser is invoked when the bit stream that represents an input message is converted to the internal form that can be handled by the broker.

Contd
The way in which the parser interprets the bit stream is unique to that parser, so the logical message tree that is created from the bit stream varies from parser to parser. A parser might also create a bit stream from a tree structure if a node in the message flow invokes the ESQL ASBITSTREAM function.

MRM parser and domain

The MRM message domain includes all messages that are modeled in the workbench. You can create message models to represent a wide range of message types, with one or more optional physical formats. Messages in this domain are processed by the MRM parser. The MRM parser is a program that interprets a bit stream or tree that represents a message that belongs to the MRM domain, and generates the corresponding tree from the bit stream on input, or bit stream from the tree on output.

Contd
Its interpretation depends on the physical format that you have associated with the input or output message: For CWF, the parser reads a set sequence of bytes and translates these into the fields and values in the message tree.

Contd
For TDS, the parser uses the Data Element Separation method to parse the bit stream. Depending on the values that you have set for the TDS physical format properties, this might involve identifying delimiters, tags, fixed length elements, patterns, and so on. For XML, the parser identifies the XML markup language (tags and attributes) and creates the correct objects, modified by the values that you have set for the XML physical format properties.

Contd
In the MRM domain, the message is considered in two parts:
1. The

logical message model. This is the piece of the message that conveys the business data, devoid of its physical representation (how it appears in a bit stream on the wire). It is independent of platform and the way in which the message is constructed. For example, if you define a message that conveys information about a debit of an individuals bank account, it can be represented in different physical forms on the wire (in XML, or a fixed structure such as a COBOL copybook).

Contd
The business meaning and data is the same in both cases: only the physical layout has changed. 2. The physical representation. This is how the data is physically laid out on the wire. A single logical message model might have several different ways in which it can be physically represented.

Message Modeling

 Much of the business world relies on the exchange of information between applications. The information is contained in messages having a defined structure which is known and agreed by the sender and the receiver. You will probably find that your applications use a combination of messages, including those defined by: C and COBOL data structures. industry standards such as SWIFT or EDIFACT. XML DTD or schema.

Contd
You can model a wide variety of message formats which can be understood by WebSphere Message Broker message flows. Once the message format is known, the broker can parse an incoming message bit stream and convert it into a logical message tree for manipulation by a message flow. After the message has been processed by the message flow, the broker converts the message tree back into a message bit stream.

Message modeling concepts

Message modeling is a way of predefining the message formats used by your applications. Once you have modeled your messages, products like WebSphere Message Broker can use your message models to automatically parse and write your message formats. When you model messages you need to understand the following concepts:

Contd
Message set projects Message sets Message definition files Message categories Domains and parsers

Why model messages?

A product such as WebSphere Message Broker typically supplies a range of parsers to parse and write message formats. Some message formats are self-defining and can be parsed without reference to a model. An example of a self-defining message format is XML. In XML the message itself contains metadata as well as data values, enabling an XML parser to understand an XML message even if no model is available. Most message formats, however, are not self-defining.

Contd
As examples, a binary message originating from a COBOL program and a SWIFT formatted text message do not contain sufficient metadata to enable a parser to understand the message. The parser must have access to a model that describes the message to parse it correctly.

Which message domain and format to use?

Each message set you create specifies a domain, which determines the parser that is used when parsing and writing all messages defined within that message set. Each domain is suited to a particular class of messages (fixed-length binary, delimited text, XML and so on). Additionally, some domains support several physical formats (sometimes called wire formats).

Contd
When you create a message set you need to decide which domain and physical format to use. You can select one of the following domains: MRM For modeling a wide range of messages including XML, fixed-format binary and formatted text. XML, XMLNS or XMLNSC For messages conforming to the W3C XML standard.

Contd
JMSMap or JMSStream For messages produced by the WebSphere MQ implementation of the Java Messaging Service standard. IDOC For messages in SAP IDoc format. MIME For handling multipart MIME messages such as SOAP with Attachments or RosettaNet.

The message model

The message model consists of the following components: Message set projects Message sets Message definition files Message categories

Message set projects

A message set project is a specialized container in which you create and maintain all the resources associated with one message set. The content of a message set project is a single message set folder, the name of which provides the name of the message set.

Message sets
A message set is a container for grouping messages and associated message resources (elements, types, groups). A message set is a folder in a message set project that contains a messageSet.mset file. The name of the folder is the name of the message set. A message set project can contain just one message set.

Contd
Runtime Parser The message domain of the message set. This is used when parsing and writing all messages defined within that message set and effectively defines the message domain. Use Namespaces Indicates whether the message definitions you create within the message set are XML namespace aware.

Contd
Message set resources: Resources within a message set are created as files, and are displayed under the message set folder in the Navigator view: Message set file messageSet.mset There is always one, and only one, messageSet.mset file in a message set. It contains message model properties that are common to all the content of the message set.

Contd
It is also where you define the physical formats that you want for this message set. These can be Custom Wire Format (CWF), XML Wire Format (XML) and Tagged Delimited String Format (TDS). The file is created for you when a new message set is created, and you manipulate its content with the Message Set Editor.

Message definition files that have the suffix .mxsd.

Contd
You can have many message definition files in a message set. Each file contains the logical model and associated physical model in XML Schema form for a group of related messages. Message category files that have the suffix .category These files are optional. You can have many message category files in a message set.

Contd
A message category provides another way of grouping your messages, perhaps for documentation purposes or to assist with generating Web Services Description Language (WSDL) files. Message set identification: As well as having a name, provided by the folder, and a message set alias, a message set also has an identifier.

Contd
This is a generated string of 13 characters that uniquely identifies the message set. You can use either the name, the alias, or the identifier interchangeably whenever you need to specify the message set to a runtime product such as WebSphere Message Broker (for example, in an MQRFH2 message header).

Contd
Message set version and keywords: When you are developing a message set, you can define the version of the message set as well as any other key information that you need to be associated to it. After the message set has been deployed, the Configuration Manager can be used to display the properties of the message set.

Contd
This includes the deployment and modification dates and times (the default information that is displayed) as well as any additional version or keyword information that you have set. $MQSI Author=John Smith MQSI$ $MQSI Subflow 1 Version=v1.3.2 MQSI$.

Message definition files

A message definition file contains the messages, elements, types and groups which make up a message set. Every message set requires at least one message definition file to describe its messages. Message definition files use the XML Schema language to describe the logical format of one or more messages.

Contd
Extra information in the form of XML Schema annotations is used to describe any physical formats which you define for the messages.

XML Schema:
XML Schema is an international standard which defines a language for describing the structure of XML documents. The XML Schema language is ideally suited to describing the messages which flow between business applications, and it is widely used in the business community for this purpose. WebSphere Message Broker uses XML Schema to describe the logical structure of messages.

Contd
At a simple level, the types and elements in the message are modeled using XML Schema types and elements. However, when the need arises, most of the advanced modeling features of XML Schema are available for modeling MRM messages.

Messages
A message is a global element representing an entire message (rather than a structure within a message). Within a message definition file, a message is represented by a special global element which carries the extra information required by WebSphere Message Broker.

Composition
The message model adds the following compositions which are beyond the XML Schema specification. These extra compositions allow message models produced in earlier versions of the product to be supported.

Contd
OrderedSet A set of elements which must appear in the order in which they are listed. Groups are not allowed within an orderedSet. Elements can repeat, but duplicate element references are not allowed. UnorderedSet A set of elements which can appear in any order. Groups are not allowed within an unorderedSet.

Contd
Unlike an all group, elements within an orderedSet are allowed to repeat. However, duplicate element references are not allowed.

Contd
message A refinement of choice which is only allowed to contain a set of references to messages within the same message set. Groups and complex types with composition of message are used when modeling multipart messages. Physical format information: If one or more physical formats are defined for a message set, the XML Schema objects within the message set can hold extra information about how they should be serialized.

Message model objects:

Message A message is a set of data passed between applications. Messages must have a structure and format which is agreed by the sending and receiving applications. Message definition A message definition is a logical description of a message. A message definition is a collection of simple elements organized in a tree-like structure.

Contd
Simple element A simple element describes one or more fields in a message. It is based on a simple type (for example, string, integer or float). It can repeat, and it can define a default or a fixed value.

Contd
Simple type A simple type describes a class of data within a message. It describes the type of data (for example, string, integer or float) and it can have value constraints which place limits on the values of any simple elements based on that simple type. Complex element A complex element is a named structure containing simple elements within the message. Complex elements can contain other complex elements, and can also contain groups.

Contd
The content of a complex element is defined by a complex type. Complex type A complex type describes a structure within a message. It contains elements, attributes and groups organised into a hierarchy. Group A group is a list of elements with information about how those elements can appear in a message. Groups can be ordered (sequence) unordered (all) or selective (choice).

Contd
Attribute An attribute represents an XML Schema attribute. Attributes are very similar to simple elements, but they require special treatment when used with XML messages. In messages which are not XML, they are treated exactly like a simple element based on the same simple type.

ESQL overview

 Extended Structured Query Language (ESQL) is a programming language defined by WebSphere Message Broker to define and manipulate data within a message flow. This section contains introductory information about ESQL. ESQL is based on Structured Query Language (SQL) which is in common usage with relational databases such as DB2. ESQL extends the constructs of the SQL language to provide support for you to work with message and database content to define the behavior of nodes in a message flow.

The ESQL code that you create to customize nodes within a message flow is defined in an ESQL file, typically named <message_flow_name>.esql, which is associated with the message flow project. You can also use ESQL to create functions and procedures that you can use in some built-in nodes, like Compute, Databse and Filter nodes.

To use ESQL correctly and efficiently in your message flows, you must also understand the following concepts:
1. Data types 2 Variables 3 Field references 4 Operators

5 Statements 6 Functions 7 Procedures 8 Modules

ESQL data types

A data type defines the characteristics of an item of data, and determines how that data is processed. ESQL supports six data types, listed below. Data that is retrieved from databases, received in a self-defining message, or defined in a message model (using MRM data types), is mapped to one of these basic ESQL types when it is processed in ESQL expressions.

Contd
ESQL defines the following categories of data. Each category contains one or more data types. Boolean Datetime Null Numeric Reference String

ESQL variables
An ESQL variable is a data field used to help process a message. You must declare a variable and state its type before you can use it. A variables data type is fixed; if you code ESQL that assigns a value of a different type, either an implicit cast to the data type of the target is implemented or an exception is raised (if the implicit cast is not supported). To define a variable and give it a name, use the DECLARE statement.

Contd
Note: The names of ESQL variables are case sensitive, so it is important to make sure that you use the correct case in all places. The simplest way to guarantee this is always to define variables using upper case names.

Variable scope, lifetime, and sharing

How widespread and for how long a particular ESQL variable is available, is described by its scope, lifetime, and sharing: A variables scope is a measure of the range over which it is visible. In the broker environment, the scope of variables is normally limited to the individual node.

Contd
A variables lifetime is a measure of the time for which it retains its value. In the broker environment, the lifetime of a variable varies but is typically restricted to the life of a thread within a node.

Contd
A variables sharing characteristics indicate whether each thread has its own copy of the variable or whether one variable is shared between many threads. In the broker environment, variables are typically not shared.

Types of variable
You can use the DECLARE statement to define a variable in your ESQL code. The following are three different types of variable. External External variables (defined with the EXTERNAL keyword) are also known as user-defined properties. They exist for the entire lifetime of a message flow and are visible to all messages passing through the flow.

Contd
Their initial values (optionally set by the DECLARE statement) can be modified, at design time, by the Message Flow editor, or, at deployment time, by the BAR editor. Their values cannot be modified by ESQL.

Contd
Normal Normal variables have a lifetime of just one message passing through a node. They are visible to that message only. To define a normal variable, omit both the EXTERNAL and SHARED keywords.

Contd
Shared Shared variables (defined with the SHARED keyword) are long-lived. They are re-initialized only when a message flow is modified or restarted and are visible to all messages passing through the flow. Their values can be modified by ESQL.

Contd
User-defined properties A user-defined property (UDP) is a user-defined constant whose initial value can be modified, at design time, by the Message Flow editor, or overridden, at deployment time, by the Broker Archive editor. You can use UDPs in your ESQL or Java programs. In ESQL, you use the DECLARE statement to define a UDP to your program.

Contd
You can give the UDP an initial value on the DECLARE statement, but your code cannot modify the value at run-time. When a UDP is given an initial value on the DECLARE statement this becomes its default. However, any value specified by the Message Flow editor at design time, or by the BAR editor at deployment time (even a zero length string) overrides any initial value coded on the DECLARE statement.

Contd
All UDPs in a message flow must have a value, given either on the DECLARE statement or by the Message Flow or BAR editor; otherwise a deployment-time error occurs. At run time, after the UDP has been declared its value can be queried by subsequent ESQL statements but not modified.

Long-lived variables
It is sometimes desirable to store data for longer than the lifetime of a single message passing through a flow. One way to do this, is to store the data in a database. This is good for long-term persistence and transactionality, but access (particularly write access) is slow. Alternatively, you can use appropriate long-lived ESQL data types to cache data for a certain period of time.

Contd
This makes access much faster than it would be from a database, though this is at the expense of shorter persistence and no transactionality. Long-lifetime variables are created by using the SHARED keyword on the DECLARE statement. Long-lived data types have an extended lifetime beyond that of a single message passing through a node.

Contd
They are shared between threads and exist for the life of a message flow (strictly speaking the time between configuration changes to a message flow).

ESQL field references

An ESQL field reference is a sequence of period-separated values that identify a specific field (which might be a structure) within a message tree or a database table. The path from the root of the information to the specific field is traced using the parent/child relationships.

Contd
A field reference is used in an ESQL statement to identify the field that is to be referenced, updated, or created within the message or database table. For example, you might use the following identifier as a message field reference: You can use an ESQL variable of type REFERENCE to set up a dynamic pointer to contain a field reference.

Contd
This might be useful in creating a fixed reference to a commonly-referenced point within a message; for example the start of a particular structure that contains repeating fields. A field reference can also specify element types, XML namespace identifications, indexes and a type constraint. These are discussed in detail later. The first name in a field reference is sometimes known as a Correlation name.

ESQL operators
An ESQL operator is a character or symbol that you can use in expressions to specify relationships between fields or values. ESQL supports the following groups of operators: Comparison operators To compare one value to another value (for example, less than). Logical operators To perform logical operations on one or two terms (for example, AND).

Contd
Numeric operators To indicate operations on numeric data (for example, +). There are some restrictions on the application of some operators to data types; not all lead to a meaningful operation. These are documented where they apply to each operator.

ESQL statements
An ESQL statement is an instruction that represents a step in a sequence of actions or a set of declarations. ESQL provides a large number of different statements that perform different types of operation. All ESQL statements start with a keyword that identifies the type of statement and end with a semicolon. An ESQL program consists of a number of statements that are processed in the order they are written.

Contd
As an example, consider the following ESQL program: DECLARE X INTEGER; SET X = 42; This program consists of two statements. The first starts with the keyword DECLARE and ends at the first semicolon.

Contd
The second statement starts with the keyword SET and ends at the second semicolon. These two statements are written on separate lines and it is conventional (but not required) that they be so. You will notice that the language keywords are written in capital letters. This is also the convention but is not required; mixed and lower case is acceptable.

Contd
The first statement declares a variable called x of type INTEGER, that is, it reserves a space in the computers memory large enough to hold an integer value and allows this space to be subsequently referred to in the program by the name x. The second statement sets the value of the variable x to 42. A number appearing in an ESQL program without decimal point and not within quotes is known as an integer literal.

Contd
ESQL nested statements An ESQL nested statement is a statement that is contained within another statement. Consider the following ESQL program fragment: IF Size > 100.00 THEN SET X = 0; SET Y = 0; SET REVERSE = FALSE; ELSE SET X = 639; SET Y = 479; SET REVERSE = TRUE; END IF;

ESQL functions
A function is an ESQL construct that calculates a value from a number of given input values. A function usually has input parameters and can, but does not usually have, output parameters. It returns a value calculated by the algorithm described by its statement. This statement is usually a compound statement, such as BEGIN... END, because this allows an unlimited number of nested statements to be used to implement the algorithm.

Contd
ESQL provides a number of predefined, or built-in, functions which you can use freely within expressions. You can also use the CREATE FUNCTION statement to define your own functions

ESQL procedures
An procedure is a subroutine that has no return value. It can accept input parameters from, and return output parameters to, the caller. Procedures are very similar to functions. The main difference between them is that, unlike functions, procedures have no return value. Thus they cannot form part of an expression and are invoked by using the CALL statement. Procedures commonly have output parameters.

Contd
You can implement a procedure in ESQL (an internal procedure) or as a database stored procedure (an external procedure). The ESQL procedure must be a single ESQL statement, although that statement can be a compound statement such as BEGIN END.

ESQL modules
A module is a sequence of declarations that define variables and their initialization, and a sequence of subroutine (function and procedure) declarations that define a specific behavior for a message flow node. A module must begin with the CREATE node_type MODULE statement and end with an END MODULE statement. The node_type must be one of COMPUTE, DATABASE, or FILTER.

Contd
The entry point of the ESQL code is the function named MAIN, which has MODULE scope. Each module is identified by a name which follows CREATE node_type MODULE. The name might be created for you with a default value, which you can modify, or you can create it yourself.

Creating ESQL for a node

The name is handled in a case insensitive way (that is, use of the name with any combination of upper and lower case letters matches the declaration). That is in contrast to the names that you declare for schemas, constants, variables, and labels, which are handled in a case sensitive way, and which you must specify exactly as you declared them.

Contd
You can also create local constants and variables. If you have created constants, functions, or procedures at the broker schema level, you can also refer to these within the module. You can define routines at a level at which many different modules can use them, which can save you development time and maintenance effort. To create ESQL for a node:

Contd
Create ESQL to customize the behavior of a Compute, Database, or Filter node within an ESQL file. Before you start To complete this task, you must have completed the following task: A module can be associated with only one node of a particular type (Compute, Database, or Filter). Within the module you can create and use functions and procedures as well as the supplied statements and functions.

Contd
1. Switch to the Broker Application Development perspective. 2. In the Navigator view, double-click the message flow that includes the node for which you want to create ESQL. The message flow opens in the editor view. 3. Right-click the node (which must be Compute, Database, or Filter) and click Open ESQL. The default ESQL file for this message flow, <message_flow_name>.esql, is opened in the editor view (the file is created if it does not already exist).

Contd
If you have already created the default file and you click Open ESQL, the file is opened in the editor view and a new module is created and highlighted. A skeleton module is created for this node at the end of the ESQL file. Its exact content depends on the type of node. The following module is created for a Compute node:

Contd
CREATE COMPUTE MODULE <module_name> CREATE FUNCTION Main() RETURNS BOOLEAN BEGIN -- CALL CopyMessageHeaders(); -- CALL CopyEntireMessage(); RETURN TRUE; END; CREATE PROCEDURE CopyMessageHeaders() BEGIN DECLARE I INTEGER 1; DECLARE J INTEGER CARDINALITY(InputRoot.*[]); WHILE I < J DO SET OutputRoot.*[I] = InputRoot.*[I]; SET I = I + 1; END WHILE; END; CREATE PROCEDURE CopyEntireMessage() BEGIN SET OutputRoot = InputRoot; END; END MODULE;

Contd
The module name is determined by the value that you have set for the corresponding node property. The default is <message_flow_name>_<node_type>. The Main function contains calls to two procedures, described below, that are declared within the Compute node module following the function Main. These calls are commented out. If you want to include the function that they provide, uncomment these lines and place them at the appropriate point in the ESQL that you create for Main.

Contd
CopyMessageHeaders This procedure loops through the headers contained in the input message and copies each one to the output message. If you are migrating from Version 2.1, this procedure is equivalent to the code generated when you select the Copy message headers button on the Compute node properties dialog.

Contd
CopyEntireMessage This procedure copies the entire contents of the input message, including the headers, to the output message. If you are migrating from Version 2.1, this procedure is equivalent to the code generated when you select the Copy entire message button on the Compute node properties dialog.

Contd
Adding comments to ESQL You can add comments to and remove comments from your ESQL code: 1. To change an existing line of code into a comment line, click Source Comment. 2. To change a comment line to a code line, click Source Uncomment. 3. To create a new comment line, press Enter to create a new line and either type the comment identifier -- or click Source Comment. You can enter any text after the identifier: everything you type is ignored by the ESQL editor.

Contd
ESQL TIME data type The TIME data type holds a time of day in hours, minutes, seconds, and fractions of a second. The format of a TIME literal is the word TIME followed by a space, followed by a time in single quotation marks in the form hh:mm:ss.ffffff. For example: DECLARE MyTime TIME; SET MyTime = TIME 11:49:23.656; Each of the hour, minute, and second fields in a TIME literal must always be two digits; the optional fractional seconds field can be up to 6 digits in length.

Contd
ESQL GMTTIME data type The GMTTIME data type is similar to the TIME data type, except that its values are interpreted as values in Greenwich Mean Time. GMTTIME literals are defined in a similar way to TIME values. For example: DECLARE MyGetGmttime GMTTIME; SET MyGetGmttime = GMTTIME 12:00:00;

Contd
ESQL TIMESTAMP data type The TIMESTAMP data type holds a DATE and a TIME in years, months, days, hours, minutes, seconds, and fractions of a second. The format of a TIMESTAMP literal is the word TIMESTAMP followed by a space, followed by a timestamp in single quotation marks in the form yyyy-mm-dd hh:mm:ss.ffffff.

Contd
For example: DECLARE MyTimeStamp TIMESTAMP; SET MyTimeStamp = TIMESTAMP 1999-12-31 23:59:59; The year field must always be four digits in length. The month, day, hour, and minute fields must always be two digits. (Do not omit leading zeroes.) The optional fractional seconds field can be 0 - 6 digits long.

Contd
ESQL GMTTIMESTAMP data type The GMTTIMESTAMP data type is similar to the TIMESTAMP data type, except that the values are interpreted as values in Greenwich Mean Time. GMTTIMESTAMP values are defined in a similar way to TIMESTAMP values, for example: DECLARE MyGetGMTTimeStamp GMTTIMESTAMP; SET MyGetGMTTimeStamp = GMTTIMESTAMP 1999-12-31 23:59:59.999999;