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.
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.
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:
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?.
Resources within a message set are created as files, and are displayed in the Navigator view:
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.
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.
There is a generated string of 13 characters that uniquely identifies 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.
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.