JMS Connector Configuration
Before using JMS with SV, you will have to put your JMS client classes into SV classpath. There is a built-in support for specific JMS servers.
Note
If you want to use secure transport, you will have to set up the Java trust
store using javax.net.ssl.trustStore
and
javax.net.ssl.trustStorePassword
system properties.
Weblogic example:
"connector": [ {
"id": "connector",
"connectorType": "jms",
"properties": {
"jndiContextFactory": "weblogic.jndi.WLInitialContextFactory",
"jndiProviderUri": "t3://machine.domain.com:7001",
}
} ]
WebSphere example:
"connector": [ {
"id": "connector",
"connectorType": "jms",
"properties": {
"jndiContextFactory": "com.ibm.websphere.naming.WsnInitialContextFactory",
"jndiProviderUri": "corbaloc::machine.domain.com:2809/NameServiceServerRoot",
}
} ]
IBM MQ
Although SV uses IBM MQ classes for JMS for communication with MQ, there is no
support for JNDI. So SV provides its own replacement class which is used as
the jndiContextFactory
parameter:
jndiContextFactory
iscom.microfocus.sv.processing.jms.connector.MqProvider
host
is MQ server hostnameport
is MQ server portmqChannel
is MQ channel namemqCipherSpec
contains cipher spec if secure transport is to be used (see IBM documentation), for exampleTLS_RSA_WITH_AES_256_CBC_SHA256
orANY_TLS
MQ connector configuration example:
"connector": [ {
"id": "connector",
"connectorType": "jms",
"properties": {
"jndiContextFactory": "com.microfocus.sv.processing.jms.connector.MqProvider",
"host": "mymq.acme.com",
"port": 1514,
"mqChannel": "MY.SRVCONN",
"username": "admin",
"password": "changeit",
"jmsConnectionFactory": "ConnectionFactory",
"jndi.queue.REAL-REQUEST": "SV.Real.Request",
"jndi.queue.REAL-RESPONSE": "SV.Real.Response",
"jndi.queue.VIRTUAL-REQUEST": "SV.Request",
"jndi.queue.VIRTUAL-RESPONSE": "SV.Response"
}
} ]
Note
In case of secure transport you may need to set the
com.ibm.mq.cfg.useIBMCipherMappings
Java property according to you JSSE
vendor. It instructs IBM MQ classes for JMS to correctly map MQ cipher spec
to JSSE equivalent. By default SV expects Oracle JSSE and sets this property
automatically if not already set. So if you need to switch to IBM variant,
you need to set the property before starting the lab. Incorrect settings is
usually signalled by exception complaining about unknown cipher spec.
Microsoft Azure Service Bus
To use Azure Service Bus with SV, include JARs from Apache Qpid JMS (download the AMQP 1.0 version). Then set properties as follows:
jndiContextFactory
isorg.apache.qpid.jms.jndi.JmsInitialContextFactory
jmsConnectionFactory
isConnectionFactory
jndi.connectionfactory.ConnectionFactory
should be set to Azure server URI, something likeamqps://xxx.servicebus.windows.net
username
andpassword
contain theSharedAccessKeyName
andSharedAccessKey
from Azure connection properties
Since Azure does not provide JNDI, it must be configured via Apache Qpid JMS.
For each queue and topic you need to create property named according to queue
name in JNDI with value set to Azure name (JNDI name and Azure name can be
different). So for example lets have Azure queue MyVirtualRequest
which will
be used for virtual requests in SV. We need to set two properties:
jndi.queue.VirtualRequest
toMyVirtualRequest
- this says there will be queue namedVirtualRequest
in JNDI and it will be mapped toMyVirtualRequest
in Azure. You can have both JNDI and Azure names the same but you still need to include this mapping.jmsVirtualRequestDestination
in endpoint configuration will be set to JNDI name, i.e.VirtualRequest
.
For topic, use jndi.topic.JNDI-NAME
property. For topic subscription you
should use jndi.queue.JNDI-NAME
as subscription is accessed as queue from JMS.
The Azure name is in form of topic_name/Subscriptions/subscription_name
. In
case of topics you will have to use topic on sending side (real request and
virtual response) and subscription on receiving side (virtual request and real
response).
Example of JMS connector configuration for Microsoft Azure Service Bus:
"connector" : [ {
"connectorType" : "jms",
"id" : "connector",
"properties" : {
"jndi.connectionfactory.ConnectionFactory" : "",
"username" : "...",
"password" : "...",
"jndiContextFactory" : "org.apache.qpid.jms.jndi.JmsInitialContextFactory",
"jmsConnectionFactory" : "ConnectionFactory"
}
} ]
JMS connector configuration properties
The JMS connector is configured with the JNDI context configuration properties prepended with the "jndi." prefix.
The mandatory properties are bold, other properties are optional.
Property | Description |
---|---|
jndiContextFactory | (string) JNDI initial context factory class name. It is also used for protocols not supporting JNDI as implementation class (see MQ above). |
jndiProviderUri | (string) JNDI provider URI, i.e. tcp://localhost:61616 or ssl://localhost:61616 |
jmsConnectionFactory | (string) JNDI name of JMS connection factory to use, some implementations may not need it. |
username | (string) credentials required by broker |
password | (string) credentials required by broker |
host (1) | (string) MQ server host |
port (1) | (integer) MQ server port |
mqChannel (1) | (string) MQ channel |
mqCipherSpec (1) | (string) IBM MQ cipher spec to use, i.e. TLS_RSA_WITH_AES_256_CBC_SHA256 or ANY_TLS . See the IBM documentation. |
Notes:
- [1] Used when connecting to IBM MQ server. See also IBM MQ configuration
JMS endpoint configuration properties
In each endpoint you can configure either request, response or both. Since JMS is one-way, not request-response, the endpoint request/response mapping just affects how endpoint behaves in different service modes.
- FORWARD_TO_REAL_SERVICE mode:
- SV will listen on virtual request destination and send the received messages to real request destination.
- SV will also listen on real response destination and send the received messages to virtual response destination.
- In both cases it will learn the messages.
- SIMULATE_SERVICE mode:
- SV will listen on virtual request destination and pass received messages to simulator.
- Any messages generated by simulator will be sent to virtual response destination.
- INVOKE_REAL_SERVICE mode:
- SV will send messages generated by simulator to real request destination.
- SV will listen for messages from real service on real response destination.
As can be seen, the REQUEST destinations work from client to real service and RESPONSE destinations work in reverse. This way you can simulate service which sends messages to some destination(s) and receives them on another destination(s).
Note
It is important to set name of endpoint as the endpoint is directly bound to operation. There is one to one mapping between endpoint and operation so the endpoint name must match the operation name. During learning, the operation will be named according to endpoint from which the message came. During simulation and invocation, operation name is used to determined where to send the message - SV uses the endpoint named after the operation.
Mandatory properties are bold. Other properties are optional.
Property | Description |
---|---|
displayName (1) | (string) The endpoint name used in operation definition in service interface. |
jmsVirtualRequestDestination | (string) The JNDI name of destination for receiving requests from clients. |
jmsVirtualResponseDestination | (string) The destination where clients receive responses. Optional, the client can provide response topic with replyTo header. |
jmsRealRequestDestination | (string) The destination where service receives requests. Optional, the client can provide a topic with replyTo header for solicit response in invocation mode. |
jmsRealResponseDestination | (string) The destination to receive responses from service. |
Notes:
- [1] The display name is mandatory when there are more than one operation in service interface.