1

We have written a .NET application using IBM MQ XMS which listens to a queue, inspects message contents and then forwards messages to the correct queue. The message is forwarded unmodified.

BizTalk picks the message up but is leaving it in an Unparsed Interchange format with message header information in the body. Example:

RFH ... MQSTR ... <mcd><Msd>jms_text</Msd></mcd>  d   <jms><Dst>queue:///VC.AZ.BT.270.Q.5010?persistence=1</Dst><Tms>1575310018071</Tms><Dlv>1</Dlv></jms> 
   <usr></usr> ISA*00*...

If we bypass the .NET routing client and drop a message directly onto the same queue from MQ Explorer, BizTalk parses it into a Serialized Interchange format as expected. We cannot see why this header info is not being parsed out. Any ideas?

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
sac80644
  • 103
  • 1
  • 5
  • It would appear that there is something wrong in your .Net routing client, but without the relevant code, it would be hard to say what. – Dijkgraaf Dec 03 '19 at 01:23
  • See the answer to the above question for how to tell XMS not to send the default additional RFH2 header. – JoshMc Dec 03 '19 at 03:44
  • @JoshMc Worked! I was looking at how the destination was being created, just hadn't found the support doc referencing the targetClient yet. Thanks! – sac80644 Dec 03 '19 at 20:12

1 Answers1

0

Your .Net code is likely tripping significant NULLs or other non-visual characters. BizTalk will require the message to have all characters accounted for in the message header or it will fail. Use a tool like Notepad++ or UltraEdit to inspect the messages in HEX mode to be able to pinpoint where the difference is. What is the purpose of the routing client? Where is it in the message flow? Why not use BizTalk for the routing and cut out the offending program?

silverbugg
  • 214
  • 2
  • 7
  • The issue was solved by setting targetClient=1 in the destination removing the additional RFH2 headers as explained above. Thanks. – sac80644 Dec 03 '19 at 20:10