Message sets

A message set is a container for grouping messages and associated message resources (elements, types, groups).

A message set is represented by a messageSet.sfmset file. The message set file is shown in the Navigator view under a project resource that contains message definitions.

The primary editor for modifying a message set is the flow message set editor (see Flow message set editor).

In the following example, you can see a representation of a message set named NCDPLS.Messages that contains a message set file (messageSet.sfmset) and two message files (input_NCDPLS.sfmxsd and ncdpl_rd.sfmxsd). The NCDPLS.Messages subproject is a project resource that stores the message set and associated message files. The subproject corresponds to a message set project.

Figure 1. NCDDPLS.Messages
NCDPLS.Messages
   Schema
      input_NCDPLS.sfmxsd
      messageSet.sfmset
      ncdpl_rd.sfmxsd
   .project

The service flow project tools create a message set automatically when the interface definition subproject, nonterminal applications subproject, terminal applications subproject, or outbound web services subproject is created.

A message set contains two key properties:

  • Runtime Parser

    The message domain of the message set. This is used when parsing and writing all messages defined within that message set and effectively defines the message domain. See Which message domain and format to use?.

  • Use Namespaces
    Indicates whether the message definitions you create within the message set are XML namespace aware. See Namespaces.
    Note: This parameter is required and is enabled by default for all subprojects that contain messages.

Message set resources

Resources within a message set are created as files, and are displayed in the Navigator view:

  • Message set file messageSet.sfmset

    There is always one, and only one, messageSet.sfmset file in a message set. It contains message model properties that are common to all the content of the message set. It is also where you define the physical formats that you want for this message set. These can be Custom Wire Format (CWF), XML Wire Format (XML) and Tagged Delimited String Format (TDS).

    The file is created for you when a new message set is created, and you manipulate its content with the flow message set editor.

  • Message files (also called message definition files) that have the suffix .sfmxsd

    You can have many message files in a message set. Each file contains the logical model and associated physical model in XML Schema form for a group of related messages. See Message files.

Message set identification

There is a generated string of 13 characters that uniquely identifies the message set.

Message set recommendations

You can have as many message files as you want within one message set. But you are recommended to limit your message sets to a few related message files that share the same physical formats. There are several reasons for this:
  • Generation of a message dictionary and other representations is quicker.
  • Generated documentation is more manageable.
  • Physical formats apply to all objects within the message set.

    So for example, if you have an XML message and an unrelated CWF message in the same message set, then both XML and CWF physical format properties will be present for all objects. But the XML properties are of no interest to the CWF message and so will take default values in that message. (Similarly, the CWF properties are not of interest to the XML message.) This can result in unwanted task list warnings.

  • Recursion is only permitted for the XML physical format, not for CWF and TDS.

    So if you are modeling XML messages that have a recursive structure, you must ensure that recursive XML messages do not share a message set with non-XML physical formats.