WPS: Mediation Routing Primitive : Type Filter

Type Filter mediation primitive : Conditionally route a message based on the message type, by comparing the message against a list of user defined xpaths and types.

The Type Filter mediation primitive uses XPath expressions to allow you to direct messages down different paths of a flow, based on their type.

The Type Filter mediation primitive has one input terminal (in), one fail terminal (fail), and multiple output terminals, (one of which is the default terminal). The in terminal is wired to accept a message and the other terminals are wired to propagate a message.

Each of the output terminals, apart from the default terminal, is associated with an XPath expression and a type. The elements of the message identified by the XPath expressions are compared, in turn, with the associated type. The primitive always uses the first matching output terminal. The default terminal is used if the message meets none of the conditions.

If an exception occurs during the filtering, the fail terminal propagates the original message, together with any exception information.

Usage:

You can use the Type Filter mediation primitive to check that the inbound message has elements of a specific type. If the criterion is not met you can raise a fault using the Fail mediation primitive, or send an error response.

Type Filter Properties:

Filters :
    A list of XPaths, types, and associated terminal names, that define the filtering performed by the mediation primitive.
    Note: Order is significant in the list of expressions. Expressions are evaluated in the order they appear in the table.
XPath element :
        An XPath 1.0 expression against which the message is tested. The expression is evaluated starting from the XPath expression /, which refers to the complete SMO.
Type :
        The qualified type to be matched.
Terminal name :
        The name of an output terminal. There is one terminal name for each pattern XPath type pair. The terminal name must be a valid connection endpoint, and it must not be fail or default. The default value is empty, which is invalid.

NOTE:
The Type Filter primitive matches on either the exact type of an element or its derived types. For example, if you try to match against xsd:int but the actual element is of type xsd:short, it will still match.

WPS: Mediation Routing Primitive : Message Filter

Message Filter : Routes messages down different paths, based on the message content.

• The Message Filter mediation primitive uses XPath expressions to allow you to direct messages, which meet certain criteria, down different paths of a flow. 
• The Message Filter mediation primitive has one input terminal (in), one fail terminal (fail), and multiple output terminals, (one of which is the default terminal). The in terminal is wired to accept a message and the other terminals are wired to propagate a message. 
• Each of the output terminals, apart from the default terminal, is associated with a simple, conditional expression. The contents of the input messageare compared with each expression in turn and, if the condition is met, the messageis propagated to the associated output terminal. The primitive can be configured either to use the first matching output terminal, or all matching output terminals. The default terminal is used if the messagemeets none of the conditions. 
• If an exception occurs during the filtering, the fail terminal propagates the original message, together with any exception information.

Usage of Message Filter:

You can use the Message Filter mediation primitive to check that the inbound message meets some criterion. For example, that a required field is set. If the criterion is not met you can raise a fault using the Fail mediation primitive, or send an error response.

The Message Filter mediation primitive lets different messages take different paths. For example, a message might need forwarding to different service providers based on the request details.

You can use the Message Filter mediation primitive to bypass unnecessary steps. You can test if certain data is in a message, and only perform a Database Lookup operation if the data is missing.

When used in combination with a Database Lookup primitive, the Message Filter can direct messages based on the contents of an independently administered lookup table. For example, you could route a message based on customer status even if the inbound message contained only the customer identifier.

By configuring the primitive to propagate messages to all matching terminals, you can trigger multiple events each requiring different conditions. For example, you could log requests relating to a particular account identifier and send requests relating to a particular product to be audited.

Properties of Message Filter:

Enabled :
    Defines whether the message is mediated by the Message Filter mediation primitive. By default the mediate action of the Message Filter mediation primitive is enabled. You can suspend the mediate action by clearing the checkbox. If you suspend the mediation, the message goes to the default terminal.

Filters :
    A list of expressions, and associated terminal names, that define the filtering performed by the mediation primitive.
    Note: Order is significant in the list of expressions. Expressions are evaluated in the order they appear in the table.

Pattern :
        An XPath 1.0 expression against which the message is tested. The expression is evaluated starting from the XPath expression /, which refers to the complete SMO.

Terminal name :
        The name of an output terminal. There is one terminal name for each pattern XPath expression. The terminal name must be a valid connection endpoint, and it must not be fail or default. The default value is empty, which is invalid.

Distribution mode :
    Determines the behavior of the mediation primitive when an inbound message matches multiple expressions. If the Distribution mode is set to First, the message is propagated to the first matching output terminal. If the Distribution mode is set to All, the message is propagated to all matching output terminals. If there is no matching output terminal, the default terminal is invoked.

WPS: Mediation flow and it's Primitives

Mediation services can inspect, modify, augment and transform a message as it flows from requestor to provider.

The heart of a mediation module is the mediation flow component, which provides the mediation logic applied to a message as it flows from a service consumer to a provider. The mediation flow component is a type of SCA component that is typically used, but not limited to a mediation module. A mediation flow component contains a source interface and target references similar to other SCA components. The source interface is described using WSDL interface and must match the WSDL definition of the export to which it is wired. The target references are described using WSDL and must match the WSDL definitions of the imports or Java components to which they are wired. The mediation flow component handles most of the ESB functions including:

• Message filtering which is the capability to filter messages based on the content of the incoming message.
• Dynamic routing and selection of service provider, which is the capability to route incoming messages to the appropriate target at runtime based on predefined policies and rules.
• Message transformation, which is the capability to transform messages between source and target interfaces. This transformation can be defined using XSL stylesheets or business object maps.
• Message manipulation/enrichment, which is the capability to manipulate or enrich incoming message fields before they are sent to the target. This capability also allows you to do database lookups as needed.
• If the previous functionalities do not fit your requirements, you have the capability of defining a custom mediation behavior in JAVA.

Mediation primitives

What are the various mediation primitives available in WESB?
Mediation primitives are the core building blocks used to process the request and response messages in a mediation flow.

• Built-in primitives, which perform some predefined function that is configurable through the use of properties.
• Custom mediation primitives, which allow you to implement the function in Java.
• Mediation primitives have input and output terminals, through which the message flows. Almost all primitives have only one input terminal, but multiple input terminals are possible for custom mediation primitives.
• Primitives can have zero, one, or more output terminals.
• There is also a special terminal called the fail terminal through which the message is propagated when the processing of a primitive results in an exception.

The different types of mediation primitives that are available in a mediation flow :


Service invocation:

Service Invoke: Invoke external service, message modified with result

Routing primitives:

Message Filter: Selectively forward messages based on element values
Type Filter : Selectively forward messages based on element types

Endpoint Lookup : Find potential endpoint from a registry query
Fan Out : Starts iterative or split flow for aggregation
Fan In : Check completion of a split or aggregated flow
Policy Resolution: Set policy constrains from a registry query
Flow Order : Executes or fires the output terminal in a defined order
SLA Check : Verifies if the message complies with the SLA
Gateway Endpoint Lookup: Finds potential endpoint in special cases from a registry
UDDI Endpoint Lookup: Finds potential endpoints from a UDDI registry query

Transformation primitives:

XSL Transformation : Update and modify messages using XSLT
Business Object Map : Update and modify messages using business object maps
Message element setter : Set, update, copy, and delete message elements
Set message type : Set elements to a more specific type
Database Lookup : Set elements from contents within a database
Data Handler : Update and modify messages using a data handler
Custom Mediation : Read, update, and modify messages using Java code
SOAP header setter : Read, update, copy, and delete SOAP header elements
HTTP header setter : Read, update, copy, and delete HTTP header elements
JMS header setter : Read, update, copy, and delete JMS header elements
MQ header setter : Read, update, copy, and delete MQ header elements

Tracing primitives:

Message logger : Write a log message to a database or a custom destination
Event emitter : Raise a common base event to CEI
Trace : Send a trace message to a file or system out for debugging

Error handling primitives:

Stop : Stop a single path in flow without an exception
Fail : Stop the entire flow and raise an exception
Message Validator : Validate a message against a schema and assertions

Mediation subflow primitive:

Subflow : Represents a user-defined subflow