Resolving problems when developing message models

This topic contains advice for dealing with some common problems that can arise when working with message sets.

About this task

Message definition files:
Other:

Your message definition file does not open

Procedure

  • Scenario: You have created a complex type with a base type that causes the types to be recursive, and now your message definition file does not open.
  • Solution: Recover the last saved version of your message definition file from the local history or from your repository.

A message definition file error is written to the task list

Procedure

  • Scenario: An error is written to the task list indicating that the message definition file has been corrupted.
  • Explanation: This error message appears when the base type of the complex type is itself, or a circular definition of two or more simple types. This type of recursion is not supported.
  • Solution: Examine your code and ensure that the type of recursion described above does not occur.

Your physical format property values have reverted to defaults

Procedure

  • Scenario: Someone has sent you a message definition file. You have added it to a message set project, but all the physical format property values have reverted to defaults.
  • Explanation: You cannot transfer message definition files on their own in this way because these files are not entirely independent.
    It is the messageSet.mset file that lists all the physical formats that are applicable to a message set.
    For example, if you have a message set A with CWF format Binary1, and a message set B without any physical formats, a message definition file copied from A to B does not show Binary1 as a known physical format (although the properties are still in the message definition file).
  • Solution: If possible, request the entire message set project.

    Alternatively, add physical formats to the receiving message set so that they match the originating message set. Then any dormant properties become visible. However, make sure that the message set level physical format properties match, or those object properties that inherit defaults from the message set level will be incorrect.

You are unable to enter text in the Message Definition editors

Procedure

  • Scenario: You are unable to enter text in the Message Definition Overview editor, or change the text of an enumeration or pattern facet in the Message Definition Properties editor.
  • Solution: The Message Definition editors are cell editors, and to enable them you have to double-click the cell.
    The first click selects the cell; the second click puts the cell into active state, allowing you to edit it.

Objects in your message definition file are not listed in alphabetic order

Procedure

  • Scenario: The objects in your message definition file (.mxsd) are listed in the order that you created them, but you want them to be in alphabetic order.
  • Solution:
    1. In the Integration Development perspective, double-click the message definition file to open it in the Outline view.
    2. Click az (at the top of the Outline view).
    This action changes the order of objects within each of the message definition file's folders (the Messages, Types, Groups, Elements, and Attributes folders) to be alphabetic.

Error messages are written to the task list after you have imported related XML Schema files

Procedure

  • Scenario: When you have finished importing a collection of related XML Schema files, you find that the IBM® Integration Toolkit task list contains error messages for the message set project, indicating that referenced types or other objects cannot be found.
  • Explanation: These errors are typically an indication that one message definition file includes or imports another message definition file, but that the Message Definition editor is unable to resolve the specified link.
  • Solution:
    • Check that a message definition file exists in the IBM Integration Toolkit for each of the related XML Schema files that you are importing. If the new message definition files have been created, they appear in the Application Development view.
    • Using the Properties Hierarchy in the Message Definition editor, check that any message definition files that include or import other message definition files are correctly locating the target files.

    One common scenario is where you have two XML Schema files X and Y, which both exist in the same directory in the file system but where X, which includes Y, is defined with a real target namespace, while Y is defined in the notarget namespace. After you import the two files, X is placed into the location that is determined by its namespace, but Y is placed into the default namespace location used for files defined in the notarget namespace. This situation causes the link between the two files to break, and you must modify X so that it correctly includes Y in its new relative location.

A group contains two different elements with the same XML name in the same namespace

Procedure

  • Scenario: A warning is written to the task list because a group contains two different elements that have the same XML element name, in the same namespace.
  • Explanation: When a message that has an XML physical format is validated, the validation includes a test to identify any part of a message definition where the parser might not be able to uniquely determine which element is represented by the XML name.
    This test generates a warning when a group contains two different XML elements with the same element name in the same namespace, even in cases where the duplication is legitimate.
  • Solution: Determine whether the duplication that is identified in the warning message is in fact a problem that needs to be corrected, or whether it has arisen because of two elements on opposite sides of a choice sharing the same XML name, in which case the duplication is legitimate because no ambiguity can occur.

You are unable to set up a message definition file to include a message definition file within another message definition file

Procedure

  • Scenario: You are unable to set up the include property of a message definition file to include a second message definition file that is included within another message definition file.
  • Explanation: A message definition file can reference objects in another message definition file only if the first file references the second file directly.
    For example, if three message definition files exist, A, B and C, where A includes B and B includes C, A can reference objects in B, and B can reference objects in C, but A cannot reference objects in C.

    You might also encounter this problem after importing XML Schema files that have nested includes.

  • Solution: You can work around this problem by including the message definition file directly, which, in the above example, would mean including C directly in A.
    Alternatively, you can define all the message set definitions that are in C directly in B, then delete C so that A needs to include only B.

You want to make the Properties tab the default tab in the Message Definition editor

Procedure

  • Scenario: When using the Message Definition editor to edit your message definition files, you prefer to use the Properties tab rather than the Overview tab, but the Overview tab is always selected as the default.
  • Solution: Use the IBM Integration Toolkit preferences to choose the Properties tab as the default tab:
    1. From the menu, click Windows > Preferences.
    2. Expand Integration Development, then Message Set.
    3. Expand Editors and select Tab Extensions.
    4. In the Message Definition Editor section, select the Properties and the Overview check boxes.
    5. Click OK.

Error message BIP5410 is issued because a union type cannot be resolved

Procedure

  • Scenario: Error message BIP5410 is raised indicating that an element or attribute is based on a union type and that the element or attribute could not be cast to any member of the union.
  • Explanation: When parsing an element or attribute that is based on a union type, the MRM XML parser uses an xsi:type attribute, where present, to resolve the union.

    If an xsi:type attribute is not present, or an attribute is being parsed, the parser tries each union member type in turn, attempting to cast to the associated simple type, until the cast succeeds. The order of precedence for the attempted cast is the order in which the member types are listed in the message model, under the union type, in the Outline view.

    If the data cannot be cast to any of the simple types within the union, the union cannot be resolved and a parser error is reported.

  • Solution: Perform the following checks:
    • Check that the message contains a valid value for the element or attribute that is identified in the error message.
    • Check that the member types of the union that are identified in the error message contain the correct list of simple types.
    • If possible, use an xsi:type attribute to resolve the union explicitly.

Error message BIP5395 is issued because an xsi:type attribute value does not correspond to a valid member type of the union

Procedure

  • Scenario: Error message BIP5395 is issued, indicating that an element is based on a union type that has an xsi:type attribute with a value that should resolve the union explicitly to one of its modeled member types and that the xsi:type attribute value does not correspond to a valid member type of the union.
  • Explanation: When parsing or writing an element or attribute that is based on a union type, the MRM XML parser or writer uses an xsi:type attribute, where present, to resolve the union.
    The parser resolves the value of the xsi:type attribute to a simple type in the dictionary and checks that the simple type is a valid member type of the union.

    If the xsi:type attribute identifies a type that is not a member type of the union, it reports an error.

  • Solution: Perform one of the following steps:
    • Modify the message so that the xsi:type attribute identifies a valid member type of the union.
    • Check that the member types of the union identified in the error message contain the correct list of simple types.

Error message BIP5396 is issued because a data type does not correspond to any of the valid data types of the union

Procedure

  • Scenario: Error message BIP5396 is issued, indicating that an element or attribute is based on a union type but the data type does not correspond to any of the valid data types in the union.
  • Explanation: When writing an element or attribute that is based on a union type, the MRM XML writer uses an xsi:type attribute, where present, to resolve the union.
    If an xsi:type attribute is not present, the writer tries to match the data type of the literal value in the tree to a simple type in the union. If the literal value cannot be matched to any of the simple types in the union, it reports a writing error.
  • Solution: Perform one of the following steps:
    • Check that the message or ESQL contains a valid value for the element or attribute.
    • Check that the union type on which the element is based contains the correct list of simple types.
    • Consider using an xsi:type attribute to resolve the union explicitly.
    • Consider changing the type of the element in the tree to correspond with one of the union member types.

A union type contains two or more simple types that are derived from the same fundamental type

Procedure

  • Scenario: A warning is issued during logical validation indicating that a union type contains two or more simple types that are derived from the same fundamental type.
  • Explanation: The integration node does not apply value constraints until the data is in the logical tree. Therefore, it is not possible to choose between two simple types that are derived from the same fundamental type but with different constraints. For example, the integration node cannot differentiate between a member type of integer with a range of 1-10 and another member type of integer with a range of 11-20, therefore it resolves the union to the first member type of integer.
  • Solution: Ensure that the union type that is identified in the warning does not contain more than one simple type that is derived from the same fundamental type or ensure that the ordering of such member types is as desired.

A list type is based on a union that also contains a list type

Procedure

  • Scenario: An error message is issued during logical validation, indicating that a list type is based on a union type that includes a list type as one of its member types.
  • Explanation: Lists of lists are not legal. An item type of a list type cannot be a list type itself nor can it be derived at any level from another list type. Therefore, a list type cannot have an item type of a union type that includes a list type as one of its member types.
  • Solution: Ensure that any union type specified as an item type for a list type does not include a list type as one of its member types.

A union type contains an enumeration or pattern facet

Procedure

  • Scenario: An error message is raised during logical validation, indicating that a union type contains an enumeration or pattern facet that is not supported because enumeration and pattern facets must be specified directly on the member type.
  • Explanation: The integration node cannot support the union type facets of pattern and enumeration applied directly to a restriction of a union type. It can support facets directly on the chosen member type only. The Message Definition editor provides support for these facets to enable the import of schemas using direct facets on a restriction of a union type but it issues a warning notifying that they will be ignored by the integration node.
  • Solution: If you want to use the enumeration or pattern facets, specify them directly on the member type and not on the union type itself.

Error message BIP5505 is issued because input data is not valid for the data type

Procedure

  • Scenario: A data conversion fails while a message is being read or written. Error message BIP5505 is issued, indicating that the input data was not valid for the data type.
  • Solution:
    Perform the following checks:
    • Ensure that the bit stream is correctly aligned to the model. If the incoming message is not consistent with the model, the wrong bytes are allocated to fields, and the data presented to a field is unlikely to contain valid data for the logical type.
    • Ensure that the correct encoding and CodedCharSetId are applied to the body of the input message. If the wrong encoding is used, the input message bit stream is subject to byte swapping and changes to the byte order. This change can affect the nature of data that applies to a field and make it unusable.
    • Ensure that an appropriate WebSphere® MQ format is applied to the body of the input message. For example, if MQSTR is applied to a bit stream that contains numeric data, character conversions, rather than encodings, are used to translate the bytes. This use can change the meaning of bytes and make them not valid for the logical data type. If character conversions are used with negative external decimals, consider using the EBCDIC custom option.
    • If the error is on a numeric field, ensure that the input data is compatible with the physical format settings. For example, if the field is signed, ensure that a valid sign byte has been passed in, that it corresponds to the orientation of the sign, and that it is included or excluded as appropriate.
    • If the input message is found not to be compatible with the MRM message definitions, check the message at the source. If it is sent over channels, check that the conversion settings on the channels are correct.

A deprecation error is issued on an imported .mrp file

Procedure

  • Scenario: You have imported an .mrp file, and get an error message indicating that complex elements or embedded simple types are deprecated.
  • Explanation: Complex elements and embedded simple types have no exact equivalent in XML Schema. The closest equivalent to a complex type in XML Schema is to derive a complex type from a simple type. However, such a type is not allowed to contain elements; only attributes are allowed.
  • Solution: If your complex type contains elements that cannot be modeled as attributes, set the Mixed content flag on the complex type. If you need to parse messages that contain mixed content, set the Mixed content flag on the parent complex type. The anonymous data that used to be modeled by the complex type or the embedded simple type, then appears as a self-defining node in the parsed message tree.

User trace detects an element length error

Procedure

  • Scenario: You have defined an MRM message and when you execute the message flow, an error message is written to the user trace indicating that the length of an element is invalid.
  • Explanation: You have added an element of type string to the complex type making up the message, but you have not defined the length of the string in the instance of the element in its type.
  • Solution:
    1. Open the message definition file in the Message Definition editor.
    2. In the Outline view, expand the appropriate complex type, then click the element to display its properties in the editor area.
    3. In the Properties Hierarchy, make sure that the element is selected within the CWF physical format under Physical Properties.
    4. Specify the properties that this element will have when it is part of the complex type; for example, in the above case, make sure that the Length Count value is set.
    5. Save any changes in the Message Definition editor and redeploy the message.

MRM dateTime value has changed after it has been parsed

Procedure

  • Scenario: You have defined an MRM dateTime element but the value created in the message tree is different from the value that you defined.
  • Explanation: The parser uses lenient dateTime checking, converting out-of-band data values to the appropriate in-band value.
  • Solution: See the information about lenient dateTime checking in Message Sets: DateTime as string data with particular reference to how years and fractional seconds are represented.