IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Key concepts > The enterprise service bus in IBM BPM > Service applications and service modules

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.

IBM BPM supports a supplied set of mediation primitives, which implement standard mediation capabilities for mediation modules or modules deployed into IBM BPM.

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.

Figure 1. Mediation module containing three mediation primitives

You can use Integration Designer 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.

Integration Designer 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.

Integration Designer 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.


Supported mediation primitives

The following set of mediation primitives are supported by IBM BPM:

Business Object Map

Transforms messages.

  • Defines message transformations using a business object map, which can be reused.

  • Allows you to define message transformations graphically, using the business object map editor.
  • Can alter the content of a message.
  • Can transform an input message type to a different output message type.

Custom Mediation

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 create complex transformations and routing patterns by:

  • Creating Java code.
  • Creating your own properties.

  • Adding new terminals.

You can call a service from a Custom Mediation primitive, but the Service Invoke mediation primitive is designed to call services and provides additional functionality, such as retry.

Data Handler

Allows you to transform a part of a message. It is used to convert an element of a message from a physical format to a logical structure or a logical structure to a physical format. The primary usage of the primitive is to convert a physical format, such as a Text string within a JMS Text Message object, into a logical Business Object structure and back again. This mediation is commonly used to:

  • Transform a section of the input message from a defined structure to another - an example of this would be where the SMO includes a string value that is comma delimited and you want to parse this into a specific Business Object.

  • Alter the message type – an example would be when a JMS export has been configured to use a JMS basic typed data binding and within the mediation module the integration developer decides that the content should be inflated to a specific BO structure.

Database Lookup

Modifies messages, using information from a user-supplied database.

Endpoint Lookup

Allows for the dynamic routing of requests, by searching for service endpoints in a repository.

  • Service endpoint information is retrieved from a WebSphere Service Registry and Repository (WSRR). The WSRR registry can be local or remote.

  • You make registry changes from the WSRR administrative console.
  • IBM BPM needs to know which registry to use, therefore, create WSRR access definitions using the IBM BPM administrative console.

Event Emitter

Enhances monitoring by letting you send events from inside a mediation flow component.

  • You can suspend the mediate action by deselecting the check box.

  • You can view Event Emitter events using the Common Base Events browser on IBM BPM.

  • You should only send events at a significant point in a mediation flow, for performance reasons.

  • You can define the parts of the message that the event contains.

  • The events are sent in the form of Common Base Events and are sent to a Common Event Infrastructure server.

  • To fully use the Event Emitter information, event consumers need to understand the structure of the Common Base Events. The Common Base Events has an overall schema, but this does not model the application specific data, which is contained in the extended data elements. To model the extended data elements, the Integration Designer tools generate a Common Event Infrastructure event catalog definition file for each of the configured Event Emitter mediation primitives. Event catalog definition files are export artifacts that are provided to help you; they are not used by Integration Designer or by the IBM BPM run time. You should refer to the event catalog definition files when you create applications to consume Event Emitter events.

  • You can specify other monitoring from IBM BPM.

    For example, you can monitor events to be emitted from imports and exports.

Fail

Stops a particular path in the flow, and generates an exception.

Fan In

Helps aggregate (combine) messages.

  • Can only be used in combination with the Fan Out mediation primitive.

  • Together, the Fan Out and Fan In mediation primitives allow aggregation of data into one output message.

  • The Fan In mediation primitive receives messages until a decision point is reached, then one message is output.

  • The shared context should be used to hold aggregation data.

Fan Out

Helps split and aggregate (combine) messages.

  • Together, the Fan Out and Fan In mediation primitives allow aggregation of data into one output message.

  • In iterate mode, the Fan Out mediation primitive lets you iterate through a single input message that contains a repeating element. For each occurrence of the repeating element, a message is sent.

  • The shared context should be used to hold aggregation data.

HTTP Header Setter

Provides a mechanism for managing headers in HTTP messages.

  • Can create, set, copy, or delete HTTP message headers.
  • Can set multiple actions to change multiple HTTP headers.

Mapping

Transforms messages.

  • Allows you to perform Extensible Stylesheet Language (XSL) transformations or Business Object Map transformations.

  • You transform messages using an XSLT 1.0 or an XSLT 2.0 transformation or a Business Object Map transformation. The XSL transformations operate on an XML serialization of the message, whereas the Business Object Map transformation operates on the Service Data Objects (SDO).

Message Element Setter

Provides a simple mechanism for setting the content of messages.

  • Can change, add or delete message elements.
  • Does not change the type of the message.

  • The data in the value columns must be either a simple XML schema type, or an XML schema type that extends a simple XML schema type.

Message Filter

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

  • You can suspend the mediate action by deselecting the check box.

Message Logger

Logs messages in a relational database or through your own custom logger. The messages are stored as XML, therefore, data can be post-processed by XML-aware applications.

  • You can suspend the mediate action by deselecting the check box.

  • The rational database schema (table structure) is defined by IBM.
  • By default, the Message Logger mediation primitive uses the Common database. The runtime environment maps the data source at jdbc/mediation/messageLog to the Common database.

  • You can set Handler implementation classes to customize the behavior of the custom logger. Optionally, you can provide Formatter implementation classes, Filter implementation classes, or both to customize the behavior of the custom logger.

MQ Header Setter

Provides a mechanism for managing headers in MQ messages.

  • Can create, set, copy, or delete MQ message headers.
  • Can set multiple actions to change multiple MQ headers.

Policy Resolution

Allows for the dynamic configuration of requests, by searching for service endpoints, and associated policy files, in a repository.

  • You can use a policy file to dynamically override the promoted properties of other mediation primitives.
  • Service endpoint information and policy information is retrieved from a WebSphere Service Registry and Repository (WSRR). The WSRR registry can be local or remote.

  • You make registry changes from the WSRR administrative console.
  • IBM BPM needs to know which registry to use, therefore, create WSRR access definitions using the IBM BPM administrative console.

Service Invoke

Calls a service from inside a mediation flow, rather than waiting until the end of the mediation flow and using the callout mechanism.

  • If the service returns a fault, you can retry the same service or call another service.

  • The Service Invoke mediation primitive is a powerful mediation primitive that can be used on its own for simple service calls, or in combination with other mediation primitives for complex mediations.

Set Message Type

During integration development, lets you treat weakly-typed message fields as though they are strongly-typed. A field is weakly-typed if it can contain more than one type of data. A field is strongly-typed if its type and internal structure are known.

SOAP Header Setter

Provides a mechanism for managing headers in SOAP messages.

  • Can create, set, copy, or delete SOAP message headers.
  • Can set multiple actions to change multiple SOAP headers.

Stop

Stops a particular path in the flow, without generating an exception.

Type Filter

Allows you to direct messages down a different path of a flow, based on their type.

WebSphere eXtreme Scale Retrieve

You can retrieve information from an eXtreme Scale server cache environment.

  • You can look up values in the cache, and store them as elements in the message using a key.
  • Combining the eXtreme Scale Store and Retrieve mediation primitives, you can cache the response from a back-end system. Future requests will not require access to that back-end system.

  • You must create eXtreme Scale definitions using the WebSphere ESB administrative console, so you can specify which eXtreme Scale server to use.

WebSphere eXtreme Scale Store

You can store information into an eXtreme Scale server cache environment.

  • You can store information in a eXtreme Scale cache using a key and an object.
  • Combining the eXtreme Scale Store and Retrieve mediation primitives, you can use the Store mediation primitive to store data within the cache, and use the Retrieve mediation primitive to retrieve data previously stored within the cache.

  • You must create eXtreme Scale definitions using the WebSphere ESB administrative console, so you can specify which eXtreme Scale server to use.

Service applications and service modules