This topic applies only to the IBM Business Process Manager Advanced configuration.

Dynamic invocation

When a mediation module is developed and deployed, the flow of messages through the module is determined by the wiring of components. The configuration of the components is used to determine which external services are to be called.

Applications can override or change the configuration and reroute messages at run time. You might do this dynamically by overriding a value specified for an endpoint address. Alternatively, you can select a new target import. In each case, the message flow changes according to the information in the message.

For example, you can use Integration Designer to create a binding on an import. The import contains endpoint information, specifying the location of a remote service. This fixed endpoint information can be overridden dynamically by information carried in the message.

If a message flow is changed dynamically within a mediation module, the new route applies only to that message and any response coming back. When the message has been sent and any response returned, the dynamic routing changes are discarded and the original fixed values defined in the module are used as the default values again. Any response to a dynamic invocation returns using the same route as the dynamic invocation.

There are three main ways that dynamic invocation takes place:
  • Dynamic override of a fixed endpoint, in which a service is called using any supported import binding. The service is available at a different endpoint from the endpoints originally specified when the mediation module was created and deployed.
  • Dynamic invocation with a target import, in which a service is called using any supported import binding. The binding must already be available within the mediation module. It is selected at run time according to information contained in the message.
  • Pure dynamic invocation, in which a service is called without needing an import in the mediation module. No additional information is required apart from the details in the message.
The Endpoint Reference (EPR) structure within the request message is used to provide the information required for a dynamic invocation. Details about the EPR can be obtained by retrieving information about the endpoint from a suitable storage location, such as WSRR or a database. This information is used to set EPR details for the message using the SCA Endpoint Reference API. The SMO structure: 
/headers/SMOHeader/Target/address
/headers/SMOHeader/Target/@bindingType
/headers/SMOHeader/Target/@import
/headers/SMOHeader/AlternateTarget/address
/headers/SMOHeader/AlternateTarget/@bindingType
/headers/SMOHeader/AlternateTarget/@import
During a dynamic invocation, the invocation target type is identified by examining the endpoint URI.
  • If the URI begins with sca, this indicates an SCA component.
  • A URI prefix of http or jms is assumed by default to indicate a web service endpoint.
  • A URI prefix of http does not by default indicate an HTTP service, and a URI prefix of jms does not by default indicate a JMS service. However, if the reference is wired to an import, or a target import is specified with a JMS or an HTTP binding, the URI is assumed to be JMS or HTTP, and not web services.
    • The bindingType field in the Endpoint Reference can be used to change this. For example, using the SCA Endpoint Reference API to set the bindingType field to a value of EndpointReference.BINDING_TYPE_HTTP or a mediation flow to set the Target@bindingType attribute to HTTP, results in a URI prefix of http in the EPR being interpreted as indicating an HTTP binding for that message.
Parent topic: Invocation of Services