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 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.

Select, from the dropdown 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.

You can choose from the following names:
  • (the default if you select Finish from page two of the New Message Set wizard). Choose this domain if you want to model XML messages. You can deploy the message set to brokers if you want, because the XMLNSC parser optionally uses the message set at run time.
  • MRM (the default). Choose this domain 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 against which the MRM parser checks the received message.
  • XMLNSC. 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.
  • XMLNS. You might need to choose this domain for some kinds of XML messages. You do not have to deploy the message set to brokers, because the XMLNS parser does not use the message set at run time.
  • 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.
  • JMSMap. Choose this domain if you want to model a JMS MapMessage message. You do not have to deploy the message set to brokers, because this parser does not use the message set at run time.
  • JMSStream. Choose this domain if you want to model a JMS StreamMessage message. You do not have to deploy the message set to brokers, because this parser does not use the message set at run time.
  • MIME. Choose this domain if you want to model a MIME message. You do not have to deploy the message set to brokers, because the MIME parser does not use the message set at run time.
  • 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.
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.

Always select this property if you want to use the message set to model XML messages.

MRM domain

Property Type Meaning
Default wire format String Specify the default wire format that is used if a format cannot be deduced from the message's MQRFH2 header, or was not specified as a property of the input node at which the message is received by a message flow. The default value is <no default specified>.
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.

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 type prefix property

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.

If you are using MRM or IDOC domains, in addition to the main message set properties, you can update message set properties that are specific to each of the physical formats. Links to reference topics that describe these properties are given below.

Related concepts
Parsers
MRM parser and domain
XML parsers and domains
Which message domain and format to use?
JMS parsers and domains
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
Accessing embedded messages in the MRM domain
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, 2009Copyright IBM Corporation 1999, 2009.
Last updated : 2009-01-07 15:20:55

ad09250_