| Author |
Message
|
| Amar Tayade |
 Posted: Wed Jul 14, 2004 9:07 pm Post subject: Problem with JMS when replying to NON-JMS application. |
 |
|
Newbie
Joined: 22 Nov 2002
Posts: 9
|
My application is a Generic code so that any System can be joined to it thru MQ just changing configuration from web page on my app server . No need to change any code.
Platform : Sun Solaris/ WMQ with JMS & JNDI/ Websphere 3.5
We came across a prolem where we need to join a non-JMS application for the first time. The incoming message is in MQSTR format but outgoing reply message from my application is in MQRFH2 format . MQRFH2 format is making this message to fail at MQSI HUB( which comes into picture between these two appliactions).
I thought of setting Targetclient to Non-Jms while replying back so that format will be MQSTR but I am afraid this will change settings for already existing application to which we are replying (as code is generic)
Is there any way I can handle this without changing anything in my code.
(Thru JNDI or something ?)If not can I expect MQSI HUB to handle converstion between MQRFH2 to MQSTR ?
Thanx
Amar  |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jul 15, 2004 5:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, you can remove MQRFH2 headers using any version of MQSI that I'm aware of.
That is, I know you can do this with WMQI (or WMQIB) version 2.1 and WBIMB version 5.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Jul 15, 2004 9:10 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| MQRFH2 format is making this message to fail at MQSI HUB |
Unless the Flow is using BLOB, this should not cause a problem. WMQI fully understands RFH2 headers, and keeps them in a seperate part of the tree.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 15, 2004 11:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You are talking about a JMS application:
Change your JNDI settings for the queue.
Specify for the queue to be an MQ queue and not a JMS queue.
Check out and change the corresponding attribute in JNDI.
Had to do it manually to make it stick in WAS.
This will avoid putting the RFH2 header on the queue.
Enjoy
 |
|
| Back to top |
|
|
| kiran_tala |
| Posted: Fri Jul 16, 2004 10:57 am Post subject: |
|
|
Novice
Joined: 16 Jul 2004
Posts: 14
|
| ((com.ibm.mq.jms.MQQueue)ioQueue).setTargetClient(com.ibm.mq.jms.JMSC.MQJMS_CLIENT_NONJMS_MQ); |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 16, 2004 11:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
fjb and kiran...
Amar specifically said he does not want to change his destination type, because he doesn't want to break his JMS aware applications. He just wanted to make sure that his broker could handle the RFH2 header.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jul 17, 2004 10:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Jeff,
| Quote: |
Is there any way I can handle this without changing anything in my code.
(Thru JNDI or something ?)If not can I expect MQSI HUB to handle converstion between MQRFH2 to MQSTR ?
|
There is nothing to prevent you from having 2 JNDI definitions of the same MQQueue. One with type JMS one with type MQ.
Now when you post to the JMS one you will get the RFH2 header and posting to the non JMS (MQ) one you will not get the header.
This change is not in the queue definition it is just part of JNDI.
Thus no need to change any code.
I just hope he coded a different JMS destination for his JMS and non JMS application. If not some code changes (minor) will be required.
Looking at changes this should be less invasive than having to change the broker to handle the RFH2 header.
It will allow for his design on the broker to be unchanged and his JMS application will not need to care.
Just look up a different JMS destination as to his JMS target and his non JMS target.
No change in coding.
Thanks
F.J. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Jul 17, 2004 10:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
fjb_saper...
| Amar Tayade wrote: |
| I thought of setting Targetclient to Non-Jms while replying back so that format will be MQSTR but I am afraid this will change settings for already existing application to which we are replying (as code is generic) |
So, again... the original poster doesn't want to change his target client - as it might cause his other applications to break.
But it also might not - it depends on how they are coded - and only Amar knows that for sure!
But the big thing is, whatever broker he is also sending his messages to will understand the MQRFH2, and process it just fine. So he doesn't have to change his target client. And if he's using a transformational broker (WBIMB, WMQI, MQSI, Interchange, Workflow but NOT Event Broker or the support pack) then he should be able to remove the RFH2 header with logic inside the broker.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jul 17, 2004 10:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
fjb_saper, now his code will no longer be generic, simply responding to the Repky To info for every message coming in. How is he going to know if the current Reply Message is going to be destined for MQ or JMS? Without hard coding logic that says if it needs to go back to XYZ then ot needs a header, if it goes back to ABC it doesn't, etc.
But, if he simply always includes the header, its no big deal if a non JMS app first routes itself through WBIMB, which can add the header to the request going in, and strip it on the reply coming back. Now both the requesting app and the replying app are not changed, one of the main reason for using WBIMB.
Now, of course if his shop does not have WBIMB, is it worth spending all that $$$ if you could just hard code it for this one case? Maybe. But you KNOW that next month or year another app will have the same problem, and pretty soon your generic service style apps have so much hard coded exception code stuck in them you have defeated the whole purpose of having generic service style apps.
Both ways will work (Jeff's and fjb_saper's), but Jeff's is looking ahead long term.
My 2 cents....
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jul 17, 2004 10:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hi Peter,
No problem. Great advice.
As we are not running any broker (I guess one of those other $$$ decisions) I have no way to judge the effort of setting up the broker to discard / apply an RFH2 header.
I must confess I was looking for a quick fix to make it work now, leaving the long term fix in Amar's hand.
If the effort for dealing with the RFH2 header on the broker side is less than 5 min, you do not want to change anything on the WAS Side.
Thanks again Peter for looking out for the long term.
F.J.  |
|
| Back to top |
|
|
| Amar Tayade |
| Posted: Thu Jul 22, 2004 7:29 pm Post subject: Problem with JMS when replying to NON-JMS application. |
|
|
Newbie
Joined: 22 Nov 2002
Posts: 9
|
My apology for not replying on this forum earlier. This problem was resolved the next day during a debugging call with hub team and hence.....
There was no change from my application side. Everything was handled by MQSI hub with their changes .
I really appreciate immediate replies I got from Grandmasters.
Thanx
Amar  |
|
| Back to top |
|
|
|
|
