Skip to content

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 is com.microfocus.sv.processing.jms.connector.MqProvider
  • host is MQ server hostname
  • port is MQ server port
  • mqChannel is MQ channel name
  • mqCipherSpec contains cipher spec if secure transport is to be used (see IBM documentation), for example TLS_RSA_WITH_AES_256_CBC_SHA256 or ANY_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 is org.apache.qpid.jms.jndi.JmsInitialContextFactory
  • jmsConnectionFactory is ConnectionFactory
  • jndi.connectionfactory.ConnectionFactory should be set to Azure server URI, something like amqps://xxx.servicebus.windows.net
  • username and password contain the SharedAccessKeyName and SharedAccessKey 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 to MyVirtualRequest - this says there will be queue named VirtualRequest in JNDI and it will be mapped to MyVirtualRequest 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:

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.