BizTalk 2013 & MQ server integration via HIS 2013
Configuration :- Windows server 2012 standard, BizTalk Server Enterprise 2013, HIS 2013, MQSC adapter, MQ Client v7.5.
IBM MQ server 7.0.1.9 installed in remote machine.

Outbound interface is working fine i.e BizTalk is able to post messages to the remote MQ server queue.
However, while trying to consume message from MQ server, BizTalk deletes the message from the queue (meaning the read() method is called), but the message is not shown inside the BizTalk infrastructure (not present in suspended queue, any eventlog message or tracked service instances).

For testing purpose, we used rfhutilc tool to put() messages to the queue lets say "Queue A". When we do this, the message is posted to the Queue A successfully, but unable to consume via BizTalk (but message gets deleted from the queue when we enable the MQSC receive location).
Again, we tried to put the message into the MQ server queue using BizTalk outbound interface and it successfully puts the message. However, when i enable the BizTalk receive location pointing to this Queue A, it successfully consumes the message. This is a very wierd behaviour.

We dont have the previlege to look at MQ server trace logs (as its hosted by another partner). Any help regarding this would be great.
January 6th, 2014 10:20am

This doesn't seem to be something that we have run across based on the checking I did with an engineer that works with BizTalk Server and the MQSC Adapter much more than I do. I would suggest that you open a support case as we will likely need to get traces of the problem as well as details about your configuration.

Thanks...

Free Windows Admin Tool Kit Click here and download it now
January 11th, 2014 12:04am

Hi,

I know that there have already been issues in the past using the MQ Client 7.5 together with the MQ Server 7.0.1. As the MQSC must be installed in a specific order to make it work successfully. Have you installed it in this way :

  1. BizTalk Server Enterprise 2013
  2. HIS 2013
  3. MQ Client (please try the latest MQ Client 7.0.1.11) : there have been a lot of issues fixed for .Net

Are you using the MQSC Adapter with Transactional Support ON ?

Best Regards,

January 22nd, 2014 6:03am

Thanks for the reply Steve. The HIS 2013 Installation Guide (http://download.microsoft.com/download/5/6/3/5638D97C-A249-4981-B35D-DE6C4B2B4695/HIS_Installation_Guide.htm) states the following:

BizTalk Adapter for WebSphere MQ

WCF Channel for WebSphere MQ

IBM WebSphere MQ V7.5 or V7.1 (Client, Extended Transactional Client, or Server)

According to the above information, MQ client v7.0.* is not supported. Does it also apply for MQ server v7.0.*? For testing purpose, we've tried the versions of 7.0.*, 7.1.2, 7.1.4, 7.5.

Outbound functionality is working for MQ client v7.1.4 & 7.5

Certificate not installed issue is coming for other versions (which was fixed in 7.1.4 supportpac).

We've tried with both Transaction Support ON & OFF. Same issue!

I installed in the following order :- 

1. BizTalk 2013

2. MQ Client

3. Repair BizTalk 2013 installation

4. HIS 2013.

The issue is wierd for the fact that Outbound interfaces are publishing the messages to the queue, but inbound files are not consumed by BizTalk from the queue.

Free Windows Admin Tool Kit Click here and download it now
January 22nd, 2014 11:14am

Strange !

And there's no error in the Windows Event Log or/and in the WebSphere MQ Folder ?

Have you already tried to build a simple .Net application that uses the WMQ Class from the IBM MQ Client Software to consume the queue ?

Best Regards,

January 22nd, 2014 11:59am

Really appreciate the prompt response!

No, there are no errors in eventlog/errors in websphere MQ folder.

We've built a .Net app that picks the files from MQ successfully. Thats the stop-gap arrangement as of now.

However, file does get deleted from the queue when we enable the MQ receive location. But no trace of the file in "tracked service instances", no eventlog entry/errors.

I tried enabling various trace options in HIS 2013 SNA manager (via  Tools -> SNA Trace Utility) Is there any particular trace/debug option(among various options available) specific to MQSC adapter to log error/traces?

Free Windows Admin Tool Kit Click here and download it now
January 23rd, 2014 1:15am

You're welcome !

That's strange that nothing is logged in the error subfolder of the IBM Websphere MQ folder.

If there's no error message, is you MQSC configured correctly ? Could you post your MQSC binding ?

There's no particular trace available, except EventLog or IBM Websphere MQ Log.

From an architecture point of view : BizTalk --> MQSC (Host Integration Server) --> IBM Websphere MQ Client

Have you already tried a basic BizTalk Application that only consumes a message from a queue and puts it in a Windows Folder ? Only to be sure that there's no error in you BizTalk Application.

Best Regards,

January 23rd, 2014 6:26am

Error subfolder of the IBM Websphere MQ folder (created during installation of MQ client and Hosted in BizTalk server)" is not updated. I tried consuming a message now just to double confirm this.

What boggles me more is that as mentioned in my 1st post, when I send an outbound message to the queue via BizTalk and point my receive location to this queue, BizTalk consumes message but throws error in eventlog about unable to parse message (due to some special characters getting appended to the message during transmission). But when I upload the message using rfhutilc tool or external partner uploads the message to the queue, it disappears without any trace.

Apart from our usual BizTalk app, we created a test BizTalk app just to check the message flow (basic passthrough receive), but still no trace of the message and no log entries.

Am not sure what you mean by MQSC binding. Are you referring to MQSC connection string in receive location or any other specific binding file?

Free Windows Admin Tool Kit Click here and download it now
January 23rd, 2014 4:42pm

Hi,

When a message is consumed by BizTalk from a receive location, it is parsed to an XML Document. Everything that is stored temporally in the BizTalk Message Box is XML. So I think that there are special (strange) characters in the message that is in your MQ Queue.

The MQSC Binding is in your BizTalk Application Binding --> Right click on your Application --> Export Binding

Have you already tried with another Character Set (Encoding) in your Receive Location MQSC Configuration, like UTF-8 ?

Best Regards,

January 24th, 2014 6:19am

Hi Steve,

The special characters appear only when we transmit the message using BizTalk to MQ. Its visible when we browse the message using rfhutilc tool. However, when we upload the message via rfhutilc, the special characters dont emerge.

Also, there is nothing wrong with MQ binding since i feel BizTalk is able to communicate to MQ as the message is deleted as soon as i enable the MQ receive location. Yes, we've tried UTF-8 in BizTalk receive location MQ properties, but still no trace.

Regards,

Bharath.

Free Windows Admin Tool Kit Click here and download it now
January 24th, 2014 8:33am

We have had a problem reported with the HIS 2013 MQSC adapter where under certain conditions the MQSC adapter passed a zero-length stream to a BizTalk Pipeline. I'm wondering if you are seeing something similar. The scenario was described as follows:

The conditions we have found is when a message is delivered with format MQHRF2 and encoding 273 (eventually others too) to the receive pipeline. Headers are extracted from the MQ message and written to the message context. The problem arises when Int Fmt is UNIX or Host.

If they use RfhUtil to read the message, it works. Also, if the message is sent with different encoding, it works as expected and the message is delivered. They also found that setting the Receive Location configuration property Data Offset For Headers to No results in the message being delivered with the headers included in the message and this is no matter what encoding is used.

Does any of this sound similar to your setup/scenario?

Thanks...

 

January 24th, 2014 4:20pm

Hi Stephen,

I tried setting  Data Offset For Headers to both "No" & "Yes". Still not receiving any message in either conditions. Can you please clarify what you mean by " Int Fmt is UNIX or Host." The actual scenario is to receive zip file, but we're unable to receive even xml files (with utf-8 encoding). I can confirm it is in MQHRF2 format.

You mentioned MQSC adapter passes zero length stream, was the message received transaction (Receive pipeline) visible under "Tracked service instances"? Because in my case, its not visible.

Regards,

Bharath.


Free Windows Admin Tool Kit Click here and download it now
January 27th, 2014 9:31am

The best course of action at this point is to open a support case with the Microsoft BizTalk Server support team. The BizTalk Team supports the MQSC adapter so this would be the faster way to get to the bottom of this issue. It appears that this will entail getting diagnostics for us to analyze and possibly details about the environment so that we can try to reproduce the scenario internally.

Thanks...

January 27th, 2014 7:48pm

Stephen,

We have a similar issue of when we have a message coming in from MQSC with encoding of 273 , BizTalk 2013 is getting a zero length file.

Did you get a fix for this issue form Microsoft?

It would be really great if you could reply and let us know.Thanks

Ganesh Paduvary

Free Windows Admin Tool Kit Click here and download it now
April 7th, 2015 11:29am

The fix you are referring to is included in HIS 2013 Cumulative Update 2. See the following for details on HIS 2013 CU2:

http://support.microsoft.com/en-us/kb/2929767

The specific MQSC fix is described in the following:

http://support.microsoft.com/kb/2925059

Thanks...

April 7th, 2015 11:39am

Thanks Stephen.

That fixed the issue.

Free Windows Admin Tool Kit Click here and download it now
April 8th, 2015 4:18pm

Thanks Stephen.

That fixed the issue.

  • Proposed as answer by GaneshPaduvary Wednesday, April 08, 2015 8:17 PM
April 8th, 2015 8:17pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics