IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Business process management overview > Incorporate services
Access services external to an application
This scenario is applicable for WebSphere Enterprise Service Bus and IBM Business Process Manager.
- Mediation modules can be deployed to WebSphere ESB and IBM BPM.
- Modules can be deployed to IBM BPM.
Service interaction begins when a service requester sends a message to a service provider, which performs the requested function and sends the result in a message back to the service requester. Processing generally includes...
- routing
- protocol conversion
- transformation
- retry of a failed invocation
- dynamic service invocation
This processing is known as mediation.
There are two types of modules in IBM Integration Designer
Modules Business integration modules. Contain business processes, rules and state machines Mediation modules Implement mediation flows If there is little or no state processing required, consider using a mediation flow component.
If you need to store state between service invocations, or if you have data that will need to be stored in variables and processed, consider using a business process component.
For example, if you are calling multiple services and recording the information that is returned from each, so that after invoking all the services, you want to do some further processing with the returned data, use a business process where you can easily assign the returned information to variables. In other words, when you have too much state you have crossed the line into business logic.
Access an SCA component
A basic example of accessing a service is when an import calls another SCA component, without requiring any data transformation. Even in this situation, you could access the external service from a mediation module, rather than accessing it directly from a business module. This would allow flexibility in the future, for changing the service endpoint or qualities of service or governance (for example, adding logging) without impacting the business components that consume the service. This architectural pattern is known as "separation of concerns".
Before you decide to implement this pattern, weigh the benefits of the pattern against the potential effects of overhead introduced by another module. If your main requirement is flexibility, and you are going to make frequent changes to the services accessed, consider using a separate module as shown here. If performance is most important, and you are willing to update and redeploy the business logic, consider using a single module.
High level tasks
- Create a mediation module.
- In the mediation module, create an import with the appropriate binding for the external service that you want to access.
- Create an export, and give it the same interface as the import.
- Generate an SCA binding for the export.
- In the mediation module's assembly, wire the export to the import. Save the mediation module.
- Create a module.
- Add an export, and a component.
- In the Business integration view, drag the export created in the mediation module (in step 4) into the module assembly. An import with the same binding as the export will be created.
- Wire the export to the component, and the component to the import.
- Add the component's implementation.
Later, you can add mediation logic such as logging or routing to the mediation module without affecting the business module.
Adding mediation
Sometimes it is not sufficient to simply invoke an external service. Sometimes you need to do processing first, by adding a mediation module as an intermediary between the service requester and provider.
These are some of the functions that the intermediary mediation flow would perform:
- Setting protocol headers.
- Interface or parameter transformation by using a Business Object Map or Mapping primitive.
- Select a particular service from a static list, by using a Message Filter primitive.
- Invoking multiple services to aggregate the results, by using the Fan out and Fan In primitives.
- Dealing with service invocation failures by retrying the same service or invoking a different service, by using a Service Invoke primitive.
- Dynamic routing by choosing which service to use at run time.
Versus than integration time, which enables services to be more loosely coupled and businesses to react faster to change.
New services can be added without touching the modules that have been deployed to the runtime environment.
Dynamic routing is most powerful when used with a registry, which requires the Endpoint Lookup mediation primitive to be used.
Access Enterprise Information Systems
Services and artifacts on external systems can be imported into Integration Designer. A wizard discovers applications and data on an Enterprise Information System (EIS) and lets you generate services from the discovered applications and data. The generated artifacts are interfaces and business objects, which can be used by components in a module.
Using an intermediary mediation module between a module and a host system makes it more reusable. In the example below, a mediation flow is used to route to the correct host system, and to transform the data to the format required by the host system.
Here are the high level tasks for this example:
- Use the external service wizard to connect to the host system. Using the external service wizard to access external services follows a similar pattern regardless of the adapter you are using. For information on how to use the external service wizard, see Pattern of accessing external services with adapters
- Create a module. For step-by-step instructions, see Create a module for business services
- Add an export, a component, and an import with SCA binding. See Calling services
- Add an interface to the export, and wire the export to the component.
- Add the component's implementation. In the implementation, set a property that indicates which host service will be accessed. For information on implementation types, see Implementations
- Create a mediation module with an export that has an SCA binding, and the same interface as the import of the module created in step 2.
- Wire the export to a mediation flow component.
- Create an import for each host system that you want to access, using the appropriate outbound adapter from the assembly editor palette.
- Wire the mediation flow component to the imports.
- Implement the mediation flow component. Use a Message Filter primitive to choose the import based on a property set in the business logic, and use a Mapping primitive for each adapter import. Message filter.
- In the module, select the mediation module's export as the service to be imported into the module. For step-by-step information, see Invoking a service from another module.
Later, you can make a change such as adding an adapter, or changing an adapter to point to a different host system, with minimal impact to the business logic.
Access messaging systems
In order for your service component architecture (SCA) module to communicate to an existing JMS, MQ or MQ JMS messaging client, you need to create interfaces, business objects and bindings for imports and exports. See Mapping a message to an SCA interface.
Mediation flows use messages, which provide access to context and header information in addition to business objects.
If you want access to JMS header information or a custom JMS property, use a mediation flow. If you are integrating with an MQ system, and you want to access MQ header information, use a mediation flow.