The type of dynamic invocation performed, and the result
obtained, depends on the override details provided.
How a dynamic override is processed
There
are several possible combinations of mediation module configurations,
including:
- The mediation module might have more than one import.
- The imports could be wired or unwired.
The algorithm which is used to determine which import to use
during runtime is based on the following parameters, in the order
of evaluation precedence:
- Target import
- BindingType
- Wire
- URI prefix
Here are some examples of different settings and the resulting
runtime behaviour (A value of 'Not supplied' means that no value for
that field was supplied in the incoming message. A value of 'Any'
means that a value for that field can be absent, or will be ignored
if supplied):
Table 1. Example 1 of dynamic overrideImport |
Import name |
BindingType |
Any |
Wire |
Any |
Address |
Not set |
Result |
The specified target import is invoked, using
the address defined when the mediation module was created and deployed.
The bindingType is ignored, because an import name is provided. |
Table 2. Example 2 of dynamic overrideBindingType |
Not set |
Wire |
JMS Import |
Address |
JMS URI |
Result |
A JMS invocation is made using the wired JMS
Import |
Table 3. Example 3 of dynamic overrideImport |
Not supplied |
BindingType |
Web service |
Wire |
JMS Import |
Address |
JMS or HTTP URI |
Result |
A pure dynamic Web Service invocation is made,
using the supplied Address and BindingType. |
Dynamic invocation error handling
A runtime
exception occurs when one of the following conditions is true:
- The URI specifying an intended endpoint has invalid syntax.
- The endpoint specified by the supplied URI does not exist.
- The target import specified does not exist.
- The URI format in the specified endpoint, and the import binding
type, are not compatible.
The exception is thrown by the mediation module, and returned
in the response flow.