Skip to main content

HermesJMS connecting to MQ 8+

I have naturally looked over a number of blogs and forums on this subject whilst attempting to set this up, but I have yet to see a complete set of instructions. There always seems to be a corner cut somewhere. Naturally, I don't want to bunk this trend, but hopefully, I will cut one or two less corners.

Having said that, I do not intend to cover MQ or HemesJMS (nor indeed any of the other topics that arise, such as PKI/SSL) in any more depth than is required to specifically set up their connections. I am happy to cover these (with the exception of HermesJMS, which I know little of) in later posts.

Happy reading! ...

First of all, I did this within SoapUI 5.3 with the embedded HermesJMS. This was a Windows install of SoapUI, but I expect both the SoapUI and HermesJMS specific instructions will translate fairly well on to UNIX.

Secondly, in the spirit of my opening paragraph I am going to do this over SSL. I will use server authentication only (and not mutual authentication) - however, mutual authentication  simply requires a key store which is set in exactly the same way as the trust store (minor googlable differences in the Java system property names) and SSLCAUTH set on the server connection channel.

To carry this out, you will minimally need HeremesJMS and the MQ 8 or above client installed on the client machine.

1) Within the SoapUI install directory, you will find a sub-directory called HermesJMS\bin.

In that directory there is a batch file called hemes.bat. Edit this to set 3 things:

- The JRE binary directory in the system PATH, e.g.

set PATH=C:\Program Files\IBM\MQ\java\jre\bin;%PATH%

- The Java home directory, e.g.

set JAVA_HOME=C:\Program Files\IBM\MQ\java\jre\

- Any required system options for the JVM (e.g. trust/key store), e.g.

start "HermesJMS" "%JAVA_HOME%\bin\javaw" -XX:NewSize=256m -Xmx1024m -Dhermes.home="%HERMES_HOME%" %HERMES_OPTS% -Djavax.net.ssl.trustStore=C:\ssl\keyStore.jks -Djavax.net.ssl.trustStorePassword=password  ...

(assume ... is the rest of the usual options found in the batch file)

You will notice that I have chosen to use the MQ JRE above - or more specifically IBM Java 8. This is for two reasons; it is compatible with HermesJMS (though not SoapUI) and seems to work with MQ SSL in this context. Unfortunately, Oracle's Java 8 was less successful with MQ SSL - another mystery.

2) If you plan to use a cipher with greater than AES128 encryption strength, as I do, you will need to find and download the Unrestricted SDK JCE policy files for IBM Java 8.

Unzipped, these should be used to replace 2 of the policy files in the equivalent directory to

C:\Program Files\IBM\MQ\java\jre\lib\security

3) Within SoapUI, update the following preferences to point at the HemesJMS installation directory.




you should then be able to invoke HermesJMS for the SoapUI Tools menu. (I think this may have been in the Files menu in previous releases - hunt around, you'll find it.)

4) Once the HemeseJMS Browser starts, create a new session and called it MQSession, for example. Switch to the Providers tab.




5) Right click and "Add Group", give the group name MQ, say. Right click on "Library" and click on "Add JAR(s)".

Navigate to C:\Program Files\IBM\MQ\java\lib (or equivalent) and choose com.ibm.mq.allclient.jar (this bundles mqjms.jar and a bunch of others in MQ 8+)



6) Flip back to the Sessions tab and update the following:

a) On the Connection Factory section, choose com.ibm.mq.jms.MQConnectionFactory from the Class drop down list and MQ for the Loader.

b) Right click within the Connection Factory space and Add Property (do this for each property you set).

c) Set an SSLCIpherSuite property (if your using SSL) and set this to the cipher suite that is equivalent to the cipher you set on your MQ SVRCONN. See the table in the following topic of the MQ KC SSL/TLS CipherSpecs and CipherSuites in IBM MQ classes for Java.

d) Set the SVRCONN channel name, hostName, port and transportType, as below. (Note that the cipher suite name begins SSL_ for this cipher, as opposed to to TLS_ used in the cipher spec for the MQ channel property SSLCIPH.)



e) Additionally - because you haven't tuned client authentication off on the queue manager (shouldn't turn it off), that's be silly - fill in the User and Password, as above (you'll need to check the checky box).

f) Add and edit your queue destinations, as above.

You should now be able to right click and browse your queues or from the HermesJMS Messages drop down menu Send (put) messages to the queue. I personally found that I was not able to Discover... queues via my session - the queue manager reported that no cipher had been sent in that case. Perhaps somebody out there can solve that mystery.

Enjoy!








Comments

Popular posts from this blog

Linux systemd for integration nodes as well as MQ?

So, in the tips and tricks that are out there, you will find suggestions on how to set up an MQ queue manager as a systemd service. Here is a quick refinement for a slightly more robust version and the inclusion of an IIB (or ACE) integration node.   The following shows the necessary settings and commands (and tests the service). This works with integration nodes that are associated with queue mangers of the same name. (A practice I have personally adopted for a good few years - for numerous good reasons, including the fact that is simple to remember.) These are scant notes, but you should be able to 'read between the lines'. Enjoy!  crtmqm -ld /var/mqm/log -md /var/mqm/qmgrs -lf 16384 -lc -lp 5 -ls 5 -u SYSTEM.DEAD.LETTER.QUEUE TEST strmqm TEST mqsicreatebroker TEST -q TEST -w /var/mqsi -o advanced -s inactive endmqm TEST Switch to root: su - intadm belongs to mqm (primary group) and mqbrkrs vi /etc/systemd/system/mq@.service [Unit] Description=IBM MQ queue manager %I After=ne

MQ tuning the persistent queue buffer with NewPQBufferSize

In the course of writing a health check for MQ and IIB this week, I was reminded of some log tuning mystique that we resolved at Hursley concerning queue buffers. As detailed elsewhere, DefaultQBufferSize is the TuningParameters stanza value that determines the size of the non-persistent buffer of a queue. The queue's non-persistent buffer will adopt the size of this parameter based on the value this was set to in the qm.ini when the QM was last started, but before the queue was created. If this value is not set in the qm.ini at that time, then the default value is 128KB. So far, this is pretty much aligned with the 'received wisdom', as long as you looked under the right stone. What is not generally known is that the queue persistent buffer 'equivalent' is not DefaultPQBufferSize (which I will describe shortly), but NewPQBufferSize! NewPQBufferSize: The persistent buffer of a queue will be set to whatever value was when the QM was last started and before the queue

PKI (SSL) connection setup of client MQ and IIB tooling - Rfhutil

  This series of walk-throughs is intended to provide some guidance to developers to set up their client tooling connections, by means of example, where PKI (public key infrastructure) is employed with MQ and IIB endpoints. PKI is generally used to distinguish an SSL infrastructure from an environment where self-signed certificates are employed as personal certificates. Self-signed certificates are a quick and easy way for a developer to practice with some of the SSL aspects of their code, but are not recommended for a full Development environment and certainly not for Production. Why would one employ PKI in a Development environment? The simple answer is that there are differences and the sooner those differences are got to grips with in the development cycle the more rapid and successful the adoption of PKI will be. Following that preamble, I should add that the details of how to build and manage PKI are detailed elsewhere. (Management being far more the tric