WebSphere Message Brokers
File: ad09250_
Writer: Terry Cowling

Reference topic

This build: July 31, 2007 21:23:06

Message set properties

Message sets have properties that you can set to define their characteristics and the way in which they are processed.

General message set properties

The table below defines the properties that you can set to customize the message set.

Property Type Meaning
Message Domain String Select, from the drop-down list, the message parser for messages that belong to this set. Use the message parser name when you write ESQL field references for messages in the message set; for example, InputRoot.MRM.Document. The Mapping editor and the content assist feature of the ESQL editor use the message parser name when they generate ESQL field references. The message parser name must match the Message Domain property of any input node that processes messages from the message set, or the <Msd> element value of any MQRFH2 header that precedes a message from the message set.
You can choose from the following names:
  • Start of changeXMLNSC (the default if you select Finish from page two of the New Message Set wizard. Choose this parser if you want to model namespace aware XML messages. You do not have to deploy these message sets to brokers, because this parser does not use a runtime dictionary.End of change
  • Start of changeMRM. Choose this parser for binary, text, or XML messages. You must deploy the message set to the brokers that receive these messages. The deploy action creates a runtime dictionary (RTD), against which the MRM parser that is invoked by the broker, checks the received message.End of change
  • XMLNS. Choose this parser if you want to model namespace aware XML messages. You do not have to deploy these message sets to brokers, because this parser does not use a runtime dictionary.
  • IDOC. Choose this parser if you want to model SAP IDoc messages. If your message set contains user-defined IDoc segments, you must deploy the message set to the brokers that receive these messages. The deploy action creates a runtime dictionary (RTD), against which the MRM parser that is invoked by the broker, checks the received message.
  • MIME. Choose this parser if you want to model a MIME message. Messages that are defined in this way are interpreted by the MIME parser, not by the MRM parser. (You do not have to deploy these message sets to brokers, because this parser does not use a runtime dictionary.)
  • JMSMap. Choose this parser if you want to model a JMS MapMessage message. You do not have to deploy these message sets to brokers, because this parser does not use a runtime dictionary.
  • JMSStream. Choose this parser if you want to model a JMS StreamMessage message. You do not have to deploy these message sets to brokers, because this parser does not use a runtime dictionary.
  • XML, . Choose this parser if you want to model a generic self-defining XML messages. Messages that are defined in this way are interpreted by the generic XML parser, not by the MRM parser. You do not have to deploy these message sets to brokers, because this parser does not use a runtime dictionary. The XML parser is supported for compatibility with Version 2.
Start of changeDefault Wire FormatEnd of change Start of changeStringEnd of change Start of changeSpecify the default wire format used, only if you select MRM, IDOC or a custom domain as the default message domain, or either of MRM or IDOC is selected in the list of supported message domains. The default value is <no default specified>.

If you do not select any of the preceding options, the Default Wire Format format is unavailable.

End of change
Message Set ID String This property is a unique identifier that is automatically generated for you when you create the message set. You cannot change this property.
Message Set Alias String Specify an alternative unique value that identifies the message set. This property is only required if you are using the Message Identity technique to identify embedded messages. Using this technique, the embedded messages are defined in this message set but the parent message is defined in a different message set, and the bit stream does not contain the actual message set name or identifier.
Message Type Prefix String This property is used when you define multipart messages, specifically when using the Message Path technique to identify embedded messages.

The value that you specify is used as an absolute or relative path to the innermost message from the outermost, and is used as a prefix to the value of the Message Type property that is specified for the outermost message (specified either in the MQRFH2 header of the message, or in the input node of the message flow).

If you set a value, it must be in the form id1/id2/.../idnu where id1 is the identifier of the outermost message, id2 is the identifier of the next element or message, and idn is the identifier of the innermost message. The default value is blank (not set).

The table below, describing the use of the message set property Message Type Prefix, shows how this value is combined with the Message Type property of an input message.

Use namespaces Check box Select this property if you want to use namespaces within the message set. Namespaces provide a method of avoiding naming conflicts where different document definitions have elements of the same name. For further information see Namespaces.

By default, this check box is selected.

Using namespaces affects how elements are created in the logical message tree. Each element in the message tree has both a name and a namespace, so an ESQL or Java reference to one of these elements has to specify both name and namespace. Therefore, using namespaces has an effect on the ESQL or the Java that you write.

Select this property if you want to use the message set in the future to model XML messages.

Broker will treat Length facet as MaxLength Check box Select this property if you want the COBOL importer to create a maxLength facet, rather than a length facet, for a fixed length string element.

By default, this check box is selected.

Use of the message set property Message Type Prefix

The table below shows the implications of using the property Message Type Prefix. The message type or message prefix can describe either elements or messages.

Message Type property example Message Type Prefix not set Message Type Prefix set
Simple Message Type:msg_type Results in the simple Message Type:msg_type Results in the path Message Type: /msg_prefix_1/.../msg_prefix_n/ msg_type
Path Message Type:msg_type_1/.../msg_type_m Results in the path Message Type:/msg_type_1/.../msg_type_m Results in the combined path Message Type: /msg_prefix_1.../msg_prefix_n /msg_type_1/.../msg_type_m
Simple absolute Message Type:/msg_type Results in the simple Message Type:msg_type Results in the simple Message Type:msg_type

An error is raised if Message Type Prefix is set to any value other than msg_type.

Path absolute Message Type:/msg_type_1/.../msg_type_m Results in the path Message Type:/msg_type_1/.../msg_type_m Results in the path Message Type:/msg_type_1/.../msg_type_m

An error is raised if all identifiers in Message Type Prefix do not match the corresponding identifiers in the resulting path.

The message set does not have any properties that are dictated by membership of a larger object, because it is the largest message object that can be defined by the MRM.

In addition to message set properties, you can update properties that are specific to each of the physical formats. Links to reference topics that describe these properties are given below.

Related concepts
Multipart messages
Identifying an embedded message using a Message Identity
Identifying an embedded message using a Message Path
Message set projects
Message sets overview
Physical formats in the MRM domain
Namespaces in the message model
Related tasks
Working with a message set project
Working with a message set
Related reference
Custom Wire Format message set properties
XML Wire Format message set properties
TDS Format message set properties
Documentation properties for all message set objects
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:23:06

ad09250_ This topic's URL is: