Skip to Content

JMS channel custom RFH2 header settings

Hi Folks,

This blog has been entered with the aim of enabling anyone to set the JMS settings in sender and receiver channels easily and testing it using rfhutil.

Before i go into the technical details, I would like to give a background of why such a blog.

The requirement is that i need to send a request from MQ to R3 via PI and a response should be received to MQ for the request, with a correlation to the sending message(meaning using the identifier in the sender message as a reference).

But i do have a few constraints though:-

  • The correlation can not be any of the standard options provided by PI(like JMS correlation ID, JMS message ID.. etc ). This is because the sending application can not recognize any other header other than the one it currently uses. In my case, something called a batchId.
  • I can not use synchronous messaging reason because i would need to restart the messages on failure.
  • I can not use a BPM if at all that does make a difference :P.
  • Last but never never the least, I am not familiar with the tool that i use for testing -rfhutil. This last point may not look that relevant, but in my case when i was not aware if it was my testing or my development that was wrong, it actually stood out to be the most important 🙂

So here goes the technical side of things…

Actual Technical requirement :- MQ sends a message with a custom RFH2 header into PI, after which it reaches R3. R3 receives it and sends back a response setting the header with the same value taken from the request.

Custom header structure :- samplevalue

Total input message structure :- samplevalue..actual message..

JMS sender channel settings:-

Create a JMS sender channel as we do normally, except that we have to use “JMS-Compliant” as target client in the processing tab as shown below :-


Please find a paragraph from the SAP note 1086303 which tells us the reason why -“Websphere MQ has the limitation that its support for message properties is complete ONLY in JMS compliant mode. MQ has two modes – legacy/native mode and a JMS compliant mode. The difference between these two modes lies in the presence of an extra MQ message header – the MQRFH2 header – that is present in JMS compliant messages. (Please see references). Without this header, an MQ message cannot support custom JMS message properties.”

The next change is in the Advanced tab to set ASMA. Here we fill in the check box for “Specify Additional JMS Message Properties (10 Maximum)”, and add the custom field in usr, i.e in our case “batchId”. Please note that we can add as many as to 10 properties in this table. The technical names start with DCJMSMessageProperty0 and go on till DCJMSMessageProperty9

Please find the screenshot below.


Now the last thing. Whether we need dynamic configuration? We surely need dynamic configuration. No doubt on that. The only question is where we do it. Usually if we have an operation mapping, we do it there. Otherwise we make it in the channel modules. Please note that it may be done either in operation mapping or in channel modules depending on the availability of mapping. We DO NOT NEED BOTH.


Please find the code if we are using an Operation mapping dynamic configuration :-


DynamicConfiguration dynamicconfiguration = (DynamicConfiguration)param.get(“DynamicConfiguration”);
            DynamicConfigurationKey dynamicconfigurationkey = DynamicConfigurationKey.create(““, “DCJMSMessageProperty0”);
            String s = dynamicconfiguration.get(dynamicconfigurationkey);


Else If you do not have a mapping and want to go for the channel configuration for dynamic settings, please find the screenshot below :-


Module Key — Paramter Name — Parameter value
RFHHEADER — key.0 — read DCJMSMessageProperty0
RFHHEADER — value.0 — batchId

Now thats all for sender settings. We have a similar setting for Receiver channel settings. This you would most probably see in other blogs and forum questions. However i have put a few screenshots just for your easy reference.

JMS receiver channel settings:-

Create a JMS receiver channel as we do normally, except that we have to use “JMS-Compliant” as target client in the processing tab as shown above :-

Again, if we have operation mapping we can use the below code :-


  DynamicConfiguration conf = (DynamicConfiguration) container.getTransformationParameters().get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);
  DynamicConfigurationKey key = DynamicConfigurationKey.create(““, “DCJMSMessageProperty0”);
  conf.put(key, BatchID);
  }catch(Exception e)
   trace.addInfo(“BatchID Exception”);


Else, we can go for channel configuration as shown in the screenshot below :-

Please note that, during channel configuration, we can either take a value from the message or put a constant value. Eg:- In a case where you want the value of the field batchId in the message to be set in the header, you may use message.batchId. In another case where you want to set a constant value, for example “123” in the header you may simply use “123” instead of message.”field”.

With this, I would like to end the discussion on PI channel settings. This should work now.

Now something which is very very relevant as in my case – Using the rfhutil tool 🙂

I am not sure as to how many people actually use it. However I have just given below the settings that i gave so that the custom header is read by PI when i sent a message.

As a first note, I would like to make a point that if you feel that none of your settings are being read by the sender channel, whatever tool you are using, start ahead with the receiver(if or if not required in your scenario). The reason why i say this is because we can spend lesser time in setting a receiver configuration and testing it rather than trying different kind of settings in your sender testing.

Please find how to test the message in rfhutil screenshots below :-




Ok guys.. with this i come an end of this blog. I would give a huge thanks to Raja Sekhar Reddy and Abhishek Salvi who have helped me conquer this scenario. And a bigger thanks to my supervisor Narendra Kuchipudi who advised me to use the receiver scenario as a guide than to keep surfing, looking for the right settings 🙂



1 Comment
You must be Logged on to comment or reply to a post.