This topic contains sections marked as revised for this release
WebSphere Message Brokers
File: au16661_
Writer: Jane Brockbank Task topic This build: July 31, 2007 21:39:45
Resolving problems when migrating or importing message flows and
message sets
This topic contains advice for dealing
with some common problems that can occur when you import or migrate message
flows and message sets:
Message flows that refer to a migrated user-defined node have connection
errors
Scenario: After migration, all message flows that refer
to a migrated user-defined node have errors indicating that connections cannot
be made.
Explanation: One possible cause is that the original user-defined
node had space characters as part of one or more terminal names. The
spaces are rendered as 'X20' erroneously.
Solution: Edit the user-defined node .msgnode file,
which is available in the same project as the flows that you have migrated.
Correct any terminal names that are at fault. Ensure that the names are exactly
as the broker node implementation expects.
After migration, message flows cannot locate a user-defined node
Scenario: After migration, message flows cannot locate a
user-defined node.
Explanation: One possible cause is that the flows do not
have the correct reference internally to a user-defined node.
Solution: Invoke the Locate subflow pop-up
menu from the node that cannot be located. Using the Browse dialog box, locate
the user-defined node (which is in the same project as migrated flows). The message flow should now link to the user-defined node correctly
and the task list entry is removed when you save the flow.
Comparing an empty XML tag with NULL fails
Scenario: The ESQL module for a node in the message flow
includes a test of a field in an XML message in the XMLNS domain. The
statement tests the field against IS NULL; for example:
IF InputRoot.XMLNS.soap:Envelope.soap:Header.soap:Tag IS NULL THEN ...
This statement returns FALSE, even if the field is empty.
Explanation: In an XML message, all fields are regarded
as character fields and cannot be tested against IS NULL or IS NOT NULL. In Version 5.0, this test returned the
expected result. In Version 6.0, the XMLNS parser
has been corrected to fail the comparison between an empty tag, <Tag></Tag> or <Tag/>,
and NULL.
Solution: Rework your ESQL to compare the field to the empty
string:
IF InputRoot.XMLNS.soap:Envelope.soap:Header.soap:Tag = '' THEN ...
This
comparison returns TRUE if the field has no content.
An exception is thrown when you CAST a CHAR to TIME or TIMESTAMP
Scenario: When you CAST a CHARACTER variable to a TIME or
TIMESTAMP, the operation fails; an exception is thrown, and message BIP2521E
is issued.
Explanation: Version 6.0 applies
stricter rules to the format of character strings that are supplied as input
to the CAST function. The format of the input string must be of
the form hh:mm:ss.SSSSSS or yyyy-MM-dd hh:mm:ss.SSSSSS respectively.
If the character string is not of this format, an exception is thrown.
Version 5.0 accepted any valid separator between
time components. For example, in previous versions an input character string
of yyyy-MM-dd-hh:mm:ss.SSSSSS was acceptable.
Solution: Modify the CAST statement to use a valid CHARACTER
string. For example, your current statement might be of this form:
SET result = CAST(inputChar AS TIMESTAMP);
You
can add the format to the statement:
SET result = CAST(inputDateChar AS TIMESTAMP FORMAT 'yyyy-MM-dd-hh.mm.ss.SSSSSS');
Alternatively,
you can use a function to perform the CAST. Change the SET statement:
SET result = CharToTimeStamp(inputChar);
Create
a schema-level function:
CREATE FUNCTION CharToTimeStamp(inputChar CHAR) RETURNS TIMESTAMP
BEGIN
DECLARE returnTS TIMESTAMP
CAST(inputChar TO TIMESTAMP FORMAT 'yyyy-MM-dd-hh.mm.ss.SSSSSS');
RETURN returnTS;
END;
An exception is thrown when you compare a TIMESTAMP with CHAR '-1'
Scenario: When you compare a TIMESTAMP value, for example
Properties.ExpirationTime, with a CHAR value that starts with the - (minus)
character, the operation fails; an exception is thrown, and message BIP2461E
is issued.
Explanation: When you compare values, implicit CASTs are
performed if the two values are not of the same type. For example,
if you compare the TIMESTAMP field Properties.ExpirationTime with '-1' to
determine if it is not set, Version 6.0 rejects
the comparison and throws an exception.
Version 5.0 incorrectly CAST the CHAR value to a
valid TIMESTAMP; for example:
CAST ('-1' AS GMTTIMESTAMP)
The
result of this CAST was 0000-01-01 00:00:00. The comparison was performed
and no exception was thrown.
Solution: CAST the TIMESTAMP value to CHAR before you perform
the comparison. For example:
IF CAST(InputRoot.Properties.ExpirationTime AS CHAR) = '-1' THEN ....
Deploying a message flow fails with BIP2912E
Scenario: When you deploy a message flow that includes a
node that you have customized with ESQL, the deploy fails with a sequence
of error messages; BIP2087E, BIP4041E, BIP4001E, and BIP2912E.
Explanation: If you defined a RETURNS clause for an ESQL
function, Version 6.0 checks that an expression
is specified on the RETURN statement, and that it matches the type that you
specified in the RETURNS clause (TRUE, FALSE, UNKNOWN). If the RETURN statement
does not match, errors are reported.Version 5.0 does not
fail the deploy if you do not include a value, or if a mismatch exists.
Solution: Modify the RETURN statement in your ESQL code
to match the RETURNS clause. The behavior of the Main function
RETURN statement in each of the different ESQL nodes is shown below.
Node
RETURN TRUE;
RETURN FALSE;
RETURN UNKNOWN (if BOOLEAN type) or RETURN NULL;
RETURN;
Compute
Propagate to Out terminal
Stop propagation
Stop propagation
Deploy failure (BIP2912E: Type mismatch on RETURN)
Database
Propagate to Out terminal
Stop propagation
Stop propagation
Deploy failure (BIP2912E: Type mismatch on RETURN)
Filter
Propagate to True terminal
Propagate to False terminal
Propagate to Unknown terminal
Deploy failure (BIP2912E: Type mismatch on RETURN)
Scenario: When you deploy a message flow that includes a
node that you have customized with ESQL, the deploy fails with a sequence
of error messages; BIP4001E and BIP2912E.
Explanation: An EXISTS statement in an ESQL function specifies
a parameter that is not a list.Version 6.0 checks
that the expression returns a list; Version 5.0 do not fail the deploy if you do not
specify a list. For example:
EXISTS(SELECT * from Environment.Variable.LocalError);
The
statement above is accepted by Version 5.0, but not by Version 6.0,
which checks that the expression returns a list. The expression must be one
of the following types:
A LIST operator
A field reference that includes the array indicator []
A SELECT statement that returns a list
Solution: Modify the EXISTS statement in your ESQL code
to specify a valid expression. For example:
EXISTS(SELECT * from Environment.Variable.LocalError[]);
MRM XML messages include a namespace on the root tag
Scenario: You have migrated your message flow from Version 5.0 and
the MRM XML message that it generates includes a namespace on the root tag.
Explanation: When an MRM message that is defined in a namespace
is generated, the namespace is included in the root tag in Version 6.0. For example, the root tag in the generated message in Version 5.0 might
be:
<claim_std_msg>
In Version 6.0,
if the root tag is in the named namespace, the root tag in the generated message
might be:
Solution: You do not have to make any changes; the output
message is correctly generated.
A TDS message of length zero is written from a fixed length structure
Scenario: You have defined a TDS message with the Data Element Separation property set to Fixed Length. An output message of length
zero is created from the message tree.
Explanation: This problem is encountered when the following
conditions are met:
The MRM-TDS parser is used to create the bit stream from the message tree.
The output message has the Data Element
Separation property set to Fixed
Length.
All elements have properties Min Occurs and Max Occurs set to 0.
Elements with Max Occurs set
to 0 are not visible to the
parser and are therefore not written to the output bit stream.
If these
conditions arose in Version 5.0, the parser wrote the fixed length elements
as self-defining elements, and therefore created an output bit stream, even
though the output did not match the message definition. Version 6.0 does
not generate an invalid bit stream, and therefore the bit stream is of zero
length under these conditions.
Solution: Set the Max Occurs property
to a number greater than 0 for
all elements that you expect to appear in the bit stream. If you
reset Max Occurs but the message
tree contains no corresponding elements, define default values for those elements.
Data patterns in TDS messages are rejected
Scenario: You have defined a TDS message with the Data Element Separation property set to Use Data Pattern. The Message Broker Toolkit has
generated errors against the message definition.
Explanation: Version 6.0 validates
the expressions that you specify in the data patterns.Version 5.0 did
not perform this validation.
Solution: Check all the patterns that have been marked as
invalid, and correct them. A typical cause of an invalid pattern
is that special characters have not been escaped. For example, a pattern might
include [+-] to indicate that a character should be either + or -.
However, you can also use square brackets to indicate a range, such as [0-9],
in which the hyphen character is considered part of the expression. Using
the hyphen to indicate a minus sign is therefore not valid expression syntax.
You must escape the minus character with the escape character backslash to
use it in this way, for example [+\-].
MQRFH2 NameValueData empty tags are written in the short form
Scenario: XML generated from an MQRFH2 header contains empty
tags for NameValueData fields in the form <Tag/>.
Explanation: Version 6.0 generates
the short form of empty XML tags.Version 5.0 generated the long form of empty XML
tags, for example <Tag></Tag>.
Solution: The XML specification indicates that both forms
of the empty tag must be tolerated by XML applications, so the changed behavior
in Version 6.0 is consistent with that specification
and should not cause problems in your XML applications. However,
some JMS applications might be affected by empty tags in the short form; refer
to the documentation for your JMS provider.