Extend and tune your flow configuration > Message handler > Set up message-processing actions

Set up message-processing actions

To set up message-processing actions:

From the menu bar click Processing configuration.
At the top of the Processing configuration page, in the navigation graphic, click either of the Message handler icons.

Setting up message actions can be a two-step process:

Define message attributes – Complete this step if you want to use attributes that are not the default attributes.
Define conditions – Select an attribute and assign a value to the attribute to set up a condition for triggering a message action.

Define message attributes

Message attributes are name-value pairs whose values are extracted from messages through parsing or have fixed values. Activator can parse only XML messages, but attributes with fixed values can apply to EDI, XML or binary documents.

For example, you can have the system parse certain XML messages for values of an attribute named POAmount. Or, you can instruct the system to apply an attribute named SupplyChain with a fixed value of Retail to certain messages.

You can define attributes to be active only when certain conditions occur. This lets you customize attributes to a high degree of specificity.

Defining attributes is optional. Attributes you define are in addition to default attributes. The following are the names of default attributes displayed in the user interface. These are not the internal technical names.

Any attributes that display after Virtual file user data have been added in addition to the defaults. One way to add or delete attributes is to select System management > Manage message attributes.

Consumption file name – The name of the message picked up from an integration or delivery transport.
Production file name – The name of the message sent to integration or a partner.
Sender routing ID – The routing ID of the sending party.
Receiver routing ID – The routing ID of the receiving party.
From – The name of the sending party.
To – The name of the receiving party.
Document class – The document class of the message payload (for example, X12, XML).
Content MIME type – The MIME type of the message payload. The following are commonly used types.

application/EDI-consent	Tradacoms messages
application/EDIFACT	EDIFACT messages
application/EDI-X12	X12 messages
application/octet-stream	Binary messages
application/xml	XML messages

For information about other MIME types see: http://www.mhonarc.org/~ehood/MIME/MIME.html.

Document type – For EDI documents this is the business document type, such as 894 (invoice) or 850 (purchase order). For XML documents, the document type has to be parsed from the document.
Business protocol – The message protocol for transporting the message. For example, AS1, AS2, AS3, ebXML.
EDI control ID – For EDI documents, the control ID.
Is receipt – A boolean indicating whether the message is a receipt acknowledging a message has been received. Receipts can trigger message actions unless you set up a condition excluding them. (Note that inbound receipts are processed before reaching the message handler. So Is Receipt is applicable as a message action only for outbound receipts.)
Virtual file user data – A text field that can be set to any arbitrary valid OFTP string value. This attribute provides a way for two endpoints connecting via OFTP to communicate commands, status or other information outside of the protocol specification. The attribute corresponds to the protocol element SFIDUSER sent or received during exchanges. The value is limited to 8 bytes of ASCII text whose semantic is up to the conversing OFTP user applications.

Define conditions

From the pool of available attributes, you select an attribute and also an operator and a value. This serves as the trigger of the action. For example, you could specify that an action triggers when:

Sender ID
(attribute)

equals
(operator)

Community A
(value)

You also can set up an action that compares the value of one attribute to the value of another attribute. For example, suppose you want to reject inbound messages when the sender ID parsed from the payload is not the same as the sender ID in the message protocol envelope. To do this, you could create an attribute named ParsedSenderId whose value is parsed from XML documents. Then you would set up an action to reject messages that meet the following two conditions. Note that the Is Receipt condition is needed to make sure the action applies only to inbound messages, but not outbound receipts.

1.	ParsedSenderId (attribute)	not equal (operator)	Sender routing ID (attribute)
2.	AND Is Receipt = false

You can set up multiple conditions, all of which must be met for an action to trigger.

The following defines operators. Not all of these are available for all attributes.

Exists – The operator tests whether an attribute has any value at all.
Doesn't exist – The operator tests whether an attribute has no value at all.
Equals – The operator tests whether an attribute has a *specific* value. (Meaning that it both exists and has that specific value.)
Not Equal – The operator tests whether an attribute does not match a specific value, meaning that it exists but not with that specific value.
Starts with – The operator tests whether an attribute begins with the specified value. This can be used in wildcard searches. For example, match any string beginning with foo.
Ends with – The operator tests whether an attribute ends with the specified value. This can be used in wildcard searches. For example, find any string ending with foo.
Contains – The operator tests whether an attribute contains the specified value. This can be used in wildcard searches. For example, match any string containing foo.

Note The operators starts with, ends with and contains are available only with these attributes: Consumption file name and Production file name.

In addition to equals and not equal, there are the following related operators whose purpose is self explanatory: greater than, less than, greater than or equal and less than or equal.