| Author |
Message
|
| bprasana |
 Posted: Fri Apr 15, 2011 3:59 pm Post subject: MQRFH2 in a .NET platform |
 |
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
Hi all,
There is a requirement to track a particular transaction from front end all the way along with a few more meta data like timestamp, fullmsglogindicator=y/n. etc.
Front is a .NET based application which can communicate with Integration via a MQ Q or thru http(all http requests are soap).
This needs to be done with minimal changes to the existing Payload.
I wanted to know if there are better ways to do this than then one below:
For All requests, generate a unique id and put it in MQRFH2 header along with other meta data for MQ msgs and SOAP header for http based msgs.
WMB flows do not have any validation on soap messages.
WMB 6.0 and WMQ 6.0 server and clients are used in all systems.
Also, has any used MQRFH2 like this before? is this the right approach?
Can .NET send MQ message with MQRFH2 header?
Thanks for reading thru the big post
bprasana |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Apr 15, 2011 7:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you want to handle the MQRFH2 from a non JMS environment (.NET) you might want to look into the XMS support pack. Note that since 7.0.1 this is part of the product.
As you are looking at 2 different modes of delivery it might make sense to have it in the SOAP header in all cases. This will make no difference between http or MQ.
If you need to track on a non SOAP MQ message, I agree that setting properties on the MQRFH header makes sense. It will not touch the payload. However be warned that it might hit MQClients not prepared to handle the MQRFH header (Mainframe, C, .NET etc... systems not using the XMS support pack) and that could pose different problems.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Apr 16, 2011 4:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Given that Broker 6.0 goes out of support in a week or two, it's really a good idea to put this on a backburner until you upgrade to 6.1 or 7.
Otherwise, there's no such thing as an MQRFH2 in HTTP, so you kind of have to put it in the payload if you want it in the same place in both transports.
Also, I would use MQ v7 and use message properties instead of an RFH2...
(MQ v6 has another year of support...) |
|
| Back to top |
|
|
| bprasana |
| Posted: Sun Apr 17, 2011 9:34 pm Post subject: |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
@fjb_saper and mqjeff
Thanks for the answers.
We are currently working on upgrade from 6.0 to 6.1. This is also going to production at the same time as above requirement.
But MQ upgrade is not yet planned also most of the MQ communications are non SOAP msgs. But i am curious to know if there are any known issues i need to take care of as mentioned by fjb_saper?
We currently have Mainframe,Java and .NET as end systems.
we did recommend use of IA9H for .NET platform but I am not sure for other platforms. Can someone please recommend.
This might be a silly question as i have not used MQ 7 before-
Will the use of MQRFH2 header pose any concerns when we do MQ 7 upgrade?
regards,
bprasana |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Apr 18, 2011 3:13 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bprasana wrote: |
This might be a silly question as i have not used MQ 7 before-
Will the use of MQRFH2 header pose any concerns when we do MQ 7 upgrade? |
Go to http://www.ibm.com/support/docview.wss?rs=171&uid=swg27014224 (page listing MQ v7 fixes)
Search down the page for RFH2.
Use the very latest fix pack. Do lots of testing.
As of MQ v7, the MQI and the Java classes and the .NET classes try to do things with MQRFH2 blocks, particularly if they think they were originated by JMS and/or contain MQ v7-style "properties". |
|
| Back to top |
|
|
| bprasana |
| Posted: Tue Apr 19, 2011 1:50 pm Post subject: |
|
|
Disciple
Joined: 18 Apr 2005
Posts: 179
|
Can someone tell me if the XMS support pac changes the way .NET is currently coded(It calls the MQ client APIs directly from c#).
Also do we need this support pack on broker QM as well?
I forgot to mention: All the above components along with WMB which has around 42 interfaces are all in production already. So the requirement is to change the way they are working drastically. |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Apr 20, 2011 2:59 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bprasana wrote: |
| Can someone tell me if the XMS support pac changes the way .NET is currently coded |
Hi. No, how could it do so? I might not have understood the question.
| Quote: |
| Also do we need this support pack on broker QM as well? |
Ask your architects. I don't know how we could know the answer to this. |
|
| Back to top |
|
|
|
|
