Force Remove of old WMQ Cluster information from Qmgr

If you alter your WMQ Cluster, for example change it name or change the full repository Qmgr you may see error messages in the logs.
Errors like there is no full repository cluster for cluster "Name You have renamed" and more others.

You can execute REFRESH CLUSTER() REPOS(YES) command on the partial repository Qmgrs or the reset cluster command.

If those command not work properly I suggest to clean the SYSTEM.CLUSTER.REPOSITORY.QUEUE of the full repository Qmgr. Thus after the restart it will get the latest and the correct status of the WMQ Cluster.

1. change the SYSTEM.CLUSTER.REPOSITORY.QUEUE to get disable.
2. restart the qmgr. (Because the repository queue is in get disabled mode the cluster process will failed to start and won't lock the queue for exclusive use)
3. Clear the SYSTEM.CLUSTER.REPOSITORY.QUEUE
4. Alter it to get enabled mode
5. restart the Qmgr.

This should clean the noise log messages.

Error Handling in Websphere Message Broker V6/V6.1

A major issue in the WMB message flows is the error handling.
I saw many production message flows which loose messages meaning loose business information.

WMB platform give the developer freedom and variety of the error handling but it is very important to understand how it works.

So let's begin.

You can divide the broker elements in two categories under transactional objects and non transactional. On the transactional objects the engine makes checkpoints before entering each node. Thus if exception thrown in the entered node the object that you will get will be without any changes made in the node. If you need the changed object details you need to catch it in the node (java/esql try catch code). The non transactional elements save their state and the engine don't do any rollback on them.

Transactional Objects (those who have the Input/Output prefix):

• Body - Root
  
• LocalEnvironment
  

Non transactional :

• Environment
  
• ExceptionList
  

Node's Failure Terminal

Each node has a failure terminal. Message will route to this terminal only if there was an exception in the node and the failure terminal is connected otherwise the exception will be propagated to the previous up the flow. If an error occurred downstream it won't be routed to the node's failure terminal. I don't recommend using this pattern except maybe when calling sync service like.

When developing sub flows remember to connect all the terminal of the sub flow, because during the deployment of the flow the compiler will neglect the unconnected terminals, thus if failure occurred in the sub flow and you didn't connect it the failure won't be propagated to the main flow and thus you will lose track of the error.

Try Catch pattern and Catch terminal

My suggestion is to use this pattern; you get it implicit on the input nodes, by choosing the transaction mode.
Don't forget to throw exception at the end of the catch handling if you working under transaction otherwise no rollback will be executed because the whole transaction handled successfully.
If you developing synchronized service construct indicative reply message for the caller.
Very important if you putting dump messages for logging by the MQOutput set it to non transaction mode, if not your dump message will also be roll backed by the engine and you won't see your message in the queue.
Put your tryCatch node on common business parts, divide your flows wisely.

Trace Nodes

Nice function giving you the ability to dump your trace to log files, trace or custom files. You can dump whatever you want, ${Root}, and use the ESQL function like CURRENT_DATE.
The major improvement in 6.1 version is that now you don't need to delete the trace nodes after the development you can just disable them by this command :

mqsichangetrace –n [on off]

MQInput Node error handling flow when working under transaction (otherwise the message will be discarded) and the error occurred beyond the MQInput node.

1. If catch terminal connected the exception will be propagated there. Remember to throw custom exception for the Roll back process in which all action against external sources like DB or MQ queues will be back-out.
   It is also a good place for compensation process if needed.
   

   The message will be rolled back to input queue and the back out count will be raised by one.
   

2. If failure terminal connected the and the back-out count of the message equals treshold property the message will routed there if not it will be routed to the Back-out queue (property on the input queue) and if it not set then it tries to put it on the Qmgr back out queue.
   if no back out queue exist it will try to put the message on the Qmgr DLQ.
   If error occurred beyond the failure terminal then the engine will try to resend the message twice the treshold number ( new in version 6.1) and then try to put it on the Qmgr Back out Queue and if not then on the Qmgr DLQ.
   If no success yet then the message will loop infinitely thus become a poison message and manual interfering is needed.
   

Treshhold

MQ gives you set of properties by which you can handle back out messages. You can set on the queue the back out number and the back out queue name. the MQInput node will route the message implicitly if the treshold is reached.

MQSeries 2.0 Adapter Latency HotFix

If you working with the MQSeries 2.0 biztalk adapter and letancy is your concern you definitely need to install this hotfix.
By this hotfix you change the adapter working mode from polling to event driven when receiving messages from queue.

MQ 6 on Windows 64 bit operating systems

So, is there such thing as WMQ 64 bit on 64 bit Windows platform?

I discovered that there is no such thing.
WMQ 6 on windows is great 32 bit queueing system that supports 64 bit windows platforms.
This issue doesn't exist on Linux/unix systems.

If you developing .Net application for 64 bit systems you should compile it as an x86 program and not 64 bit, because WMQ 6.0 doesn't support 64 bit and you will get several unexpected errors while compilation/ running of the program.

go to this link http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp and search for "installing on 64-bit windows operating systems" for more details.

MQ correlation set initialization in biztalk

WMQ manager can generate a unique message id (MQMD_MsgID) for you if you put message to queue with MQMD_MsgID set to null.
In MQ/MQC biztalk adapters there is a great feature to get the MQMD_MsgID after putting the message to WMQ queue using solicit response port. After putting the message to queue you get an xml which includes the MQMD_MsgID.

So if you want to send a request and get the response by WMQ you need to do the next steps :

1. Create send solicit-response port, configure it to Mqseries/MQC adapters.
2. Create Correlation Set based on MQSeries.Biztalk_CorrelationID
   
1. Add Mqseries.dll to your project, from Biztalk bin directory.
2. Create the correlation type,You can make the correlation only by the MQSeries.Biztalk_CorrelationID because the adapters update it automatically. On send to queue they copy the MQMD_MsgID to MQSeries.Biztalk_CorrelationID and on the receive the adapter copies the value of MQSeries.Biztalk_CorrelationID to MQMD_CorrelationID.
3. Initialize the Correlation set using "dummy send" port (Null/Nope adapters)
   You cannot initialize it on the receive shape like in the following orchestration , because you will get this error when compile : "in a sequential convoy the ports must be identical" .
   
   
   
   you get this error because biztalk cannot determine which message it will get first, the message of the solicit-response (receive shape which initialize the correlation set) or the message of the response followed up the Correlation set.
4. Set the follow correlation set attribute on the needed receive shape.
   
   enjoy
   
   

<

Biztalk and MQ Correlation Set with NOPE/ NULL adapter causing Race Condition.

In my integration scenario I needed to implement request/response interface between application running on Mainframe (Supplier) platform and windows (Biztalk ) . The communication between the platforms done with WMQ.

General MQ Stuff

In WMQ you have great feature for Correlation. When putting a message to a queue with MQMD_MsgID set to Null, WMQ Server generates a unique ID for this message and thus you can correlate the transaction with this MQMD_MsgID. The supplier get the message from queue, do it's stuff, sets the Correlation_ID of the response message to the MQMD_MsgID of the received message and puts it to queue.
All the client need to do is to listen on the queue for a message with Correlation_ID equal to it request MSG_ID.

Biztalk implementation

Biztalk support this way of work with it's MQSeries/MQC adapters using the solicit response port type. When issue the put to queue command with the adapter, you get the MQMD_MsgID which was assigned to your message by the WMQ Manger. The adapter copies it's also to the MQSeries.BizTalk_CorrelationId, thus you can work only with it and not using the MQMD_MsgID/MQMD_CorrelationID (on receive).

To implement this you need to do the next steps, by best practices :

1. Create solicit-response port for the destination wmq queue.
2. Create Correlation Set based on MQSeries.BizTalk_CorrelationId. this context property will be initiate automatically by the adapter with the MQMD_MsgID created by the WMQ Manager after issue the send to queue port.
   
3. Create "dummy send" port for dev null/ NOPE adapter for the Correlation Set initialization. (*)
   
4. Setting the Correlation set on the receive shape, waiting for the responce. The adapter will set the MQSeries.BizTalk_CorrelationId with the value of the MQMD_CorrelationID.
   
   (*) see my previous post on this subject.
   

The Problem

seems simple yes, but there is a huge problem in step 3 and 4 because they are not an atomic transaction.
What will happen if biztalk will get a response message prior the setting of the Correlation Set, you will get the no subscribers error, because the Orchestration did not succeeded yet to subscribe it self in the message engine for this particular message.

We got a Race Condition problem.
Yep I got it , the roundtrip of the message from Biztalk to Mainframe , suppliers work, and back took less time than the Correlation Set initialization in biztalk. Surprised I WAS too.


Solution

So to solve it I needed to write my own code for unique message id generation and set the correlation set before sending the request message with it.

Summery

Be aware of biztalk publish/subscribe latency.
On my next post I will give some tips for it optimization by administration table configuration. In this scenario it didn't help.

Biztalk 2006 MQSC adapter

Hi,

In this post I will explain the benefit of the MQSC (WMQ native api client adapter) over MQS (COM+ server adapter).

When working with wmq and Biztalk on multi server environment I suggest to work with the MQSC adapter and not with MQS adapter.

Because of the following arguments:

• MQSC Support clustered MQSeries Queue Managers.
• The MQS adapter make subscriber for each clustered queue, even if it is the same
  queue, but on different qmgr. Creates duplication of messages.
  
• MQSC Support clustered BizTalk servers.
• You can't difine with the MQS adapter a dynamic recieve loaction. Works only with local Qmgr on the biztalk application server.
• The COM+ level overhead of the MQS adapter.
• Can define by WMQ channel table file a simple fail over mechanism, using the wild char "*" in the qmgr name.
  

You can get the inforamtion about the MQSC adapter here :

http://msdn2.microsoft.com/en-us/library/aa772116.aspx

When using the MQSC adapter it is very important to set the transaction mode on (default off ) when integrating with WMQ queus. Otherwise duplication of messages can occur.