The project I'm currently working on is going to make heavy use of IBM WebShere MQ to send messages from BizTalk to the client's iSeries box. I'd never previously worked with WebSphere MQ, so I didn't really have any idea what it would take to get this to work. I was pleasantly surprised that it wasn't too difficult to configure a send port and pass messages through it to a queue. Or so I thought...
A couple of weeks ago, the client gave me the name of a host, queue manager and queue that I'd been using for my development. Everything was going great, I was able to put messages onto the queue, I was happy, the client was happy. Life was good. Then the client tells me that the host I've been connecting to is actually a Solaris box and that in prod, we'll actually be sending to an iSeries. We both agree that it would behoove us to start pointing my dev environment to their dev iSeries box in order to flush out any weirdness there might be. As it turns out, it was a good thing we made the change.
As soon as I reconfigured my BRE policy that sets endpoint information to point to the iSeries queue, we started seeing failures in the event log. An example from the event log:
Event Type: Error
Event Source: BizTalk Server 2009
Event Category: BizTalk Server 2009
Event ID: 5754
Date: 6/9/2010
Time: 10:16:41 AM
User: N/A
Computer: WINDOWS2003
Description:
A message sent to adapter "MQSC" on send port "<my dynamic sendport name>" with URI "mqsc://client/tcp/<hostname>(1414)/<queue manager name>/<queue name>" is suspended.
Error details: Failure encountered while attempting to open queue. queue = <queue name> queueManager = <queue manager name>, reasonCode = 6124
MessageId: {76825C7C-611A-4A56-8A6F-35E1124BDB5C}
InstanceID: {BA389103-DF9B-493F-8C61-44574822AAD6}
The key piece of information in the event entry is the reasonCode, 6124. A quick Google search shows that reasonCode 6124 is the code for MQRC_NOT_CONNECTED. According to IBM's docs, this means that you've tried to send a message without first opening a connection to the queue manager. Obviously, in the context of BizTalk, this is an unexpected error, since this sort of thing should be managed entirely by the send adapter.
Perusing IBM's documentation a bit more, I came across some info on how to turn on tracing for MQ. With tracing enabled, I tried sending a message again, then went and reviewed the trace files. The bulk of the information in the trace files didn't mean a thing to me, but at the end of one of the files, I did notice this:
00006257 15:40:20.327795 3500.4 RSESS:000009 ------{ reqReleaseConn
00006258 15:40:20.328714 3500.4 RSESS:000009 ------} reqReleaseConn (rc=OK)
00006259 15:40:20.328727 3500.4 RSESS:000009 ------{ xcsClearTraceIdent
0000625A 15:40:20.328739 3500.4 : ------} xcsClearTraceIdent (rc=OK)
0000625B 15:40:20.328752 3500.4 : -----}! trmzstMQCONNX (rc=MQRC_NOT_AUTHORIZED)
0000625C 15:40:20.328765 3500.4 : ----}! MQCONNX (rc=MQRC_NOT_AUTHORIZED)
0000625D 15:40:20.328766 3500.4 : ---}! ImqQueueManager::connect (rc=MQRC_NOT_AUTHORIZED)
0000625E 15:40:20.328767 3500.4 : --}! ImqObject::open (rc=MQRC_NOT_CONNECTED)
0000625F 15:40:20.328768 3500.4 : --{ ImqQueue::lock
00006260 15:40:20.328769 3500.4 : --}! ImqQueue::lock (rc=Unknown(1))
00006261 15:40:20.328769 3500.4 : --{ ImqQueue::unlock
00006262 15:40:20.328769 3500.4 : --}! ImqQueue::unlock (rc=Unknown(1))
It seemed like the MQRC_NOT_CONNECTED error was being caused by a security related issue (MQRC_NOT_AUTHORIZED). I did notice something earlier in the log where it appeared that MQ was passing a field named UID with a value equal to the account name that my BizTalk service was running under. I ended up creating a new local account on the BizTalk server that had the same name as a user which had access to the queue manager on the iSeries. I then created a new host instance that ran under this new account, created a send handler for the MQSC adapter on this new host instance and reconfigured my orchestration to run on the new host instance. After bouncing all my host instances, I was now able to send messages to the iSeries.
It's still not clear to me why we were able to connect to the Solaris server. I ended up contacting IBM's support and they did confirm that the process sending to MQ does in fact pass the identity to the queue manager it's connecting to.
