Transforming from one data type to another

Code ESQL functions and statements to transform messages and data types in
many ways.
The following topics provide guidance:
v Casting data from message fields
v Converting code page and message encoding
v Converting EBCDIC NL to ASCII CR LF on page 63
v Changing message format on page 65
Casting data from message fields
You can use the CAST function to transform the data type of one value to match
the data type of the other. For example, you can use the CAST function when you
process generic XML messages. All fields in an XML message have character
values, so if you want to perform arithmetic calculations or datetime comparison
s,
for example, you must convert the string value of the field into a value of the
appropriate type using CAST.
When you compare an element with another element, variable or constant, ensure
that the value with which you are comparing the element is consistent (for
example, character with character). If the values are not consistent, the broker
generates a runtime error if it cannot provide an implicit casting to resolve th
e
inconsistency. For details of what implicit casts are supported, see Implicit cas
ts
on page 365.
In the Invoice message, the field InvoiceDate contains the date of the invoice.
If
you want to refer to or manipulate this field, you must CAST it to the correct
format first. For example, to refer to this field in a test:
This converts the string value of the InvoiceDate field into a date value, and
compares it to the current date.
Another example is casting from integer to character:
Converting code page and message encoding
You can use ESQL within a Compute node to convert data for code page and
message encoding.
IF CAST(Body.Invoice.InvoiceDate AS DATE) = CURRENT_DATE THEN
DECLARE I INTEGER 1;
DECLARE C CHARACTER;
-- The following statement generates an error
SET C = I;
-- The following statement is valid
SET C = CAST(I AS CHARACTER);
60 ESQLIf your message flow is processing WebSphere MQ messages, you can use
WebSphere MQ facilities (including get and put options and WebSphere MQ data
conversion exits) to provide these conversions. If you are not processing
WebSphere MQ messages, or you choose not to use WebSphere MQ facilities, you
can use WebSphere Message Broker facilities by coding the appropriate ESQL in a
Compute node in your message flow.
The contents of the MQMD, the MQRFH2, and the message body of a message in
the MRM domain that has been modeled with a CWF physical format can be
subject to code page and encoding conversion. The contents of a message body of
a message in the XML, XMLNS, and JMS domains, and those messages in the
MRM domain that have been modeled with an XML or TDS physical format, are
treated as strings. Only code page conversion applies; no encoding conversion is
required.
For messages in the MRM domain modeled with a CWF physical format, you can
set the MQMD CCSID and Encoding fields of the output message, plus the CCSID
and Encoding of any additional headers, to the required target value.
For messages in the MRM domain modeled with an XML or TDS physical format,
you can set the MQMD CCSID field of the output message, plus the CCSID of any
additional headers. XML and TDS data is handled as strings and is therefore
subject to CCSID conversion only.
An example WebSphere MQ message has an MQMD header, an MQRFH2 header,
and a message body. To convert this message to a mainframe CodedCharSetId and
Encoding, code the following ESQL in the Compute node:
The following example illustrates what you must do to modify a CWF message so
that it can be passed from WebSphere Message Broker to IMS on z/OS.
1. You have defined the input message in XML and are using an MQRFH2
header. Remove the header before passing the message to IMS.
2. The message passed to IMS must have MQIIH header, and must be in the
z/OS code page. This message is modeled in the MRM and has the name
IMS1. Define the PIC X fields in this message as logical type string for
conversions between EBCDIC and ASCII to take place. If the fields are binary
logical type, no data conversion occurs; binary data is ignored when a CWF
message is parsed by the MRM parser.
3. The message received from IMS is also defined in the MRM and has the name
IMS2. Define the PIC X fields in this message as logical type string for
conversions between EBCDIC and ASCII to take place. If the fields are binary
logical type, no data conversion occurs; binary data is ignored when a CWF
message is parsed by the MRM parser.
4. Convert the reply message to the Windows code page. The MQIIH header is
retained on this message.
5. You have created a message flow that contains the following nodes: :
a. The outbound flow, MQInput1 --> Compute1 --> MQOutput1.
b. The inbound flow, MQInput2 --> Compute2 --> MQOutput2.
6. Code ESQL in Compute1 (outbound) node as follows, specifying the relevant
MessageSet ID. This code shows the use of the default CWF physical layer
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQRFH2.CodedCharSetId = 500;
SET OutputRoot.MQRFH2.Encoding = 785;
Developing ESQL 61name. You must use the name that matches your model definition
s. If you
specify an incorrect value, the broker fails with message BIP5431.
The use of a variable, J, that is initialized to the value of the cardinality of
the
existing headers in the message, is more efficient than calculating the
cardinality on each iteration of the loop, which happens if you code the
following WHILE statement:
7. Create ESQL in Compute2 (inbound) node as follows, specifying the relevant
MessageSet ID. This code shows the use of the default CWF physical layer
name. You must use the name that matches your model definition. If you
specify an incorrect value, the broker fails with message BIP5431.
-- Loop to copy message headers
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
WHILE I < J - 1 DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQMD.Format = 'MQIMS ';
SET OutputRoot.MQIIH.Version = 1;
SET OutputRoot.MQIIH.StrucLength = 84;
SET OutputRoot.MQIIH.Encoding = 785;
SET OutputRoot.MQIIH.CodedCharSetId = 500;
SET OutputRoot.MQIIH.Format = 'MQIMSVS ';
SET OutputRoot.MQIIH.Flags = 0;
SET OutputRoot.MQIIH.LTermOverride = ' ';
SET OutputRoot.MQIIH.MFSMapName = ' ';
SET OutputRoot.MQIIH.ReplyToFormat = 'MQIMSVS ';
SET OutputRoot.MQIIH.Authenticator = ' ';
SET OutputRoot.MQIIH.TranInstanceId = X'00000000000000000000000000000000';
SET OutputRoot.MQIIH.TranState = ' ';
SET OutputRoot.MQIIH.CommitMode = '0';
SET OutputRoot.MQIIH.SecurityScope = 'C';
SET OutputRoot.MQIIH.Reserved = ' ';
SET OutputRoot.MRM.e_elen08 = 30;
SET OutputRoot.MRM.e_elen09 = 0;
SET OutputRoot.MRM.e_string08 = InputBody.e_string01;
SET OutputRoot.MRM.e_binary02 = X'31323334353637383940';
SET OutputRoot.Properties.MessageSet = 'DHCJOEG072001';
SET OutputRoot.Properties.MessageType = 'IMS1';
SET OutputRoot.Properties.MessageFormat = 'Binary1';
WHILE I < CARDINALITY(InputRoot.*[]) DO
62 ESQLYou do not have to set any specific values for the MQInput1 node properti
es,
because the message and message set are identified in the MQRFH2 header, and
no conversion is required.
You must set values for message domain, set, type, and format in the MQInput
node for the inbound message flow (MQInput2). You do not need to set conversion
parameters.
One specific situation in which you might need to convert data in one code page
to another is when messages contain newline characters and are passed between
EBCDIC and ASCII systems. The required conversion for this situation is describe
d
in Converting EBCDIC NL to ASCII CR LF.
Converting EBCDIC NL to ASCII CR LF:
You might want to change newline (NL) characters in a text message to carriage
return (CR) and line feed (LF) character pairs. This example shows one way in
which you can convert these characters.
This conversion might be useful if messages from an EBCDIC platform (for
example, using CCSID 1047) are sent to an ASCII platform (for example, using
CCSID 437). Problems can arise because the EBCDIC NL character hex '15' is
converted to the undefined ASCII character hex '7F'. The ASCII code page has no
corresponding code point for the NL character.
In this example, a message flow is created that interprets the input message as
a
message in the BLOB domain. This message is passed into a
ResetContentDescriptor node to reset the data to a message in the MRM domain.
The message is called msg_nl (a set of repeating string elements delimited by
EBCDIC NL characters). A Compute node is then used to create an output based
on another message in the MRM domain called msg_crlf (a set of repeating string
elements delimited by CR LF pairs). The message domain is then changed back to
BLOB in another ResetContentDescriptor node. This message flow is shown in the
following diagram.
-- Loop to copy message headers
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
SET OutputRoot.MQMD.CodedCharSetId = 437;
SET OutputRoot.MQMD.Encoding = 546;
SET OutputRoot.MQMD.Format = 'MQIMS ';
SET OutputRoot.MQIIH.CodedCharSetId = 437;
SET OutputRoot.MQIIH.Encoding = 546;
SET OutputRoot.MQIIH.Format = ' ';
SET OutputRoot.MRM = InputBody;
SET OutputRoot.Properties.MessageSet = 'DHCJOEG072001';
SET OutputRoot.Properties.MessageType = 'IMS2';
SET OutputRoot.Properties.MessageFormat = 'Binary1';
Developing ESQL 63MQInput MQOutput Compute
ResetContentDescriptor ResetContentDescriptor1
The following instructions show how to create the messages and configure the
message flow.
1. Create the message models for the messages in the MRM domain:
a. Create a message set project called myProj.
b. Create a message set called myMessageSet with a TDS physical format (the
default name is Text1).
c. Create an element string1 of type xsd:string.
d. Create a complex type called t_msg_nl and specify the following complex
type properties:
v Composition = Ordered Set
v Content Validation = Closed
v Data Element Separation = All Elements Delimited
v Delimiter = <U+0085> (hex '0085' is the UTF-16 representation of an NL
character)
v Repeat = Yes
v Min Occurs = 1
v Max Occurs = 50 (the text of the message is assumed to consist of no
more than 50 lines)
e. Add Element string1, and set the following property:
v Repeating Element Delimiter = <U+0085>
f. Create a Message msg_nl, and set its associated complex type to t_msg_nl
g. Create a complex type called t_msg_crlf, and specify the following complex
type properties:
v Composition = Ordered Set
v Content Validation = Closed
v Data Element Separation = All Elements Delimited
v Delimiter = <CR><LF> (<CR> and <LF> are the mnemonics for the CR
and LF characters)
v Repeat = Yes
v Min Occurs = 1
v Max Occurs = 50
h. Add Element string1, and set the following property:
v Repeating Element Delimiter = <CR><LF>Transforming from one data type to anoth
er
Code ESQL functions and statements to transform messages and data types in
many ways.
The following topics provide guidance:
v Casting data from message fields
v Converting code page and message encoding
v Converting EBCDIC NL to ASCII CR LF on page 63
v Changing message format on page 65
Casting data from message fields
You can use the CAST function to transform the data type of one value to match
the data type of the other. For example, you can use the CAST function when you
process generic XML messages. All fields in an XML message have character
values, so if you want to perform arithmetic calculations or datetime comparison
s,
for example, you must convert the string value of the field into a value of the
appropriate type using CAST.
When you compare an element with another element, variable or constant, ensure
that the value with which you are comparing the element is consistent (for
example, character with character). If the values are not consistent, the broker
generates a runtime error if it cannot provide an implicit casting to resolve th
e
inconsistency. For details of what implicit casts are supported, see Implicit cas
ts
on page 365.
In the Invoice message, the field InvoiceDate contains the date of the invoice.
If
you want to refer to or manipulate this field, you must CAST it to the correct
format first. For example, to refer to this field in a test:
This converts the string value of the InvoiceDate field into a date value, and
compares it to the current date.
Another example is casting from integer to character:
Converting code page and message encoding
You can use ESQL within a Compute node to convert data for code page and
message encoding.
IF CAST(Body.Invoice.InvoiceDate AS DATE) = CURRENT_DATE THEN
DECLARE I INTEGER 1;
DECLARE C CHARACTER;
-- The following statement generates an error
SET C = I;
-- The following statement is valid
SET C = CAST(I AS CHARACTER);
60 ESQLIf your message flow is processing WebSphere MQ messages, you can use
WebSphere MQ facilities (including get and put options and WebSphere MQ data
conversion exits) to provide these conversions. If you are not processing
WebSphere MQ messages, or you choose not to use WebSphere MQ facilities, you
can use WebSphere Message Broker facilities by coding the appropriate ESQL in a
Compute node in your message flow.
The contents of the MQMD, the MQRFH2, and the message body of a message in
the MRM domain that has been modeled with a CWF physical format can be
subject to code page and encoding conversion. The contents of a message body of
a message in the XML, XMLNS, and JMS domains, and those messages in the
MRM domain that have been modeled with an XML or TDS physical format, are
treated as strings. Only code page conversion applies; no encoding conversion is
required.
For messages in the MRM domain modeled with a CWF physical format, you can
set the MQMD CCSID and Encoding fields of the output message, plus the CCSID
and Encoding of any additional headers, to the required target value.
For messages in the MRM domain modeled with an XML or TDS physical format,
you can set the MQMD CCSID field of the output message, plus the CCSID of any
additional headers. XML and TDS data is handled as strings and is therefore
subject to CCSID conversion only.
An example WebSphere MQ message has an MQMD header, an MQRFH2 header,
and a message body. To convert this message to a mainframe CodedCharSetId and
Encoding, code the following ESQL in the Compute node:
The following example illustrates what you must do to modify a CWF message so
that it can be passed from WebSphere Message Broker to IMS on z/OS.
1. You have defined the input message in XML and are using an MQRFH2
header. Remove the header before passing the message to IMS.
2. The message passed to IMS must have MQIIH header, and must be in the
z/OS code page. This message is modeled in the MRM and has the name
IMS1. Define the PIC X fields in this message as logical type string for
conversions between EBCDIC and ASCII to take place. If the fields are binary
logical type, no data conversion occurs; binary data is ignored when a CWF
message is parsed by the MRM parser.
3. The message received from IMS is also defined in the MRM and has the name
IMS2. Define the PIC X fields in this message as logical type string for
conversions between EBCDIC and ASCII to take place. If the fields are binary
logical type, no data conversion occurs; binary data is ignored when a CWF
message is parsed by the MRM parser.
4. Convert the reply message to the Windows code page. The MQIIH header is
retained on this message.
5. You have created a message flow that contains the following nodes: :
a. The outbound flow, MQInput1 --> Compute1 --> MQOutput1.
b. The inbound flow, MQInput2 --> Compute2 --> MQOutput2.
6. Code ESQL in Compute1 (outbound) node as follows, specifying the relevant
MessageSet ID. This code shows the use of the default CWF physical layer
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQRFH2.CodedCharSetId = 500;
SET OutputRoot.MQRFH2.Encoding = 785;
Developing ESQL 61name. You must use the name that matches your model definition
s. If you
specify an incorrect value, the broker fails with message BIP5431.
The use of a variable, J, that is initialized to the value of the cardinality of
the
existing headers in the message, is more efficient than calculating the
cardinality on each iteration of the loop, which happens if you code the
following WHILE statement:
7. Create ESQL in Compute2 (inbound) node as follows, specifying the relevant
MessageSet ID. This code shows the use of the default CWF physical layer
name. You must use the name that matches your model definition. If you
specify an incorrect value, the broker fails with message BIP5431.
-- Loop to copy message headers
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
WHILE I < J - 1 DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQMD.Format = 'MQIMS ';
SET OutputRoot.MQIIH.Version = 1;
SET OutputRoot.MQIIH.StrucLength = 84;
SET OutputRoot.MQIIH.Encoding = 785;
SET OutputRoot.MQIIH.CodedCharSetId = 500;
SET OutputRoot.MQIIH.Format = 'MQIMSVS ';
SET OutputRoot.MQIIH.Flags = 0;
SET OutputRoot.MQIIH.LTermOverride = ' ';
SET OutputRoot.MQIIH.MFSMapName = ' ';
SET OutputRoot.MQIIH.ReplyToFormat = 'MQIMSVS ';
SET OutputRoot.MQIIH.Authenticator = ' ';
SET OutputRoot.MQIIH.TranInstanceId = X'00000000000000000000000000000000';
SET OutputRoot.MQIIH.TranState = ' ';
SET OutputRoot.MQIIH.CommitMode = '0';
SET OutputRoot.MQIIH.SecurityScope = 'C';
SET OutputRoot.MQIIH.Reserved = ' ';
SET OutputRoot.MRM.e_elen08 = 30;
SET OutputRoot.MRM.e_elen09 = 0;
SET OutputRoot.MRM.e_string08 = InputBody.e_string01;
SET OutputRoot.MRM.e_binary02 = X'31323334353637383940';
SET OutputRoot.Properties.MessageSet = 'DHCJOEG072001';
SET OutputRoot.Properties.MessageType = 'IMS1';
SET OutputRoot.Properties.MessageFormat = 'Binary1';
WHILE I < CARDINALITY(InputRoot.*[]) DO
62 ESQLYou do not have to set any specific values for the MQInput1 node properti
es,
because the message and message set are identified in the MQRFH2 header, and
no conversion is required.
You must set values for message domain, set, type, and format in the MQInput
node for the inbound message flow (MQInput2). You do not need to set conversion
parameters.
One specific situation in which you might need to convert data in one code page
to another is when messages contain newline characters and are passed between
EBCDIC and ASCII systems. The required conversion for this situation is describe
d
in Converting EBCDIC NL to ASCII CR LF.
Converting EBCDIC NL to ASCII CR LF:
You might want to change newline (NL) characters in a text message to carriage
return (CR) and line feed (LF) character pairs. This example shows one way in
which you can convert these characters.
This conversion might be useful if messages from an EBCDIC platform (for
example, using CCSID 1047) are sent to an ASCII platform (for example, using
CCSID 437). Problems can arise because the EBCDIC NL character hex '15' is
converted to the undefined ASCII character hex '7F'. The ASCII code page has no
corresponding code point for the NL character.
In this example, a message flow is created that interprets the input message as
a
message in the BLOB domain. This message is passed into a
ResetContentDescriptor node to reset the data to a message in the MRM domain.
The message is called msg_nl (a set of repeating string elements delimited by
EBCDIC NL characters). A Compute node is then used to create an output based
on another message in the MRM domain called msg_crlf (a set of repeating string
elements delimited by CR LF pairs). The message domain is then changed back to
BLOB in another ResetContentDescriptor node. This message flow is shown in the
following diagram.
-- Loop to copy message headers
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
SET OutputRoot.MQMD.CodedCharSetId = 437;
SET OutputRoot.MQMD.Encoding = 546;
SET OutputRoot.MQMD.Format = 'MQIMS ';
SET OutputRoot.MQIIH.CodedCharSetId = 437;
SET OutputRoot.MQIIH.Encoding = 546;
SET OutputRoot.MQIIH.Format = ' ';
SET OutputRoot.MRM = InputBody;
SET OutputRoot.Properties.MessageSet = 'DHCJOEG072001';
SET OutputRoot.Properties.MessageType = 'IMS2';
SET OutputRoot.Properties.MessageFormat = 'Binary1';
Developing ESQL 63MQInput MQOutput Compute
ResetContentDescriptor ResetContentDescriptor1
The following instructions show how to create the messages and configure the
message flow.
1. Create the message models for the messages in the MRM domain:
a. Create a message set project called myProj.
b. Create a message set called myMessageSet with a TDS physical format (the
default name is Text1).
c. Create an element string1 of type xsd:string.
d. Create a complex type called t_msg_nl and specify the following complex
type properties:
v Composition = Ordered Set
v Content Validation = Closed
v Data Element Separation = All Elements Delimited
v Delimiter = <U+0085> (hex '0085' is the UTF-16 representation of an NL
character)
v Repeat = Yes
v Min Occurs = 1
v Max Occurs = 50 (the text of the message is assumed to consist of no
more than 50 lines)
e. Add Element string1, and set the following property:
v Repeating Element Delimiter = <U+0085>
f. Create a Message msg_nl, and set its associated complex type to t_msg_nl
g. Create a complex type called t_msg_crlf, and specify the following complex
type properties:
v Composition = Ordered Set
v Content Validation = Closed
v Data Element Separation = All Elements Delimited
v Delimiter = <CR><LF> (<CR> and <LF> are the mnemonics for the CR
and LF characters)
v Repeat = Yes
v Min Occurs = 1
v Max Occurs = 50
h. Add Element string1, and set the following property:
v Repeating Element Delimiter = <CR><LF>
i. Create a Message msg_crlf, and set complex type to t_msg_crlf.
2. Configure the message flow shown in the previous figure:
a. Start with the MQInput node:
v Set Message Domain = BLOB
v Set Queue Name = <Your input message queue name>
b. Add the ResetContentDescriptor node, connected to the Out terminal of the
MQInput node:
v Set Message Domain = MRM
64 ESQLv Select Reset Message Domain
v Set Message Set = <Your Message Set ID> (this field has a maximum of
13 characters)
v Select Reset Message Set
v Set Message Type = msg_nl
v Select Reset Message Type
v Set Message Format = Text1
v Select Reset Message Format
c. Add the Compute node, connected to the Out terminal of the
ResetContentDescriptor node:
v Enter a name for the ESQL Module for this node, or accept the default
(<message flow name>_Compute).
v Right-click the Compute node, and select Open ESQL. Add the following
ESQL code in the module:
The use of a variable, J, initialized to the value of the cardinality of the
existing headers in the message, is more efficient than calculating the
cardinality on each iteration of the loop, which happens if you code the
following WHILE statement:
d. Add the ResetContentDescriptor1 node, connected to the Out terminal of
the Compute node:
v Set Message Domain = BLOB
v Select Reset Message Domain.
e. Finally, add the MQOutput node, connected to the Out terminal of the
ResetContentDescriptor1 node. Configure its properties to direct the output
message to the required queue or queues.
Changing message format
Use the Compute node to copy part of an input message to an output message.
The results of such a copy depend on the type of input and output parsers
involved.
Like parsers:
-- Declare local working variables
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
-- Loop to copy all message headers from input to output message
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
-- Set new output message type which uses CRLF delimiter
SET OutputRoot.Properties.MessageType = 't_msg_crlf';
-- Loop to copy each instance of string1 child within message body
SET I = 1;
SET J = CARDINALITY("InputBody"."string1"[]);
WHILE I <= J DO
SET "OutputRoot"."MRM"."string1"[I] = "InputBody"."string1"[I];
SET I=I+1;
END WHILE;
WHILE I < CARDINALITY(InputRoot.*[]) DO
Developing ESQL 65Where both the source and target messages have the same folder
structure at root
level, a like-parser-copy is performed. For example:
This statement copies all the children in the MQMD folder of the input message t
o
the MQMD folder of the output message.
Another example of a tree structure that supports a like-parser-copy is:
To transform an input message in the MRM domain to an output message also in
the MRM domain, you can use either the Compute or the Mapping node. The
Mapping node can interpret the action that is required because it knows the form
at
of both messages. Content Assist in the ESQL module for the Compute node can
also use the message definitions for those messages. If the messages are not in
the
same namespace, you must use the Compute node.
To use Content Assist with message references, you must set up a project referen
ce
from the project containing the ESQL to the project containing the message set.
For
information about setting up a project reference, see Project references.
If both input and output messages are not in the MRM domain, you must use the
Compute node and specify the structure of the messages yourself.
Unlike parsers:
Where the source and target messages have different folder structures at root le
vel,
you cannot make an exact copy of the message source. Instead, the
unlike-parser-copy views the source message as a set of nested folders terminate
d by
a leaf name-value pair. For example, copying the following message from XML to
MRM:
produces a name element Name3, and a name-value element called Name31Transformin
g from one data type to another
Code ESQL functions and statements to transform messages and data types in
many ways.
The following topics provide guidance:
v Casting data from message fields
v Converting code page and message encoding
v Converting EBCDIC NL to ASCII CR LF on page 63
v Changing message format on page 65
Casting data from message fields
You can use the CAST function to transform the data type of one value to match
the data type of the other. For example, you can use the CAST function when you
process generic XML messages. All fields in an XML message have character
values, so if you want to perform arithmetic calculations or datetime comparison
s,
for example, you must convert the string value of the field into a value of the
appropriate type using CAST.
When you compare an element with another element, variable or constant, ensure
that the value with which you are comparing the element is consistent (for
example, character with character). If the values are not consistent, the broker
generates a runtime error if it cannot provide an implicit casting to resolve th
e
inconsistency. For details of what implicit casts are supported, see Implicit cas
ts
on page 365.
In the Invoice message, the field InvoiceDate contains the date of the invoice.
If
you want to refer to or manipulate this field, you must CAST it to the correct
format first. For example, to refer to this field in a test:
This converts the string value of the InvoiceDate field into a date value, and
compares it to the current date.
Another example is casting from integer to character:
Converting code page and message encoding
You can use ESQL within a Compute node to convert data for code page and
message encoding.
IF CAST(Body.Invoice.InvoiceDate AS DATE) = CURRENT_DATE THEN
DECLARE I INTEGER 1;
DECLARE C CHARACTER;
-- The following statement generates an error
SET C = I;
-- The following statement is valid
SET C = CAST(I AS CHARACTER);
60 ESQLIf your message flow is processing WebSphere MQ messages, you can use
WebSphere MQ facilities (including get and put options and WebSphere MQ data
conversion exits) to provide these conversions. If you are not processing
WebSphere MQ messages, or you choose not to use WebSphere MQ facilities, you
can use WebSphere Message Broker facilities by coding the appropriate ESQL in a
Compute node in your message flow.
The contents of the MQMD, the MQRFH2, and the message body of a message in
the MRM domain that has been modeled with a CWF physical format can be
subject to code page and encoding conversion. The contents of a message body of
a message in the XML, XMLNS, and JMS domains, and those messages in the
MRM domain that have been modeled with an XML or TDS physical format, are
treated as strings. Only code page conversion applies; no encoding conversion is
required.
For messages in the MRM domain modeled with a CWF physical format, you can
set the MQMD CCSID and Encoding fields of the output message, plus the CCSID
and Encoding of any additional headers, to the required target value.
For messages in the MRM domain modeled with an XML or TDS physical format,
you can set the MQMD CCSID field of the output message, plus the CCSID of any
additional headers. XML and TDS data is handled as strings and is therefore
subject to CCSID conversion only.
An example WebSphere MQ message has an MQMD header, an MQRFH2 header,
and a message body. To convert this message to a mainframe CodedCharSetId and
Encoding, code the following ESQL in the Compute node:
The following example illustrates what you must do to modify a CWF message so
that it can be passed from WebSphere Message Broker to IMS on z/OS.
1. You have defined the input message in XML and are using an MQRFH2
header. Remove the header before passing the message to IMS.
2. The message passed to IMS must have MQIIH header, and must be in the
z/OS code page. This message is modeled in the MRM and has the name
IMS1. Define the PIC X fields in this message as logical type string for
conversions between EBCDIC and ASCII to take place. If the fields are binary
logical type, no data conversion occurs; binary data is ignored when a CWF
message is parsed by the MRM parser.
3. The message received from IMS is also defined in the MRM and has the name
IMS2. Define the PIC X fields in this message as logical type string for
conversions between EBCDIC and ASCII to take place. If the fields are binary
logical type, no data conversion occurs; binary data is ignored when a CWF
message is parsed by the MRM parser.
4. Convert the reply message to the Windows code page. The MQIIH header is
retained on this message.
5. You have created a message flow that contains the following nodes: :
a. The outbound flow, MQInput1 --> Compute1 --> MQOutput1.
b. The inbound flow, MQInput2 --> Compute2 --> MQOutput2.
6. Code ESQL in Compute1 (outbound) node as follows, specifying the relevant
MessageSet ID. This code shows the use of the default CWF physical layer
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQRFH2.CodedCharSetId = 500;
SET OutputRoot.MQRFH2.Encoding = 785;
Developing ESQL 61name. You must use the name that matches your model definition
s. If you
specify an incorrect value, the broker fails with message BIP5431.
The use of a variable, J, that is initialized to the value of the cardinality of
the
existing headers in the message, is more efficient than calculating the
cardinality on each iteration of the loop, which happens if you code the
following WHILE statement:
7. Create ESQL in Compute2 (inbound) node as follows, specifying the relevant
MessageSet ID. This code shows the use of the default CWF physical layer
name. You must use the name that matches your model definition. If you
specify an incorrect value, the broker fails with message BIP5431.
-- Loop to copy message headers
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
WHILE I < J - 1 DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQMD.Format = 'MQIMS ';
SET OutputRoot.MQIIH.Version = 1;
SET OutputRoot.MQIIH.StrucLength = 84;
SET OutputRoot.MQIIH.Encoding = 785;
SET OutputRoot.MQIIH.CodedCharSetId = 500;
SET OutputRoot.MQIIH.Format = 'MQIMSVS ';
SET OutputRoot.MQIIH.Flags = 0;
SET OutputRoot.MQIIH.LTermOverride = ' ';
SET OutputRoot.MQIIH.MFSMapName = ' ';
SET OutputRoot.MQIIH.ReplyToFormat = 'MQIMSVS ';
SET OutputRoot.MQIIH.Authenticator = ' ';
SET OutputRoot.MQIIH.TranInstanceId = X'00000000000000000000000000000000';
SET OutputRoot.MQIIH.TranState = ' ';
SET OutputRoot.MQIIH.CommitMode = '0';
SET OutputRoot.MQIIH.SecurityScope = 'C';
SET OutputRoot.MQIIH.Reserved = ' ';
SET OutputRoot.MRM.e_elen08 = 30;
SET OutputRoot.MRM.e_elen09 = 0;
SET OutputRoot.MRM.e_string08 = InputBody.e_string01;
SET OutputRoot.MRM.e_binary02 = X'31323334353637383940';
SET OutputRoot.Properties.MessageSet = 'DHCJOEG072001';
SET OutputRoot.Properties.MessageType = 'IMS1';
SET OutputRoot.Properties.MessageFormat = 'Binary1';
WHILE I < CARDINALITY(InputRoot.*[]) DO
62 ESQLYou do not have to set any specific values for the MQInput1 node properti
es,
because the message and message set are identified in the MQRFH2 header, and
no conversion is required.
You must set values for message domain, set, type, and format in the MQInput
node for the inbound message flow (MQInput2). You do not need to set conversion
parameters.
One specific situation in which you might need to convert data in one code page
to another is when messages contain newline characters and are passed between
EBCDIC and ASCII systems. The required conversion for this situation is describe
d
in Converting EBCDIC NL to ASCII CR LF.
Converting EBCDIC NL to ASCII CR LF:
You might want to change newline (NL) characters in a text message to carriage
return (CR) and line feed (LF) character pairs. This example shows one way in
which you can convert these characters.
This conversion might be useful if messages from an EBCDIC platform (for
example, using CCSID 1047) are sent to an ASCII platform (for example, using
CCSID 437). Problems can arise because the EBCDIC NL character hex '15' is
converted to the undefined ASCII character hex '7F'. The ASCII code page has no
corresponding code point for the NL character.
In this example, a message flow is created that interprets the input message as
a
message in the BLOB domain. This message is passed into a
ResetContentDescriptor node to reset the data to a message in the MRM domain.
The message is called msg_nl (a set of repeating string elements delimited by
EBCDIC NL characters). A Compute node is then used to create an output based
on another message in the MRM domain called msg_crlf (a set of repeating string
elements delimited by CR LF pairs). The message domain is then changed back to
BLOB in another ResetContentDescriptor node. This message flow is shown in the
following diagram.
-- Loop to copy message headers
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
SET OutputRoot.MQMD.CodedCharSetId = 437;
SET OutputRoot.MQMD.Encoding = 546;
SET OutputRoot.MQMD.Format = 'MQIMS ';
SET OutputRoot.MQIIH.CodedCharSetId = 437;
SET OutputRoot.MQIIH.Encoding = 546;
SET OutputRoot.MQIIH.Format = ' ';
SET OutputRoot.MRM = InputBody;
SET OutputRoot.Properties.MessageSet = 'DHCJOEG072001';
SET OutputRoot.Properties.MessageType = 'IMS2';
SET OutputRoot.Properties.MessageFormat = 'Binary1';
Developing ESQL 63MQInput MQOutput Compute
ResetContentDescriptor ResetContentDescriptor1
The following instructions show how to create the messages and configure the
message flow.
1. Create the message models for the messages in the MRM domain:
a. Create a message set project called myProj.
b. Create a message set called myMessageSet with a TDS physical format (the
default name is Text1).
c. Create an element string1 of type xsd:string.
d. Create a complex type called t_msg_nl and specify the following complex
type properties:
v Composition = Ordered Set
v Content Validation = Closed
v Data Element Separation = All Elements Delimited
v Delimiter = <U+0085> (hex '0085' is the UTF-16 representation of an NL
character)
v Repeat = Yes
v Min Occurs = 1
v Max Occurs = 50 (the text of the message is assumed to consist of no
more than 50 lines)
e. Add Element string1, and set the following property:
v Repeating Element Delimiter = <U+0085>
f. Create a Message msg_nl, and set its associated complex type to t_msg_nl
g. Create a complex type called t_msg_crlf, and specify the following complex
type properties:
v Composition = Ordered Set
v Content Validation = Closed
v Data Element Separation = All Elements Delimited
v Delimiter = <CR><LF> (<CR> and <LF> are the mnemonics for the CR
and LF characters)
v Repeat = Yes
v Min Occurs = 1
v Max Occurs = 50
h. Add Element string1, and set the following property:
v Repeating Element Delimiter = <CR><LF>
i. Create a Message msg_crlf, and set complex type to t_msg_crlf.
2. Configure the message flow shown in the previous figure:
a. Start with the MQInput node:
v Set Message Domain = BLOB
v Set Queue Name = <Your input message queue name>
b. Add the ResetContentDescriptor node, connected to the Out terminal of the
MQInput node:
v Set Message Domain = MRM
64 ESQLv Select Reset Message Domain
v Set Message Set = <Your Message Set ID> (this field has a maximum of
13 characters)
v Select Reset Message Set
v Set Message Type = msg_nl
v Select Reset Message Type
v Set Message Format = Text1
v Select Reset Message Format
c. Add the Compute node, connected to the Out terminal of the
ResetContentDescriptor node:
v Enter a name for the ESQL Module for this node, or accept the default
(<message flow name>_Compute).
v Right-click the Compute node, and select Open ESQL. Add the following
ESQL code in the module:
The use of a variable, J, initialized to the value of the cardinality of the
existing headers in the message, is more efficient than calculating the
cardinality on each iteration of the loop, which happens if you code the
following WHILE statement:
d. Add the ResetContentDescriptor1 node, connected to the Out terminal of
the Compute node:
v Set Message Domain = BLOB
v Select Reset Message Domain.
e. Finally, add the MQOutput node, connected to the Out terminal of the
ResetContentDescriptor1 node. Configure its properties to direct the output
message to the required queue or queues.
Changing message format
Use the Compute node to copy part of an input message to an output message.
The results of such a copy depend on the type of input and output parsers
involved.
Like parsers:
-- Declare local working variables
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
-- Loop to copy all message headers from input to output message
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
-- Set new output message type which uses CRLF delimiter
SET OutputRoot.Properties.MessageType = 't_msg_crlf';
-- Loop to copy each instance of string1 child within message body
SET I = 1;
SET J = CARDINALITY("InputBody"."string1"[]);
WHILE I <= J DO
SET "OutputRoot"."MRM"."string1"[I] = "InputBody"."string1"[I];
SET I=I+1;
END WHILE;
WHILE I < CARDINALITY(InputRoot.*[]) DO
Developing ESQL 65Where both the source and target messages have the same folder
structure at root
level, a like-parser-copy is performed. For example:
This statement copies all the children in the MQMD folder of the input message t
o
the MQMD folder of the output message.
Another example of a tree structure that supports a like-parser-copy is:
To transform an input message in the MRM domain to an output message also in
the MRM domain, you can use either the Compute or the Mapping node. The
Mapping node can interpret the action that is required because it knows the form
at
of both messages. Content Assist in the ESQL module for the Compute node can
also use the message definitions for those messages. If the messages are not in
the
same namespace, you must use the Compute node.
To use Content Assist with message references, you must set up a project referen
ce
from the project containing the ESQL to the project containing the message set.
For
information about setting up a project reference, see Project references.
If both input and output messages are not in the MRM domain, you must use the
Compute node and specify the structure of the messages yourself.
Unlike parsers:
Where the source and target messages have different folder structures at root le
vel,
you cannot make an exact copy of the message source. Instead, the
unlike-parser-copy views the source message as a set of nested folders terminate
d by
a leaf name-value pair. For example, copying the following message from XML to
MRM:
produces a name element Name3, and a name-value element called Name31 with
the value Value31. The second XML pcdata (Value32) cannot be represented and is
discarded.Transforming from one data type to another
Code ESQL functions and statements to transform messages and data types in
many ways.
The following topics provide guidance:
v Casting data from message fields
v Converting code page and message encoding
v Converting EBCDIC NL to ASCII CR LF on page 63
v Changing message format on page 65
Casting data from message fields
You can use the CAST function to transform the data type of one value to match
the data type of the other. For example, you can use the CAST function when you
process generic XML messages. All fields in an XML message have character
values, so if you want to perform arithmetic calculations or datetime comparison
s,
for example, you must convert the string value of the field into a value of the
appropriate type using CAST.
When you compare an element with another element, variable or constant, ensure
that the value with which you are comparing the element is consistent (for
example, character with character). If the values are not consistent, the broker
generates a runtime error if it cannot provide an implicit casting to resolve th
e
inconsistency. For details of what implicit casts are supported, see Implicit cas
ts
on page 365.
In the Invoice message, the field InvoiceDate contains the date of the invoice.
If
you want to refer to or manipulate this field, you must CAST it to the correct
format first. For example, to refer to this field in a test:
This converts the string value of the InvoiceDate field into a date value, and
compares it to the current date.
Another example is casting from integer to character:
Converting code page and message encoding
You can use ESQL within a Compute node to convert data for code page and
message encoding.
IF CAST(Body.Invoice.InvoiceDate AS DATE) = CURRENT_DATE THEN
DECLARE I INTEGER 1;
DECLARE C CHARACTER;
-- The following statement generates an error
SET C = I;
-- The following statement is valid
SET C = CAST(I AS CHARACTER);
60 ESQLIf your message flow is processing WebSphere MQ messages, you can use
WebSphere MQ facilities (including get and put options and WebSphere MQ data
conversion exits) to provide these conversions. If you are not processing
WebSphere MQ messages, or you choose not to use WebSphere MQ facilities, you
can use WebSphere Message Broker facilities by coding the appropriate ESQL in a
Compute node in your message flow.
The contents of the MQMD, the MQRFH2, and the message body of a message in
the MRM domain that has been modeled with a CWF physical format can be
subject to code page and encoding conversion. The contents of a message body of
a message in the XML, XMLNS, and JMS domains, and those messages in the
MRM domain that have been modeled with an XML or TDS physical format, are
treated as strings. Only code page conversion applies; no encoding conversion is
required.
For messages in the MRM domain modeled with a CWF physical format, you can
set the MQMD CCSID and Encoding fields of the output message, plus the CCSID
and Encoding of any additional headers, to the required target value.
For messages in the MRM domain modeled with an XML or TDS physical format,
you can set the MQMD CCSID field of the output message, plus the CCSID of any
additional headers. XML and TDS data is handled as strings and is therefore
subject to CCSID conversion only.
An example WebSphere MQ message has an MQMD header, an MQRFH2 header,
and a message body. To convert this message to a mainframe CodedCharSetId and
Encoding, code the following ESQL in the Compute node:
The following example illustrates what you must do to modify a CWF message so
that it can be passed from WebSphere Message Broker to IMS on z/OS.
1. You have defined the input message in XML and are using an MQRFH2
header. Remove the header before passing the message to IMS.
2. The message passed to IMS must have MQIIH header, and must be in the
z/OS code page. This message is modeled in the MRM and has the name
IMS1. Define the PIC X fields in this message as logical type string for
conversions between EBCDIC and ASCII to take place. If the fields are binary
logical type, no data conversion occurs; binary data is ignored when a CWF
message is parsed by the MRM parser.
3. The message received from IMS is also defined in the MRM and has the name
IMS2. Define the PIC X fields in this message as logical type string for
conversions between EBCDIC and ASCII to take place. If the fields are binary
logical type, no data conversion occurs; binary data is ignored when a CWF
message is parsed by the MRM parser.
4. Convert the reply message to the Windows code page. The MQIIH header is
retained on this message.
5. You have created a message flow that contains the following nodes: :
a. The outbound flow, MQInput1 --> Compute1 --> MQOutput1.
b. The inbound flow, MQInput2 --> Compute2 --> MQOutput2.
6. Code ESQL in Compute1 (outbound) node as follows, specifying the relevant
MessageSet ID. This code shows the use of the default CWF physical layer
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQRFH2.CodedCharSetId = 500;
SET OutputRoot.MQRFH2.Encoding = 785;
Developing ESQL 61name. You must use the name that matches your model definition
s. If you
specify an incorrect value, the broker fails with message BIP5431.
The use of a variable, J, that is initialized to the value of the cardinality of
the
existing headers in the message, is more efficient than calculating the
cardinality on each iteration of the loop, which happens if you code the
following WHILE statement:
7. Create ESQL in Compute2 (inbound) node as follows, specifying the relevant
MessageSet ID. This code shows the use of the default CWF physical layer
name. You must use the name that matches your model definition. If you
specify an incorrect value, the broker fails with message BIP5431.
-- Loop to copy message headers
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
WHILE I < J - 1 DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
SET OutputRoot.MQMD.CodedCharSetId = 500;
SET OutputRoot.MQMD.Encoding = 785;
SET OutputRoot.MQMD.Format = 'MQIMS ';
SET OutputRoot.MQIIH.Version = 1;
SET OutputRoot.MQIIH.StrucLength = 84;
SET OutputRoot.MQIIH.Encoding = 785;
SET OutputRoot.MQIIH.CodedCharSetId = 500;
SET OutputRoot.MQIIH.Format = 'MQIMSVS ';
SET OutputRoot.MQIIH.Flags = 0;
SET OutputRoot.MQIIH.LTermOverride = ' ';
SET OutputRoot.MQIIH.MFSMapName = ' ';
SET OutputRoot.MQIIH.ReplyToFormat = 'MQIMSVS ';
SET OutputRoot.MQIIH.Authenticator = ' ';
SET OutputRoot.MQIIH.TranInstanceId = X'00000000000000000000000000000000';
SET OutputRoot.MQIIH.TranState = ' ';
SET OutputRoot.MQIIH.CommitMode = '0';
SET OutputRoot.MQIIH.SecurityScope = 'C';
SET OutputRoot.MQIIH.Reserved = ' ';
SET OutputRoot.MRM.e_elen08 = 30;
SET OutputRoot.MRM.e_elen09 = 0;
SET OutputRoot.MRM.e_string08 = InputBody.e_string01;
SET OutputRoot.MRM.e_binary02 = X'31323334353637383940';
SET OutputRoot.Properties.MessageSet = 'DHCJOEG072001';
SET OutputRoot.Properties.MessageType = 'IMS1';
SET OutputRoot.Properties.MessageFormat = 'Binary1';
WHILE I < CARDINALITY(InputRoot.*[]) DO
62 ESQLYou do not have to set any specific values for the MQInput1 node properti
es,
because the message and message set are identified in the MQRFH2 header, and
no conversion is required.
You must set values for message domain, set, type, and format in the MQInput
node for the inbound message flow (MQInput2). You do not need to set conversion
parameters.
One specific situation in which you might need to convert data in one code page
to another is when messages contain newline characters and are passed between
EBCDIC and ASCII systems. The required conversion for this situation is describe
d
in Converting EBCDIC NL to ASCII CR LF.
Converting EBCDIC NL to ASCII CR LF:
You might want to change newline (NL) characters in a text message to carriage
return (CR) and line feed (LF) character pairs. This example shows one way in
which you can convert these characters.
This conversion might be useful if messages from an EBCDIC platform (for
example, using CCSID 1047) are sent to an ASCII platform (for example, using
CCSID 437). Problems can arise because the EBCDIC NL character hex '15' is
converted to the undefined ASCII character hex '7F'. The ASCII code page has no
corresponding code point for the NL character.
In this example, a message flow is created that interprets the input message as
a
message in the BLOB domain. This message is passed into a
ResetContentDescriptor node to reset the data to a message in the MRM domain.
The message is called msg_nl (a set of repeating string elements delimited by
EBCDIC NL characters). A Compute node is then used to create an output based
on another message in the MRM domain called msg_crlf (a set of repeating string
elements delimited by CR LF pairs). The message domain is then changed back to
BLOB in another ResetContentDescriptor node. This message flow is shown in the
following diagram.
-- Loop to copy message headers
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
SET OutputRoot.MQMD.CodedCharSetId = 437;
SET OutputRoot.MQMD.Encoding = 546;
SET OutputRoot.MQMD.Format = 'MQIMS ';
SET OutputRoot.MQIIH.CodedCharSetId = 437;
SET OutputRoot.MQIIH.Encoding = 546;
SET OutputRoot.MQIIH.Format = ' ';
SET OutputRoot.MRM = InputBody;
SET OutputRoot.Properties.MessageSet = 'DHCJOEG072001';
SET OutputRoot.Properties.MessageType = 'IMS2';
SET OutputRoot.Properties.MessageFormat = 'Binary1';
Developing ESQL 63MQInput MQOutput Compute
ResetContentDescriptor ResetContentDescriptor1
The following instructions show how to create the messages and configure the
message flow.
1. Create the message models for the messages in the MRM domain:
a. Create a message set project called myProj.
b. Create a message set called myMessageSet with a TDS physical format (the
default name is Text1).
c. Create an element string1 of type xsd:string.
d. Create a complex type called t_msg_nl and specify the following complex
type properties:
v Composition = Ordered Set
v Content Validation = Closed
v Data Element Separation = All Elements Delimited
v Delimiter = <U+0085> (hex '0085' is the UTF-16 representation of an NL
character)
v Repeat = Yes
v Min Occurs = 1
v Max Occurs = 50 (the text of the message is assumed to consist of no
more than 50 lines)
e. Add Element string1, and set the following property:
v Repeating Element Delimiter = <U+0085>
f. Create a Message msg_nl, and set its associated complex type to t_msg_nl
g. Create a complex type called t_msg_crlf, and specify the following complex
type properties:
v Composition = Ordered Set
v Content Validation = Closed
v Data Element Separation = All Elements Delimited
v Delimiter = <CR><LF> (<CR> and <LF> are the mnemonics for the CR
and LF characters)
v Repeat = Yes
v Min Occurs = 1
v Max Occurs = 50
h. Add Element string1, and set the following property:
v Repeating Element Delimiter = <CR><LF>
i. Create a Message msg_crlf, and set complex type to t_msg_crlf.
2. Configure the message flow shown in the previous figure:
a. Start with the MQInput node:
v Set Message Domain = BLOB
v Set Queue Name = <Your input message queue name>
b. Add the ResetContentDescriptor node, connected to the Out terminal of the
MQInput node:
v Set Message Domain = MRM
64 ESQLv Select Reset Message Domain
v Set Message Set = <Your Message Set ID> (this field has a maximum of
13 characters)
v Select Reset Message Set
v Set Message Type = msg_nl
v Select Reset Message Type
v Set Message Format = Text1
v Select Reset Message Format
c. Add the Compute node, connected to the Out terminal of the
ResetContentDescriptor node:
v Enter a name for the ESQL Module for this node, or accept the default
(<message flow name>_Compute).
v Right-click the Compute node, and select Open ESQL. Add the following
ESQL code in the module:
The use of a variable, J, initialized to the value of the cardinality of the
existing headers in the message, is more efficient than calculating the
cardinality on each iteration of the loop, which happens if you code the
following WHILE statement:
d. Add the ResetContentDescriptor1 node, connected to the Out terminal of
the Compute node:
v Set Message Domain = BLOB
v Select Reset Message Domain.
e. Finally, add the MQOutput node, connected to the Out terminal of the
ResetContentDescriptor1 node. Configure its properties to direct the output
message to the required queue or queues.
Changing message format
Use the Compute node to copy part of an input message to an output message.
The results of such a copy depend on the type of input and output parsers
involved.
Like parsers:
-- Declare local working variables
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
-- Loop to copy all message headers from input to output message
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
-- Set new output message type which uses CRLF delimiter
SET OutputRoot.Properties.MessageType = 't_msg_crlf';
-- Loop to copy each instance of string1 child within message body
SET I = 1;
SET J = CARDINALITY("InputBody"."string1"[]);
WHILE I <= J DO
SET "OutputRoot"."MRM"."string1"[I] = "InputBody"."string1"[I];
SET I=I+1;
END WHILE;
WHILE I < CARDINALITY(InputRoot.*[]) DO
Developing ESQL 65Where both the source and target messages have the same folder
structure at root
level, a like-parser-copy is performed. For example:
This statement copies all the children in the MQMD folder of the input message t
o
the MQMD folder of the output message.
Another example of a tree structure that supports a like-parser-copy is:
To transform an input message in the MRM domain to an output message also in
the MRM domain, you can use either the Compute or the Mapping node. The
Mapping node can interpret the action that is required because it knows the form
at
of both messages. Content Assist in the ESQL module for the Compute node can
also use the message definitions for those messages. If the messages are not in
the
same namespace, you must use the Compute node.
To use Content Assist with message references, you must set up a project referen
ce
from the project containing the ESQL to the project containing the message set.
For
information about setting up a project reference, see Project references.
If both input and output messages are not in the MRM domain, you must use the
Compute node and specify the structure of the messages yourself.
Unlike parsers:
Where the source and target messages have different folder structures at root le
vel,
you cannot make an exact copy of the message source. Instead, the
unlike-parser-copy views the source message as a set of nested folders terminate
d by
a leaf name-value pair. For example, copying the following message from XML to
MRM:
produces a name element Name3, and a name-value element called Name31 with
the value Value31. The second XML pcdata (Value32) cannot be represented and is
discarded.
The unlike-parser-copy scans the source tree, and copies folders, also known as
name elements, and leaf name-value pairs. Everything else, including elements
flagged as special by the source parser, is not copied.
An example of a tree structure that results in an unlike-parser-copy is:
If the algorithm used to make an unlike-parser-copy does not suit your tree
structure, you should further qualify the source field to restrict the amount of
the
tree that is copied.
Be careful when you copy information from input messages to output messages in
different domains. You could code ESQL that creates a message structure or
content that is not completely consistent with the rules of the parser that proc
esses
the output message. This action can result in an output message not being create
d,
or being created with unexpected content. If you believe that the output message
SET OutputRoot.MQMD = InputRoot.MQMD;
SET OutputRoot.XMLNS.Data.Account = InputRoot.XMLNS.Customer.Bank.Data;
<Name3><Name31>Value31</Name31>Value32</Name3>
SET OutputRoot.MRM.Data.Account = InputRoot.XMLNS.Data.A
The unlike-parser-copy scans the source tree, and copies folders, also known as
name elements, and leaf name-value pairs. Everything else, including elements
flagged as special by the source parser, is not copied.
An example of a tree structure that results in an unlike-parser-copy is:
If the algorithm used to make an unlike-parser-copy does not suit your tree
structure, you should further qualify the source field to restrict the amount of
the
tree that is copied.
Be careful when you copy information from input messages to output messages in
different domains. You could code ESQL that creates a message structure or
content that is not completely consistent with the rules of the parser that proc
esses
the output message. This action can result in an output message not being create
d,
or being created with unexpected content. If you believe that the output message
SET OutputRoot.MQMD = InputRoot.MQMD;
SET OutputRoot.XMLNS.Data.Account = InputRoot.XMLNS.Customer.Bank.Data;
<Name3><Name31>Value31</Name31>Value32</Name3>
SET OutputRoot.MRM.Data.Account = InputRoot.XMLNS.Data.A with
the value Value31. The second XML pcdata (Value32) cannot be represented and is
discarded.
The unlike-parser-copy scans the source tree, and copies folders, also known as
name elements, and leaf name-value pairs. Everything else, including elements
flagged as special by the source parser, is not copied.
An example of a tree structure that results in an unlike-parser-copy is:
If the algorithm used to make an unlike-parser-copy does not suit your tree
structure, you should further qualify the source field to restrict the amount of
the
tree that is copied.
Be careful when you copy information from input messages to output messages in
different domains. You could code ESQL that creates a message structure or
content that is not completely consistent with the rules of the parser that proc
esses
the output message. This action can result in an output message not being create
d,
or being created with unexpected content. If you believe that the output message
SET OutputRoot.MQMD = InputRoot.MQMD;
SET OutputRoot.XMLNS.Data.Account = InputRoot.XMLNS.Customer.Bank.Data;
<Name3><Name31>Value31</Name31>Value32</Name3>
SET OutputRoot.MRM.Data.Account = InputRoot.XMLNS.Data.A
i. Create a Message msg_crlf, and set complex type to t_msg_crlf.
2. Configure the message flow shown in the previous figure:
a. Start with the MQInput node:
v Set Message Domain = BLOB
v Set Queue Name = <Your input message queue name>
b. Add the ResetContentDescriptor node, connected to the Out terminal of the
MQInput node:
v Set Message Domain = MRM
64 ESQLv Select Reset Message Domain
v Set Message Set = <Your Message Set ID> (this field has a maximum of
13 characters)
v Select Reset Message Set
v Set Message Type = msg_nl
v Select Reset Message Type
v Set Message Format = Text1
v Select Reset Message Format
c. Add the Compute node, connected to the Out terminal of the
ResetContentDescriptor node:
v Enter a name for the ESQL Module for this node, or accept the default
(<message flow name>_Compute).
v Right-click the Compute node, and select Open ESQL. Add the following
ESQL code in the module:
The use of a variable, J, initialized to the value of the cardinality of the
existing headers in the message, is more efficient than calculating the
cardinality on each iteration of the loop, which happens if you code the
following WHILE statement:
d. Add the ResetContentDescriptor1 node, connected to the Out terminal of
the Compute node:
v Set Message Domain = BLOB
v Select Reset Message Domain.
e. Finally, add the MQOutput node, connected to the Out terminal of the
ResetContentDescriptor1 node. Configure its properties to direct the output
message to the required queue or queues.
Changing message format
Use the Compute node to copy part of an input message to an output message.
The results of such a copy depend on the type of input and output parsers
involved.
Like parsers:
-- Declare local working variables
DECLARE I INTEGER 1;
DECLARE J INTEGER CARDINALITY(InputRoot.*[]);
-- Loop to copy all message headers from input to output message
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I=I+1;
END WHILE;
-- Set new output message type which uses CRLF delimiter
SET OutputRoot.Properties.MessageType = 't_msg_crlf';
-- Loop to copy each instance of string1 child within message body
SET I = 1;
SET J = CARDINALITY("InputBody"."string1"[]);
WHILE I <= J DO
SET "OutputRoot"."MRM"."string1"[I] = "InputBody"."string1"[I];
SET I=I+1;
END WHILE;
WHILE I < CARDINALITY(InputRoot.*[]) DO
Developing ESQL 65Where both the source and target messages have the same folder
structure at root
level, a like-parser-copy is performed. For example:
This statement copies all the children in the MQMD folder of the input message t
o
the MQMD folder of the output message.
Another example of a tree structure that supports a like-parser-copy is:
To transform an input message in the MRM domain to an output message also in
the MRM domain, you can use either the Compute or the Mapping node. The
Mapping node can interpret the action that is required because it knows the form
at
of both messages. Content Assist in the ESQL module for the Compute node can
also use the message definitions for those messages. If the messages are not in
the
same namespace, you must use the Compute node.
To use Content Assist with message references, you must set up a project referen
ce
from the project containing the ESQL to the project containing the message set.
For
information about setting up a project reference, see Project references.
If both input and output messages are not in the MRM domain, you must use the
Compute node and specify the structure of the messages yourself.
Unlike parsers:
Where the source and target messages have different folder structures at root le
vel,
you cannot make an exact copy of the message source. Instead, the
unlike-parser-copy views the source message as a set of nested folders terminate
d by
a leaf name-value pair. For example, copying the following message from XML to
MRM:
produces a name element Name3, and a name-value element called Name31 with
the value Value31. The second XML pcdata (Value32) cannot be represented and is
discarded.
The unlike-parser-copy scans the source tree, and copies folders, also known as
name elements, and leaf name-value pairs. Everything else, including elements
flagged as special by the source parser, is not copied.
An example of a tree structure that results in an unlike-parser-copy is:
If the algorithm used to make an unlike-parser-copy does not suit your tree
structure, you should further qualify the source field to restrict the amount of
the
tree that is copied.
Be careful when you copy information from input messages to output messages in
different domains. You could code ESQL that creates a message structure or
content that is not completely consistent with the rules of the parser that proc
esses
the output message. This action can result in an output message not being create
d,
or being created with unexpected content. If you believe that the output message
SET OutputRoot.MQMD = InputRoot.MQMD;
SET OutputRoot.XMLNS.Data.Account = InputRoot.XMLNS.Customer.Bank.Data;
<Name3><Name31>Value31</Name31>Value32</Name3>
SET OutputRoot.MRM.Data.Account = InputRoot.XMLNS.Data.A