ESQL入门指南：WebSphereMessageBroker V6开发核心技术

5星 · 超过95%的资源需积分: 9 97 浏览量更新于2024-07-27 收藏 3.52MB PDF 举报

本文档是关于IBM WebSphere Message Broker (WMB) 中使用的ESQL技术的详细介绍，适用于WebSphere Message Broker Version 6 Release 0，旨在帮助开发人员入门并深入理解这一技术。ESQL全称为Enterprise Service Query Language，它是一种强大的查询语言，用于在消息队列和企业服务总线（ESB）环境中进行高效的数据处理和操作。在Part 1 "Developing ESQL" 部分，内容涵盖了以下几个关键主题： 1. **ESQL概述**：这部分会介绍ESQL的基本概念、设计目的和在WMB中的应用，帮助读者了解其在消息处理流程中的核心作用以及与传统SQL的不同之处。 2. **管理ESQL文件**：讲解如何创建、组织和管理ESQL脚本，包括命名规范、文件结构以及版本控制等，确保代码的整洁和可维护性。 3. **编写ESQL**：详述了ESQL的语法、关键字、表达式、条件语句和循环结构等，使读者能够编写出功能丰富的查询和操作指令。 Part 2 "Reference" 提供了深入的技术参考，包括： - **语法图表：可用类型** - 显示了ESQL支持的各种数据类型和操作符的图形化表示，便于理解和记忆。 - **ESQL数据类型在消息流中的应用** - 讲解了不同类型的数据如何在消息传递过程中被处理，以及它们如何映射到WMB的消息模型。 - **ESQL变量**：定义了变量的作用域、生命周期和不同类型的变量声明方法，这对于动态数据处理至关重要。 - **ESQL字段引用**：解释了如何通过字段名或索引访问消息中的数据，以及如何在复杂的查询中组合和引用这些字段。阅读这份文档，开发者可以快速掌握ESQL在WebSphere Message Broker中的应用技巧，无论是初次接触还是想要提升现有技能，都能从中获益匪浅。同时，由于这是第三版，更新至2006年，所以还可能包含了对后续版本兼容性和新特性的说明，对于跟踪技术演进和持续学习的开发者来说是宝贵的资源。

Long lifetime variables

Flow Shared Flow Life of flow All threads of flow

Features of long-lived ESQL data types include:

v Ability to handle large amounts of long-lifetime data.

v Joining data to messages is fast.

v On multiple processor machines, multiple threads are able to access the same

data simultaneously.

v Subsequent messages can access the data left by a previous message.

v Long lifetime read-write data can be shared between threads, because there is no

long term association between threads and messages.

v In contrast to data stored in database tables in the “environment”, this sort of

data is stored “privately”; that is, within the broker.

v The use of ROW variables can be used to create a modifiable copy of the input

message.

v It is possible to create shared constants.

typical use of these data types might be in a flow in which data tables are

’read-only’ as far as the flow is concerned. Although the table data is not actually

static, the flow does not change it, and thousands of messages pass through the

flow before there is any change to the table data.

An example is a table which contains a day’s credit card transactions. The table is

created each day and that day’s messages will be run against it. Then the flow is

stopped, the table updated and the next day’s messages run. It is very likely that

such flows would perform better if they cached the table data rather than read it

from a database for each message.

Another use of these data types might be the accumulation and integration of data

from multiple messages.

Broker properties

For each broker, WebSphere Message Broker maintains a set of properties. You can

access some of these properties from your ESQL programs. A subset of the

properties is also accessible from Java code. It can be useful, during the runtime of

your code, to have real-time access to details of a specific node, flow, or broker.

There are four categories of broker properties:

v Those relating to a specific node

v Those relating to nodes in general

v Those relating to a message flow

v Those relating to the execution group

“Broker

properties accessible from ESQL and Java” on page 351 shows the broker,

flow, and node properties that are accessible from ESQL and indicates which

properties are also accessible from Java.

Broker properties:

v Are grouped by broker, execution group, flow, and node.

v Are case sensitive. Their names always start with an uppercase letter.

8 ESQL

v Return NULL if they do not contain a value.

All

nodes that allow user programs to edit ESQL support access to broker

properties. These are:

v Compute nodes

v Database nodes

v Filter nodes

v All derivatives of these nodes

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.

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. 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:

v Comparison operators, to compare one value to another value (for example, less

than). Refer to “ESQL simple comparison operators” on page 166 for details of

the supported operators and their use.

v Logical operators, to perform logical operations on one or two terms (for

example, AND). Refer to “ESQL logical operators” on page 170 for details of the

supported operators and their use.

v Numeric operators, to indicate operations on numeric data (for example, +).

Refer to “ESQL numeric operators” on page 171 for details of the supported

operators and their use.

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.

Operators that return a boolean value (TRUE or FALSE), for example the greater

than operator, are also known as predicates.

Body.Invoice.Payment

Developing ESQL 9

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.

As an example, consider the following ESQL program:

This program consists of two statements. The first starts with the keyword

DECLARE and ends at the first semicolon. 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 are acceptable.

The first statement declares a variable called x of type INTEGER, that is, it reserves

a space in the computer’s 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.

ESQL has a number of data types and each has its own way of writing literal

values. These are described in “ESQL data types” on page 4.

For a full description of all the ESQL statements, see “ESQL statements” on page

172.

ESQL nested statements

An ESQL nested statement is a statement that is contained within another

statement.

Consider the following ESQL program fragment:

In this example, you can see a single IF statement containing the optional ELSE

clause. Both the IF and ELSE portions contain three nested statements. Those

within the IF clause are executed if the operator > (greater than) returns the value

TRUE (that is, if Size has a value greater than 100.00); otherwise, those within the

ELSE clause are processed.

DECLARE x INTEGER;

SET x = 42;

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;

10 ESQL

Many statements can have expressions nested within them, but only a few can

have statements nested within them. The key difference between an expression and

a statement is that an expression calculates a value to be used, whereas a statement

performs an action (usually changing the state of the program) but does not

produce a value.

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.

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.

When you define a function, you must give it a unique name. 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). This 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.

Consider the following ESQL program fragment:

In this example, the function SQRT (square root) is given the value inside the

brackets (itself the result of an expression, a divide operation) and its result is used

in a further expression, a multiply operation. Its return value is assigned to the

variable Diameter. See “Calling ESQL functions” on page 260 for information about

all the built-in ESQL functions.

In addition, an ESQL expression can refer to a function in another broker schema

(that is, a function defined by a CREATE FUNCTION statement in an ESQL file in

the same or in a different dependent project). To resolve the name of the called

function, you must do one of the following:

v Specify the fully-qualified name (<SchemaName>.<FunctionName>) of the called

function.

v Include a PATH statement to make all functions from the named schema visible.

Note that this technique only works if the schemas do not contain

identically-named functions. The PATH statement must be coded in the same

ESQL file, but not within any MODULE.

Note

that you cannot define a function within an EVAL statement or an EVAL

function.

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.

SET Diameter = SQRT(Area / 3.142) * 2;

Developing ESQL 11

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

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. You cannot define a procedure within an EVAL statement or an

EVAL function.

When you define a procedure, give it a name. 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.

An ESQL expression can include a reference to a procedure in another broker

schema (defined in an ESQL file in the same or a different dependent project). If

you want to use this technique, either fully qualify the procedure, or include a

PATH statement that sets the qualifier. The PATH statement must be coded in the

same ESQL file, but not within a MODULE.

An external database procedure is indicated by the keyword EXTERNAL and the

external procedure name. This procedure must be defined in the database and in

the broker, and the name specified with the EXTERNAL keyword and the name of

the stored database procedure must be the same, although parameter names do not

have to match. The ESQL procedure name can be different to the external name it

defines.

Overloaded procedures are not supported to any database. (An overloaded

procedure is one that has the same name as another procedure in the same

database schema which has a different number of parameters, or parameters with

different types.) If the broker detects that a procedure has been overloaded, it

raises an exception.

Dynamic schema name resolution for stored procedures is supported; when you

define the procedure you must specify a wildcard for the schema that is resolved

before invocation of the procedure by ESQL. This is explained further in “Invoking

stored procedures” on page 70.

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. 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. 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

12 ESQL

剩余377页未读，继续阅读

qunqin

粉丝: 39
资源: 1

ESQL入门指南：WebSphereMessageBroker V6开发核心技术

Websphere Message Broker ESQL

WebShpere Message Broker ESQL使用讲解

Webspere Message Broker

ESQL详解：WebSphere Message Broker中的高级编程语言

Message Broker连接数据库

Websphere message broker 培训资料

IBM Message Broker知识点记录

WebSphere Message Broker 开发和部署最佳实践

ESQL Sonar Plugin [Move to GitHub]:用于分析Broker ESQL代码的Sonar插件-开源

Java 在 Message Broker 中的应用.rar

最新资源