This topic contains sections marked as revised for this release
In certain scenarios, the migration of .mfmap files is not fully supported.
This topic explains why migration is not automatic in these situations, and provides instructions for how to complete a successful migration. This topic also provides information about problems migrating submaps.
The programming model for message maps is different between Version 5.0 (where the file format is .mfmap) and Version 6.1 (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.1 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.
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 .msgmap file must be rewritten in ESQL, because the .msgmap files do not 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.
For Version 6.1, reusable schema structures must be defined as global elements and types. If you have Version 5.0 submaps that use local elements, you must change the schema to add definitions of global elements for the local elements, and then use the new schema after migration. If the new global elements have the same name and type as the local elements, then the Version 5.0 submaps do not need to be changed.
A local element in a Version 5.0 submap must be qualified with a namespace in order to be successfully migrated to Version 6.1, because the global element that replaces the it on migration must be qualified by the namespace. If your submap contains local elements, then you must re-create the submap and re-create the call to the submap from the main message map.
Version | Supported feature |
---|---|
Version 5.0 | global elements and global attributes as map source |
global elements and global attributes as map target | |
local elements and local attributes as map source | |
local elements and local attributes as map target | |
Version 6.1 | global elements, global attributes and global types as map source |
global elements and global attributes as map target |