Mediation primitives accept and process messages to let you change their format, content or the target service provider. Mediation primitives have properties that determine how a message will be processed. When you wire a flow in the Mediation Flow editor, you can modify the properties of nodes and mediation primitives.
Tip: Wire the input and output terminals of a mediation primitive before you set its properties. This will make your input and output message types known to the editor, and will save you time when setting the properties.
The Input node propagates the message to the primitive or node to which it is wired. The properties to be stored in the message context are specified in the details page of the input node's properties view. These properties can be accessed by mediation primitives later in the flow.
Here is an image of the input node's details page properties:
The callout node receives the message and invokes the requested service and operation. There is a callout node for each connected target operation in the mediation flow.
Here is an image of the callout node's details page properties:
Dynamic routing is enabled by default. This means that the callout will invoke the endpoint that is set in the target element of the SMOHeader in the message. If no endpoint exists in this location, the callout will invoke the endpoint defined in the import's binding. For more information, see Selecting endpoints dynamically
The callout response node is a starting point for the response flow. It forwards the message received from the target operation into the response flow. There is one callout response node for each target operation. Errors that are not defined as WSDL fault messages are propagated to the fail terminal of the callout response node.
Here is an image of the callout response node's details page properties:
Select the check box to include the original request message if you want to propagate the complete message to the fail terminal in the event of a failure. If you don't select the check box, the message information that is propagated includes the failure information (in the failinfo element) and some context information.
The Event Emitter primitive emits custom base events at a significant point in the message flow.
Here is an image of the Event Emitter primitive's details page properties.
The Message Element setter primitive sets, copies or deletes the value of message elements as the message passes through a mediation flow.
Here is an image of the Message Element Setter's detail page properties.
Select the Validate input check box to enable input message validation to ensure it matches its type definition at runtime. Deselect this check box to disable validation if performance is a concern.
Tip: Promote this property so that you can enable validation at runtime to help you debug a problem.
For more information, see Message Element Setter primitive reference.
The Endpoint Lookup mediation primitive queries the WebSphere Service Registry Repository and retrieves service endpoints. The endpoints retrieved are based on the search criteria defined in the Details page, and the retrieved endpoints are placed in the primitiveContext element in the message context. The retrieved endpoints can then be used to dynamically invoke a service, depending on the match policy specified.
Here is an image of the Endpoint Lookup primitive's details page properties, where you specify the properties to include in your query of the registry.
Here is an image of the advanced details page of the Endpoint Lookup primitive
The XSL Transformation primitive transforms messages, or changes message content according to an XSL style sheet that maps between the source and target message types.
Here is an image of the XSL Transformation primitive's details page properties.
In the Mapping file field:
In the Root field, select an XPath 1.0 expression to identify the part of the message that is available to the transformation.
In the Root field, select an XPath 1.0 expression to identify the part of the message that is available to the transformation.
Select the Validate input check box to enable input message validation to ensure it matches its type definition at runtime. Deselect this check box to disable validation if performance is a concern.
Tip: Promote this property so that you can enable validation at runtime to help you debug a problem.
The Regenerate XSL button only appears on those XSL Transformation primitives that were created in a previous version of WebSphere Integration Developer. Click Regenerate XSL to synchronize the XSL style sheet with the XML map, and to optionally enable the capability to automatically generate the associated XSL style sheet. Once you enable this capability, the XSL and XMX files will automatically stay synchronized.
For more information, see Creating mappings for the XSL Transformation primitive and XSL Transformation primitive reference.
The Message Logger primitive logs a copy of the message to a database for future retrieval or audit.
Here is an image of the Message Logger primitive's details page properties
Transaction mode defines the transaction within which the changes to the database will be committed. This property only takes effect within a global transaction. By default, transactions of mediation flow components are not global. To set the transaction of the mediation flow component to global, set the qualifier property in the component's Implementation page in the assembly editor. Select one of the following options:
For more information, see Message Logger primitive reference
The Message Filter primitive compares the content of the message to XPath 1.0 expressions that you configure, and routes the message to the next mediation primitive based on the result. You can add output terminals and associate them with the XPath expression that you configured.
Terminals
Details
We will use an example to illustrate the use of the properties in the details page of the properties view for the Message Filter primitive. In the example, if the value of the subscriptionLevel field in the message body is premium, the input message will be propagated to the terminal named realtime. The following image shows the properties that are set for the example:
In the Filters table, define the filtering performed by the mediation primitive. Each row in the table represents a filter object that associates a pattern with a terminal name.
/context/correlation/subscriptionLevel[self::node()="premium"]
Note: The order of the filters can be changed using the up and down buttons. You can control the pattern matching behavior by using the distribution mode property.
In the Distribution mode field, specify the desired behavior when more than one pattern evaluates to true.
If no terminal matches the message, it is propagated to the default terminal.
For more information, see Message Filter primitive reference
The Database Lookup primitive searches values from a database and stores them in the message.
select SALARY from EMPLOYEE_TABLE where SERIAL_NUMBER = '049728'
The result, '50000' of type long will be stored in the salary field in the message body.
Specify these properties for the primitive in the Details page of the Properties view.
In the Data source name field, enter the JNDI name of the data source. In the example, jdbc/sample/EmployeeDatabase
In the Table name field, enter the name of the database table, including the schema name. In the example, myschema.EMPLOYEE_TABLE
In the Key column name field, enter the name of the database column to be used for the look up. In the example, this is SERIAL_NUMBER
In the Key path field, click Custom XPath to launch the XPath Expression Builder to build an XPath expression. The value returned from the XPath expression is used as the key into the database. In this case that is the value of the serialNumber (049728) from the message body.
Select the Validate input check box to enable input message validation to ensure it matches its type definition at runtime. Deselect this check box to disable validation if performance is a concern.
Tip: Promote this property so that you can enable validation at runtime to help you debug a problem.
For more information, see Database Lookup primitive reference.
The Custom Mediation primitive allows you to implement your own mediation logic using Java code, or to call an import in the same mediation module.
Starting with WebSphere Integration Developer 6.0.2, there has been a change in implementation of the custom mediation primitive. The custom code is now embedded in the primitive. Custom mediations created in previous versions will still run without any changes required, however you have the option to convert them to the new implementation. For more information on this change, see the topics in "Implementing custom mediation logic" in the related tasks at the bottom of thi
Here is an image of a Custom Mediation primitive's details page properties.
For custom mediation primitives created in a version prior to WebSphere Integration
Developer 6.0.2, the details view will appear as shown below:
Open Java Editor launches the Java editor. Note that selecting this option may impact the future use of the Java Snippet editor for this custom mediation.
For more information, see Implementing custom mediation logic and Custom mediation primitive reference
Use the Stop primitive to silently stop execution of the flow. This is an expected termination and is not caused by an exception.
There are no properties to specify for this primitive. For more information, see Error handling in the mediation flow and Stop primitive reference.
The Fail primitive throws an exception and stops the execution of the flow when there is an execution failure in a mediation primitive.
Specify the properties of the primitive in the details page of the properties view.
In the Error message field, enter the error message that is added to the exception.
For more information, see Error handling in the mediation flow and Fail mediation primitive reference.