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 primitives

WPS: Mediation primitives :

Mediation flow components operate on message flows between service components. The capabilities of a mediation component are implemented by mediation primitives, which implement standard service implementation types.

A mediation flow component has one or more flows. For example, one for request and one for reply.

WebSphere® Process Server supports a supplied set of mediation primitives, which implement standard mediation capabilities for mediation modules or modules deployed into WebSphere Process Server. If you need special mediation capabilities, you can develop your own custom mediation primitives.

A mediation primitive defines an "in" operation that processes or handles messages that are represented by service message objects (SMOs). A mediation primitive can also define "out" operations that send messages to another component or module.

You can use WebSphere Integration Developer to configure mediation primitives and set their properties. Some of these properties can be made visible to the runtime administrator by promoting them. Any mediation primitive property that can be promoted can also be a dynamic property. A dynamic property can be overridden, at run time, using a policy file.

WebSphere Integration Developer also allows you to graphically model and assemble mediation flow components from mediation primitives, and assemble mediation modules or modules from mediation flow components. The administrative console refers to mediation modules and modules as SCA modules.

WebSphere Integration Developer also allows the definition of subflows in modules or their dependent libraries. A subflow can contain any mediation primitive except for the Policy Resolution mediation primitive. A subflow is invoked from a request or response flow, or from another subflow using the Subflow mediation primitive. Properties promoted from mediation primitives in a subflow are exposed as properties on the Subflow mediation primitives. These may then be promoted again until they reach the module level at which point they can then be modified by the runtime administrator.