I have a Java JMS application that reads messages from a MQ queue. My application can successfully read a message and pull out the JMS headers (e.g. JMSDeliveryMode, JMSPriority etc) and the message body, but I can not access the <usr> folder part of the message.
I am placing messages on a queue using RFHutil. Under the RFH tab I am ticking 'Include RFH V2 Headers' and 'usr', and under the usr tab I have test1=1. I can see the <usr><test1>1</test1></usr> in the message if I browse the queue using MQExplorer, so I think I'm setting the usr folder correctly.
I have outputted the whole of message.getPropertyNames() enumeration (as discussed at topic JMS passing entire Application data <usr> block, but my usr fields are not under there. My message body also does not contain my usr fields.
I've also read on the MQ v7 info center you need to set WMQ_MESSAGE_BODY to WMQ_MESSAGE_BODY_MQ, but I am using v6MQ and do not know if this is relevant/how to set this value.
How can I get access to the usr folder using the JMS API?
Any help/pointers would be much appreciated as I am fairly new to JMS programming.
A first question is why is the USR folder of importance? Are you attempting to get your JMS application to interoperate with messages that put using another application that writes custom RFH2 headers.
RFHUtil is primarily used for test purposes.
MQ JMS originally used the RFH2 heasder to specifically send the JMS properties. Therefore the MQ JMS code reads the message, removes the RFH2 and processes it into a full JMS Message.
If you want the JMS API to fully read the RFH2, then the properties for reading the MQ message you've highlighted are correct. However those are not in MQ v6. Be aware that mq v6 and V7.0.1 are now out of support. Would strongly recommend that you investigate upgrading to MQ v8 - at minimum MQ 7.5.
CLients are freely downloadable if you are a developer and connecting to an estbalished QueueManager. Client versions don't have to match the QM.
Related
I am newbie to Websphere MQ and i have some basic understanding on the concept of MQ. I know that MQ client would create a message (with MQMD and application data) and then send to MQ manager. MQ client will get the correct response back from MQ Manager. Supposedly there are many messages on the MQ Queue Manager, how does MQ client able to retrieve the right messages? What determines the uniqueness of a MQ message?
There are different ways this can be approached - one common way is for the applications processing the messages to use the message ID and correlation ID fields. The message ID can be randomly generated and saved then copied to correlation ID field to be match when the reply is sent. Applications can do gets matching on those fields in the message header.
I suggest you read through the application programming guide and reference in the knowledge center.
I have setup a topic to MQ messaging. The setup is done like in the documentation "MQ Connectivity scenario 2: Fan in per device notification" it appears as though Messagesight adds data the the message when it arrives at MQ destination. (possibly JMS header data). Is there something that has to be setup either on messagesight or MQ manager to remove the data and only leave the message?
I have a WebSphere MQ FTE file to queue transfer in which I am splitting a file to multiple messages using delimiter, when I check messages on queue all messages share same WebSphere MQ group ID. Now my problem is when I try to write those messages back to file, instead of creating multiple files fte create only one file with all messages.
What you are trying to do is not possible with WebSphere MQ FTE. When performing a file-to-message transfer, all the messages will have the same group id (as you observe). This is mentioned in the WebSphere MQ FTE Infocenter here:
http://pic.dhe.ibm.com/infocenter/wmqfte/v7r0/topic/com.ibm.wmqfte.doc/f2m_simple_split_delim.htm
Then when you perform a message-to-file transfer, the WebSphere MQ FTE agent will use the message group id field on a transfer to ensure it has consumed all the messages for that transfer. So, on the second stage, all of the messages that were created by splitting a single file are written back to a single file.
I think you will need to raise an RFE (Request for Enhancement) on the IBM DeveloperWorks website for IBM to consider if you require this functionality in WebSphere MQ FTe/MFT:
http://pic.dhe.ibm.com/infocenter/wmqfte/v7r0/topic/com.ibm.wmqfte.doc/resource_monitoring.htm
I have a program which publishes data to IBM Websphere MQ via the MQAX200 interface. I'm struggling to work out how to test it.
What's the simplest way of setting up an application to consume the messages from the queue and confirm they're correct? I don't currently have any MQ infrastructure here (that's on the client's site).
Do I need a message broker? Are there any open source implementations? Or do i need to purchase Websphere MQ, in which case what's the minimal license I'd require?
Thanks
Ben
As your application is written using a MQ interface, you need MQ to test. If it's just for testing, you can use the trial version of MQ.
As far as I know MQAX200 interface supports only P2P messaging and not Publish/Subscribe messaging. So using your application put message to a queue and then use the application like amqsgetto receive message.
You don't need message broker.
First, you need to clarify what it is you are trying to do. If you are publishing messages then your test program will need to subscribe. If you are putting messages into a queue then your test program will need to GET messages from the same queue.
The WMQ Trial Download will get you a 90-day WMQ license for no charge. The trial code includes the server and the client libraries so you can set up a QMgr and then test your program in client or bindings mode, as appropriate. If you elect to install the sample code you also get compiled binaries with which you can test. For example, amqsget gets messages and amqssub subscribes to topics, both using bindings mode (shared memory). The client versions of these (amqsgetc and amqssubc) attach over the network. If you are using topics, make sure to subscribe before you publish. If using queues, make sure to GET after you PUT.
Other useful programs include amqsgbr to browse messages on queues and amqsbcg which will hex-dump the messages and parse the message headers. Also, WMQ Explorer comes with the Windows and Linux versions of the trial and you can use that to browse, subscribe or get messages.
Just write a simple Java JMS program that subscribes to the Topic. THen you only need to install the free WebSphere MQ Client.
This article is a bit old but should do.
I am sending messages to a remote queue, to which I have no control.
I send a xml file as message but when the application reads the message it gets a message header like
<mcd><Msd>jms_text</Msd></mcd> \0\0\0l<jms><Dst>queue:///TEST</Dst><Tms>1281475843707</Tms><Cid></Cid><Dlv>1</Dlv></jms>
i don't want this message header to be present and my code for sending this message is as follows:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial",this.initialFactory);
props.setProperty("java.naming.provider.url", url);
Context context = new InitialContext(props);
QueueConnectionFactory qcf = (QueueConnectionFactory) context.lookup(this.context);
qConn = qcf.createQueueConnection();
queue = (Queue)context.lookup(name);
qSession = qConn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
qConn.start();
QueueSender send = qSession.createSender(queue);
String text = "My xml file";
TextMessage tm = qSession.createTextMessage(text);
send.send(tm);
send.close();
How do I avoid this ?
It appears that you are sending a jms message to a non jms destination. How is the message being consumed on the destination? Is it expecting a native MQ message? The receiver is not understanding the MQRFH2 header that stores the JMS header properties.
You should either configure the destination to understand jms or your can do something like the following to tell the mq jms that your receiver is a non-jms client.
((com.ibm.mq.jms.MQQueue) queue).setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);
Have a look at the properties for JMS objects as listed in the docs. On the administered object there is a property called TARGCLIENT which should be set to 'MQ'. Although you may have no control over the administered object, it is the responsibility of the person who administers the managed objects to set this property correctly. If the destination does not understand the RFH2 headers (which WMQ v6 uses to hold JMS properties) then any WMQ JMS applications which send messages to that destination must have that property set.
Incidentally, the fact that you are having this problem tends to indicate that the application consuming messages is still at v6. Please be aware that v6.0 of WMQ is end-of-life as of Sept 2011. If you switch to v7 now at both the QMgr and the client side, you can manage this with simple settings on the queue itself. The legacy app will understand the messages regardless of whether they have an RFH2 attached and the client app will see the responses as JMS messages regardless of whether the legacy app adds RFH2 headers. Move to v7 now, save your self a whole lot of trouble developing this app and also avoid having to migrate to v7 next year.
WMQ v7 client downloads are available here
Update: End-of-life for WMQ V6 was pushed back to September 2012.