Use the mediateSIBDestination command
to mediate a bus destination for a service integration bus.
Mediating a destination associates a mediation with a
selected bus destination. At run time, the mediation applies some
message processing to the messages handled by the bus destination.
Note that you can only mediate a destination with a single mediation
at a time. You can mediate more than one destination with the same
mediation.
To
run the command, use the AdminTask
object of the wsadmin
scripting client.
The wsadmin scripting client is run from Qshell. For more information, see Configuring Qshell to run WebSphere scripts using wsadmin scripting.
Command-line help is provided for service integration bus commands:
After using the command, save your changes to the
master configuration by using the following command:
AdminConfig.save()
Purpose
This command mediates a bus destination
for a service integration bus. There are parameters that you can use
to create a mediation queue point on a WebSphere® MQ
server, and create the corresponding mediation execution point on
a cluster or a server.
You should
only use the
node,
server,
and
cluster parameters in
WebSphere Application Server environments that
support server clusters.
Note: If you are mediating a destination
where the mediation point is a queue on a WebSphere MQ
server (using the wmqServer parameter), you must
specify where the mediation code runs. If the mediation code runs
in a service integration bus member, you must specify a mediation
execution point by using the node, server,
and cluster parameters. If the mediation code
runs externally, you must omit the node, server,
and cluster parameters.
- If you are not using a mediation point that is a queue on a WebSphere MQ server, use the node, server,
and cluster parameters to specify where the mediation
point is located. This is also where the mediation runs. If you omit
these parameters, the mediation point defaults to the bus member to
which the destination being mediated is assigned.
- If you are using a mediation point that is a queue on a WebSphere MQ server, use the wqmServer and wmqQueueName parameters
to specify the mediation point.
- If you omit the node, server,
and cluster parameters, the service integration
bus assumes that the mediation process is performed by an external WebSphere MQ application.
- If you want to assign the mediation point to a WebSphere MQ
server bus member, use the wmqServer and wmqQueueName parameters
to specify a WebSphere MQ queue.
In this situation, because you have omitted the node, server,
and cluster parameters, an external WebSphere MQ application can
run the mediation. The node, server,
and cluster parameters are used for nominating
the bus member where the mediation code runs.
Required parameters
- -bus bus_name -destinationName destination_name
- The destination to be mediated.
- -mediationName mediation_name
- The name of the mediation to be applied to the bus destination.
This mediation must exist before this command can be used.
Conditional parameters
- -wmqServer mq_server_name -wmqQueueName mq_queue_name
- [Queue or web service destination] To assign the mediation point
to a WebSphere MQ queue,
specify both the name of the WebSphere MQ server bus member
where the mediation point is to be assigned, and the name of the WebSphere MQ queue to be used
to store messages ready for mediation. mq_server_name is
the name of the WebSphere MQ server as specified in the -name parameter
when creating the WebSphere MQ server. mq_queue_name is
the name allocated to the WebSphere MQ queue by WebSphere MQ administration.
- -node node_name -server server_name
- [Not topic space] To mediate the bus destination to a server bus
member, specify both the name of the node on which the server runs
and the name of the server.
- -cluster cluster_name
- [Not topic space] To mediate the bus destination to a cluster
bus member, specify the name of the cluster.
This option should be used only in WebSphere Application Server environments that
support server clusters.
Optional parameters
- -nonPersistentReliability
Specify the service integration quality of service to use with
nonpersistent WebSphere MQ messages
that are received by service integration from a WebSphere MQ network. The messages in a WebSphere MQ network have their own quality of service level. This is either persistent or non-persistent. When these messages are received by a service integration application, they are assigned a service integration quality of service level that depends on their WebSphere MQ quality of service level.
For nonpersistent
WebSphere MQ messages received,
the default service integration quality of service is
RELIABLE_NONPERSISTENT.
If you choose to override this default, you will probably choose one
of the other nonpersistent service integration qualities of service
BEST_EFFORT_NONPERSISTENT or
EXPRESS_NONPERSISTENT.
However, you can choose any of the five possible service integration
qualities of service:
- BEST_EFFORT_NONPERSISTENT
- Messages are discarded when a messaging engine stops or fails. Messages might also be discarded if a connection used to send them becomes unavailable or as a result of constrained system resources.
- EXPRESS_NONPERSISTENT
- Messages are discarded when a messaging engine stops or fails. Messages might also be discarded if a connection used to send them becomes unavailable.
- RELIABLE_NONPERSISTENT
- Messages are discarded when a messaging engine stops or fails.
- RELIABLE_PERSISTENT
- Messages might be discarded when a messaging engine fails.
- ASSURED_PERSISTENT
- Messages are not discarded.
Note: Higher levels of reliability have higher impacts on
performance.
For
more information, see Mapping the JMS delivery option and message reliability to and from the WebSphere MQ persistence value.
- -persistentReliability
Specify the service integration quality of service to use with
persistent WebSphere MQ messages
that are received by service integration from a WebSphere MQ network. The messages in a WebSphere MQ network have their own quality of service level. This is either persistent or non-persistent. When these messages are received by a service integration application, they are assigned a service integration quality of service level that depends on their WebSphere MQ quality of service level.
For persistent
WebSphere MQ messages received,
the default service integration quality of service is
ASSURED_PERSISTENT.
If you choose to override this default, you will probably choose the
other persistent service integration quality of service
RELIABLE_PERSISTENT.
However, you can choose any of the five possible service integration
qualities of service:
- BEST_EFFORT_NONPERSISTENT
- EXPRESS_NONPERSISTENT
- RELIABLE_NONPERSISTENT
- RELIABLE_PERSISTENT
- ASSURED_PERSISTENT
For more information, see Mapping the JMS delivery option and message reliability to and from the WebSphere MQ persistence value.
- -useRFH2
- Determines whether service integration technologies includes
an RFH2 header in messages it places on the mediation point. Possible
values are:
- TRUE
- FALSE
The default value is TRUE.
- -maintainStrictMessageOrder
- Maintain strict message order.
Possible values are:
- Selected
- Maintains the order in which a producer sends
messages to the destination.
At run time,
this property has priority over other configuration property values.
For information on the configuration properties that are overridden
at run time, see Strict message ordering for bus destinations.
- Cleared
- Message order is not preserved for this destination.
Example
- Using Jython:
wsadmin>AdminTask.mediateSIBDestination("-bus abus -destinationName myqueue
-mediationName filterMed -cluster cluster1")
- Using Jacl:
wsadmin>$AdminTask mediateSIBDestination {-bus abus -destinationName myqueue
-mediationName filterMed -cluster cluster1}