Index Changes
Fuji Home

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

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-11) was last changed on 21-Jul-09 09:32 AM, -0700 by DerekFrankforth