Index Changes

Difference between version and version     

Back to Fuji EIP Message Filter, or Fuji EIP Message Filter Info


At line 4 added 184 lines.
!!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.
\\
[{Image src='FujiEIPMessageFilter/filter.jpg' width='40%' align='center'}]
!!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