Accessing base types in migrated message models

In previous releases, you could optionally give a compound type an associated base type in the message model. This concept is provided in Version 5 by mixed content objects. This topic applies only if you are working with messages that you modeled in a previous release and have imported using mqsimigratemsgsets command. The base type becomes the value (data) associated with the element's underlying complex type when the message set is imported.

If you have imported a message set that includes a compound type that has a defined base type, the migration process creates an additional child element as the first element in the corresponding complex type. The name of the additional element is automatically generated by the migration process. Although this element is displayed in the workbench, you do not need to refer to it in ESQL. You can continue to use the same ESQL statements to refer to the value of the base type, that is the name of the complex element itself.

For example, assume that you defined a compound type in Version 2.1 called CompType1 with a base type of STRING, and with two children Elem1 (STRING) and Elem2 (STRING). You created an element CompElem1 based on compound type CompType1. In ESQL you used the following statement to assign a value to the base type:
SET OutputRoot.MRM.CompElem1 = 'Some text value';

When this part of the message model is migrated to Version 5, a complex type CompType1 is created with three elements: the original two from the Version 2.1 definition plus the additional automatically-generated element that represents the base type. You can continue to use the same statement, shown above, to assign a value to the new element. The output message generated is also identical.

Related concepts
Message flows overview
Message modeling
Related tasks
Designing a message flow
Defining message flow content
Managing ESQL files
Migrating a message set
Related reference
Built-in nodes
ESQL reference