There are certain scenarios where the migration of .mfmap files is not supported. This topic explains why migration is not automatic in these situations, and provides instructions for how to complete a successful migration.
The programming model for message maps is different between Version 5.0 (where the file format is .mfmap) and Version 6.0 (where the format is .msgmap). Version 5.0 message maps have a procedural programming model, which is essentially an alternative ESQL, where you describe all the steps that are required to perform a transformation. Version 6.0 uses a declarative programming model, where you describe the result of the transformation, and the tools determine how to achieve that result.
Most migration failures result from message maps that contain too much information about the steps that perform the transformation, and not enough information about the desired result. For these message maps, migration is enabled by changing the .mfmap file so that specific "how to" sections are separated into an ESQL function or procedure that can be called by the message map. The .mfmap file calls the ESQL instead of containing it as an expression. The mqsimigratemfmaps command then migrates the .mfmap file, but calls the ESQL instead of logging a migration error.
A limitation is that ESQL (the run time for .mfmap and .msgmap files) cannot define functions that return complex element (or REFERENCE) values. The following procedure explains how to work around this complex element target limitation; in many cases, it means that the map must be rewritten as ESQL. For more examples and information about calling ESQL from maps, see the WebSphere Message Brokers mapping sample at .
src_msg.e[1] + src_msg.e[2]compute the result in an ESQL function like:
CREATE FUNCTION addOneAndTwo(IN src_msg) BEGIN RETURN src_msg.e[1] + src_msg.e[2]; END;In the .msgmap file, call the ESQL function addOneAndTwo using the parent element src_msg as a parameter.
src_msg.*or
src_msg.*[]can be processed using a function that takes the parent of the repeating field:
CREATE FUNCTION processAny(IN src_msg) BEGIN DECLARE nodeRef REFERENCE TO src_msg.e.*; DECLARE result <dataType> <initialValue>; WHILE LASTMOVE nodeRef DO --expression goes here SET result = result; END WHILE; RETURN RESULT; END;In the .msgmap file, call the ESQL function using the parent element src_msg as a parameter.
src_msg.{'a' || 'b'}can be processed by ESQL functions that process the parent of the repeating field:
CREATE FUNCTION processDynamicName(IN src_msg) BEGIN RETURN src_msg.{'a' || 'b'}; END;In the .msgmap file, call the ESQL function using the parent element src_msg as a parameter.
SELECT MAX("#T".FIRSTNAME) FROM Database.CUSTOMER AS "#T" WHERE "#T".CUSTOMERID = custIdcan be processed by ESQL functions that process the parent of the repeating field:
CREATE FUNCTION processMAX(IN custId) BEGIN RETURN SELECT MAX("#T".FIRSTNAME) FROM Database.CUSTOMER AS "#T" WHERE "#T".CUSTOMERID = custId END;In the .msgmap file, call the ESQL function using the element custId as a parameter.
e || "#I"must be rewritten entirely in ESQL. By definition, there must be a complex repeating parent element, and this is not supported by ESQL functions.
src_msg.e[src_msg.a]must be rewritten using if rows, msgmap:occurrence() functions, and ESQL functions:
for src_msg.e if condition msgmap:occurrence(src_msg/e) = src_msg/a
src_msg.e["#I" +5] src_msg.e[< 3]the entire .mfmap file must be rewritten in ESQL, because the .msgmap files do not yet support indexed access to repeating fields.
src_msg.e IN (1, 2, 3)must be rewritten in ESQL, because .msgmap files do not support ESQL ROW expressions.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ar25255_ |