WebSphere

Custom Mediation primitive

Use the Custom Mediation primitive to call custom logic.

Introduction

The Custom Mediation primitive allows you to implement your own mediation logic in Java™ code.

The Custom Mediation primitive combines the flexibility of a user-defined mediation primitive, with the simplicity of a pre-defined mediation primitive. You can add new terminals and create your own properties, and this allows you to create complex transformations and routing patterns.

By default, a Custom Mediation primitive has one input terminal (in), one output terminal (out), and one fail terminal (fail). However, you can add more input and output terminals. The input terminals are wired to accept a message; the output and fail terminals are wired to propagate the message. The input message is passed as the input parameter to the Java code. If the operation returns successfully, the response from the Java code is propagated to an output terminal. If the operation returns unsuccessfully, the fail terminal propagates the original message, together with any exception information.

Details

You can add an extra terminal to a Custom Mediation primitive by right-clicking on the Custom Mediation primitive and selecting either Add Input Terminal or Add Output Terminal. The name you give to a terminal is used in code generation and, therefore, must be a valid Java identifier.

You can define your own properties in a Custom Mediation primitive by going to the User Properties tab of the Properties view. You can add, edit and remove user properties.

You create your Java code by going to the Details tab of the Properties view, and adding either Java snippets or visual snippets. Because mediation primitives process messages as service message objects (SMOs), the visual snippets for processing messages are in the SMO services folder, in the Visual Snippet view.

You specify the Java imports your code needs on the Java Imports tab of the Properties view.

For most mediation primitives, the mediation flow editor detects the message types and only allows you to wire primitives that have compatible message types. However, for Custom Mediation primitives, the editor does not know the message types. Therefore, before you wire your Custom Mediation primitive, specify its message types in the Terminal tab of the Properties view.

Migration

Any deployed version 6.0.x Custom Mediation flows continue to work without migration or redeployment.

Version 6.0.x Custom Mediation primitives, which invoke a reference partner, behave as follows:
  • Continue to work without migration.
  • Are marked as deprecated, in WebSphere® Integration Developer.
  • Have read-only properties, in WebSphere Integration Developer.
  • Need manual migration to take advantage of the version 6.1.x Service Invoke mediation primitive.
Version 6.0.2 Custom Mediation primitives that contain embedded Java or visual code, behave as follows:
  • Continue to work without migration.
  • Are marked as deprecated, in WebSphere Integration Developer.
  • Cannot have more than one input terminal and one output terminal.
  • The Root property is now read-only and is no longer available in WebSphere Integration Developer.
  • Keep the method signature of the implementation as commonj.sdo.DataObject execute(commonj.sdo.DataObject input1). The implementation is modifiable using the embedded Java or visual editors.
  • Can be migrated to version 6.1.x using the fix in the Problems view.

Usage

You can use the Custom Mediation primitive to do processing that is not covered by other mediation primitives.

You can create complex routing patterns. For example, you could route the input SMO to each of your output terminals, in a specific order. The following Java code would fire out1 first, then out2, and lastly out:
out1.fire(smo);
out2.fire(smo);
out.fire(smo);

You can create complex transformations. For example, you could extract different parts of the input message to send to the different output terminals.

In the same way as you can make use of multiple output terminals, you can also make use of multiple input terminals. For example, you could create a fault-handling node by creating multiple input terminals each for a different terminal type, and in your Java code create a new output message that contains the /context/failInfo/failureString information.

Properties

User properties
You can define User Properties for your Custom Mediation. A user property must have a name, type and value. After you have created a user property you can promote it, so that the runtime administrator can change the value.
Name
The name of your property.
Type
The data type of your property. The valid types are: String, Boolean, Integer, Float and XPath.
Value
The value of your property. Whether a value is valid, depends on the data type you assign to the user property.
Required
If a property is marked as Required, the run time checks to see if the property is set.
Table 1. User-defined properties
Property Valid values Default
User Properties Name String  
Type String, Boolean, Integer, Float or XPath  
Value Depends on the Type  
Required Boolean: true or false false
The following properties are deprecated: Service reference, Operation and Root.
Note: Prior to version 6.1.x, you could create a Custom Mediation primitive to invoke a service. At version 6.1.x you can use the Service Invoke mediation primitive to call a service from inside a mediation flow.

Considerations

Consider the following when using the Custom Mediation primitive:


reference Reference topic

Terms of use | Feedback


Timestamp icon Last updated: 20 June 2010 00:39:53 BST (DRAFT)


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.wbit.help.medprim620.doc/ref/rwesb_CustomSCAmediationprimitive.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).
iDoc on