Enterprise Integration Patterns - Message Filter

Overview

A Message Filter is a special form of a Content-Based Router. It examines the message content and passes the message to a service only if the message content matches certain criteria, otherwise the message is discarded.

Use Cases

Selective Processing

If a consumer wishes to receive only messages whose content satisfy a given criteria, a message filter can be inserted on the message path to filter out unwanted messages. The consumer can focus on processing the requests it expects and does not have the overhead of processing each incoming message and discarding those it is not interested in processing

Message Filtering

Messages with sensitive/private content can be hidden from services which should not be receiving them by inserting a message filter, on the path to these services, which filters out the sensitive messages.

IFL

Syntax

filter [type] [name | expression]
type := filter implementation (xpath, regex)
name := named configuration which contains the filter details
expression := inline filter configuration

Examples

Xpath filter with inline configuration

ftp "foo"
jruby "verify-address"

route do
    from "foo"
    filter xpath ("//orders/order")
    to "verify-address"
end

Xpath filter with external configuration

ftp "foo"
jruby "verify-address"

route do
    from "foo"
    filter xpath "ordersOnlyConfig"
    to "verify-address"
end

$ cat ordersOnlyConfig/flow.properties 
exp=//orders/order

In both the examples above only those messages which match the xpath expression will be allowed to continue.

Configuration

The configuration for the Message Filter can be inline or external. In the later case, the external configuration file is generate in the "Generate Artifacts" step, the application developer can then update the configuration.

The directory layout for generated configuration is:

app-root/
    filter/
      {name}/
          flow.properties

Where '{name}' is the named of the configuration, if the user has specified a named configuration, then name is the external configuration name. If the configuration is inline, after the generate and build step it is externalized and packaged in the configuration file "flow.properties", the name in this case is a system generated name, which is never exposed to the developer. As far as the developer is concerned in his/her view the configuration is always inline.

XPath

The XPath filter type provides a simple facility for filtering XML messages.

Input Message

<orders>
   <order>
      <item>bang001</item>
      <desc>guns</desc>
      <amount>50</amount>
   </order>
   <order>
      <item>parkayXYZ</item>
      <desc>butter</desc>
      <amount>100</amount>
   </order>
</orders>

XPath Configuration

//orders/order

Output Message

<orders>
   <order>
      <item>bang001</item>
      <desc>guns</desc>
      <amount>50</amount>
   </order>
   <order>
      <item>parkayXYZ</item>
      <desc>butter</desc>
      <amount>100</amount>
   </order>
</orders>

Regex

The regex (regular expression) filter type is useful for non-XML data. The user provides a regular expression as the configuration for the filter, if the message content matches the regular expression, it continues in the route, otherwise it is discarded. Input Message

ORDER|PO123
ITEM|bang001|guns|50
ITEM|parkayXYZ|butter|200
ORDER|PO456
ITEM|oopsABC|huggies|300

Regex Configuration

"ORDER"

Output Message

ORDER|PO123
ITEM|bang001|guns|50
ITEM|parkayXYZ|butter|200
ORDER|PO456
ITEM|oopsABC|huggies|300

Header

The Header filter type provides a simple facility for filtering Messages based on values/properties contained in the MessageExchange or NormalizedMessage.

Option	Description
me.property	Returns the value of the named property in a MessageExchange, if it exists
me.operation	Returns the value of MessageExchange.getOperation(). * can be used to just extract the value
me.interface	Returns the value of MessageExchange.getInterfaceName(). * can be used to just extract the value.
nm,property	Returns the value of the named property in a NormalizedMessage, if it exists
nm.attachment	Return the value of DataContentHandler.getContentType() for the named attachment, if it exists
exp	Regex expression that can be applied to the result of one of the above

Examples

filter header ("me.property=my.exchange.property")
filter header ("nm,property=my.message.property")

Returns true if the named property exists.

filter header ("me.operation={ns:abc}opA")
filter header ("me.interface={ns:def}interA")

Returns true if operation/interface matches given value

filter header ("nm.attachment=TextAttachment")

Returns true if named attachment is found

Examples with Regex

filter header ("me.property=my.exchange.property,exp=A value")

Returns true if the name property exists and has the given value.

filter header ("me.operation=*,exp={.*}AnOperation")

Returns true if the operation name is AnOperation independent of the namespace.

filter header ("me.attachment=MyAttachment,exp=text/xml")

Returns true if the named attachments content type is text/xml

Runtime

This page (revision-11) was last changed on 21-Jul-09 09:32 AM, -0700 by DerekFrankforth.
This page was created on 21-Oct-08 14:21 PM, -0700 by KeithBabo.

More info...