This topic contains advice for dealing with some common problems that can occur when you import or migrate message flows and message sets:
InputRoot.XMl.Field1[]
<TestCase> <Folder1>Value1 <Field1>Value2 </Folder1> <Folder2>Value1 <Field1>Value3 </Folder2> </TestCase>
Now consider the following ESQL:
IF InputRoot.XML.TestCase.Folder1 = InputRoot.XML.TestCase.Folder2 THEN SET OutputRoot.XML.Result = 'Same'; ELSE SET OutputRoot.XML.Result = 'Different'; END IF;
When Folder1 and Folder2 are compared, the value of the fields are compared first. In this example, both fields have a value of 'Value1'; therefore, the comparison is successful and it continues. The code navigates to the first child in both Folder1 and Folder2. These fields are now compared for name, type, and value. In both folders, the name 'Field1' is the same, but the child in Folder1 has a value of 'Value2', and the child in Folder2 has a value of 'Value3'. The comparison therefore evaluates to FALSE.
If these fields had compared successfully, the comparison checks recursively through children of this field, and then siblings. Therefore, when message tree fields are compared with this ESQL code, the whole of the subtree has to match in field names, types, and values, and the hierarchy must be identical. If any discrepancy is found, the comparison returns FALSE.
IF FIELDVALUE(InputRoot.XML.TestCase.Folder1) = FIELDVALUE(InputRoot.XML.TestCase.Folder2) THEN SET OutputRoot.XML.Result = 'Same'; ELSE SET OutputRoot.XML.Result = 'Different'; END IF;
This comparison returns TRUE.
SET char = EVAL(FIELDNAME(InputRoot.XML.Testcase));
SET char = EVAL('FIELDNAME(InputRoot.XML.Testcase);');
IF InputRoot.XMLNS.soap:Envelope.soap:Header.soap:Tag IS NULL THEN ...This statement returns FALSE, even if the field is empty.
IF InputRoot.XMLNS.soap:Envelope.soap:Header.soap:Tag = '' THEN ...This comparison returns TRUE if the field has no content.
Version 2.1 and 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.
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;
Version 2.1 and 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.
IF CAST(InputRoot.Properties.ExpirationTime AS CHAR) = '-1' THEN ....
InputRoot.MRM.myField1When migrated to Version 6.0, warnings are generated that identify unresolved references.
If the database definitions already exist in another project, click Project > Properties, select Project References and add the reference to the relevant message flow project.
Some references cannot be resolved; for example if you declare a reference variable, and set it to point to a message tree field, and use the reference variable in place of a correlation name in the ESQL code, validation cannot be performed.
If you do not associate the definitions with your message flow project, or you use reference variables, and you prefer not to see these warnings, you can suppress them in one of the following ways:
DECLARE myRef REFERENCE TO InputRoot.XML.testCase.Field[];This statement is accepted in Version 2.1. However in Version 6.0, you must include an indication of the specific field for the reference.
DECLARE myRef REFERENCE TO InputRoot.XML.testCase.Field[1];or
DECLARE myRef REFERENCE TO InputRoot.XML.testCase.Field;
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) |
EXISTS(SELECT * from Environment.Variable.LocalError);The statement above is accepted by Version 2.1 and 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:
EXISTS(SELECT * from Environment.Variable.LocalError[]);For more information, see the EXISTS function.
MRM - StructureA - SubstructureB - FieldC = 'Value 1'If you compare the field reference InputRoot.MRM.StructureA or InputRoot.MRM.StructureA.SubStructureB against IS NULL, TRUE is returned. In Version 2.1, FALSE was returned.
<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:
<claim:claim_std_msg xmlns:claim="http://lni/orca/claim"></claim:claim_std_msg>
In Version 6.0, insignificant zeros are not maintained, and a value of 161 in a DECIMAL (10,0) field is correctly stored as 161. If you use the DECIMAL to populate the MRM CWF field in this version, the field is padded and justified according to the properties defined for that field.
If these conditions arose in Version 2.1 and 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.
For more information about data patterns and migration, see Message set migration notes.
For more information, see Restrictions for nesting complex types.
In Version 6.0, each thread maintains its own queue cache, and the new default threshold per thread is 240. Therefore an execution group maintains far more open queue handles than in the previous version, particularly if it has started a large number of threads. (The same behavior is also true for Version 5.0, therefore message flows migrated from Version 5.0 are unaffected in this way when you migrate them.)
mqsichangeproperties broker -e execgroup -o ComIbmMQConnectionManager -n queueCacheMaxSize -v new_value
You
cannot set a value less than 10; if you do, the value reverts back to the
default value 240. The new value is used for each thread in the execution
group (not for the execution group itself).If you change the value with the mqsichangeproperties command, you must stop and restart the broker for the new value to take effect.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
au16661_ |