ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » JMS queue URI - Vendor app doesn't allow qMgrName

Post new topic  Reply to topic Goto page 1, 2  Next
 JMS queue URI - Vendor app doesn't allow qMgrName « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Tue Jun 08, 2021 3:35 am    Post subject: JMS queue URI - Vendor app doesn't allow qMgrName Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

I'm working on a project where the app team is using a vendor product to interface with JMS to get to IBM MQ (in this case). Everything is configured thru the vendor product's GUI config panels. On the output "node" they have a field for the Message Queue name. The app team is successfully able to populate this field with the Reply To Queue from the request and use it on the output of the Reply message.

But they cannot get the product to respect the queue manager name. We are using the following link to determine how a JMS app can provide the destination queue manager name.
Creating destinations in a JMS application
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=applications-creating-destinations-in-jms-application#q032240_

So far every combination of the following that we have tried:
Code:
queue://[ qMgrName ]/qName


Is taken quite literally by the vendor product as the name of the destination queue. I can tell this based on the Local Events being captured by the queue manager they are connecting to.

If this vendor product truly does not allow for a destination queue manager name to be used on its iteration of MQOPEN to MQPUT
A. Does this product have a defect working with IBM MQ but not necessarily other JMS compliant messaging systems?
B. Or does this product have a defect with basic JMS 2.0 requirements?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
markt
PostPosted: Tue Jun 08, 2021 4:59 am    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 502

What does "does not respect" mean? What's the actual error you are seeing? I'm not clear from what you are saying whether this is something to do with populating a replyq/qmgr or as part of the initial PUT.

That form of addressing is the equivalent to the MQOPEN(q@qmgr), so you are already connected to a "local" queue manager. Is there a route to the other qmgr named in the URI?
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Jun 08, 2021 5:14 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Have you tried using a reply to queue alias as reply to queue?
(this can be a remote queue)
Hope it helps
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
tczielke
PostPosted: Tue Jun 08, 2021 5:23 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

Here is some sample code of setting the ReplyToQmgr with the IBM MQ JMS Extensions, in case this helps:

Code:

      // Logic to provide a ReplyToQ and ReplyToQMgr to a request message.  The ReplyToQ can be
      // temporary (MQ creates it at runtime with a name like AMQ.*), or can be a real queue
      // that has been previously created by an MQ admin.
      String replyToQ = prop.getProperty("replyToQ");
      if (replyToQ != null)
      {
         javax.jms.Queue q = null;
         
        if (replyToQ.equals("temporary"))
         {
           q = session.createTemporaryQueue();
         }
         else
         {
            String replyToQMgr = prop.getProperty("replyToQMgr");
            if (replyToQMgr != null)
            {
               System.out.println("replyToQmgr property is set to " + replyToQMgr);
               q = new MQQueue(replyToQMgr, replyToQ);
            }
            else
            {
               q = new MQQueue(replyToQ);
            }
         }
         requestReply = true;
        textMsg.setJMSReplyTo(q);
        messageConsumer = session.createConsumer(q);
        connection.start();
        System.out.println("replyToQ for consumer is set to " + q);
      }

_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Jun 08, 2021 6:32 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

The application can successfully grab the Reply To Queue value from the request and use it on the MQOPEN when sending the reply.

They cannot get the app to fill in ObjectQMgrName on the MQOPEN call. No matter what syntax is used, no matter what value is provided, the vendor app treats 100% of what's provided as the value to use for ObjectName on the MQOPEN call and appears to have no provision for getting any value into ObjectQMgrName.

In JMS terms, is the concept of ObjectQMgrName and being able to populate it strictly IBM MQ or does it apply to JMS in general? Does this vendor have a defect specific to IBM MQ or to JMS in general? I want to know how loudly I can complain
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
tczielke
PostPosted: Tue Jun 08, 2021 6:39 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

The MQ manual link for setting the ReplyToQmgr name in JMS:

Quote:
Creating destinations in a JMS application
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=applications-creating-destinations-in-jms-application#q032240_


Does have this blurb/warning:

Quote:
Note that the parameter on the createQueue() method contains provider specific information. Therefore, using the createQueue() method to create a Queue object, instead of retrieving a Queue object as an administered object from a JNDI namespace, might make your application less portable.


It is possible that the vendor wanted to write completely portable JMS code, so they avoided any functionality like createQueue that would dip into the JMS provider functionality (like IBM MQ). If this is the case, it is up to the vendor on what they want to support, but you may have to stay within a design that is in the pure JMS framework and does not deviate into MQ concepts like a ReplyToQmgr.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
markt
PostPosted: Tue Jun 08, 2021 6:55 am    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 502

The concept of a remote qmgr in this fashion is MQ-only.But the app should be capable of using the string directly.

The app should be passing that URI string to a Destination constructor where it will be interpreted by the MQ JMS implementation and converted into the MQOPEN parameters.

A JMS app does not explicitly call MQOPEN or know its syntax.

To prove it, I just ran one of the sample JMS programs:

Code:
java JmsProducer -m QM1 -d "queue://QM3/X"

where "QM3" is an xmit queue defined on QM1 (I didn't bother with the rest of the path - getting the message on that xmitq and looking at it with amqsbcg was good enough). And the only MQ-specific pieces of that sample are the properties needed on the connection factory (not the destination).

Maybe you need to look at the JMS trace to see what methods are being used.

One suspicion might be things getting folded to uppercase in the app; another suspicion might be the app assuming it can use JNDI lookups and then doing something odd when that fails.
Back to top
View user's profile Send private message
tczielke
PostPosted: Tue Jun 08, 2021 7:37 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

JmsProducer has the following code for the -d option:

Code:
        destination = session.createQueue(destinationName);


The Session.createQueue Java doc has the following blurb:

https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createQueue-java.lang.String-

Quote:
Creates a Queue object which encapsulates a specified provider-specific queue name.
The use of provider-specific queue names in an application may render the application non-portable. Portable applications are recommended to not use this method but instead look up an administratively-defined Queue object using JNDI.

Note that this method simply creates an object that encapsulates the name of a queue. It does not create the physical queue in the JMS provider. JMS does not provide a method to create the physical queue, since this would be specific to a given JMS provider. Creating a physical queue is provider-specific and is typically an administrative task performed by an administrator, though some providers may create them automatically when needed. The one exception to this is the creation of a temporary queue, which is done using the createTemporaryQueue method.


Speculating, but the vendor might have a requirement to keep their JMS 100% portable.
_________________
Working with MQ since 2010.


Last edited by tczielke on Tue Jun 08, 2021 12:18 pm; edited 1 time in total
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Jun 08, 2021 11:59 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

PeterPotkay wrote:
The application can successfully grab the Reply To Queue value from the request and use it on the MQOPEN when sending the reply.

They cannot get the app to fill in ObjectQMgrName on the MQOPEN call. No matter what syntax is used, no matter what value is provided, the vendor app treats 100% of what's provided as the value to use for ObjectName on the MQOPEN call and appears to have no provision for getting any value into ObjectQMgrName.

In JMS terms, is the concept of ObjectQMgrName and being able to populate it strictly IBM MQ or does it apply to JMS in general? Does this vendor have a defect specific to IBM MQ or to JMS in general? I want to know how loudly I can complain


You should first probably look at using what is available. If you only supply the queue name the implied remote queue manager is the queue manager you're attached to. If you need to define any other remote queue manager you would have to make use of an alias ReplyTo queue. Thus you'd never have to specify the queue manager name... You could also as others mentioned create a JNDI and have MQ retrieve the JNDI objects ...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
markt
PostPosted: Tue Jun 08, 2021 11:31 pm    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 502

Passing the string through unchanged to the Destination creator IS 100% JMS compatible. Interpreting the URI string is up to the JMS provider to do.

What would not be standards-compliant is if the app is trying to do some validation or transformation on the string itself before passing it in.

But as we've still not seen any actual evidence, or real example strings, or the error data, it's hard to go any further.
Back to top
View user's profile Send private message
tczielke
PostPosted: Wed Jun 09, 2021 5:03 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

markt wrote:
Passing the string through unchanged to the Destination creator IS 100% JMS compatible. Interpreting the URI string is up to the JMS provider to do.

What would not be standards-compliant is if the app is trying to do some validation or transformation on the string itself before passing it in.

But as we've still not seen any actual evidence, or real example strings, or the error data, it's hard to go any further.


I am not saying that it is not JMS compliant to use the Session.createQueue method. However, the documentation for that method is warning that your application may become non-portable if you use it.

Quote:
Creates a Queue object which encapsulates a specified provider-specific queue name.
The use of provider-specific queue names in an application may render the application non-portable. Portable applications are recommended to not use this method but instead look up an administratively-defined Queue object using JNDI.


This is the use case here as if you call the Session.createQueue method and pass in a destination that has an embedded ReplyToQmgr, you have lost portability. This portability guidance is also found in the JMS specification, as well.

Quote:
6.2.3. Creating Destination objects
Most clients will use Destination objects that are JMS administered objects that they have looked up via JNDI. This is the most portable approach.

Some specialized clients may need to create Destination objects by dynamically manufacturing one using a provider specific destination name. Sessions provide a JMS provider-specific method for doing this.


I don't think there is anything wrong with Peter asking for the vendor to provide an enhancement to support a non-portable requirement for IBM MQ like ReplyToQmgr. However, I am just trying to provide some guidance on why a vendor would not have initially supported this as they were possibly implementing a portability requirement that is found in the JMS specification.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
markt
PostPosted: Wed Jun 09, 2021 5:29 am    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 502

Quote:
I am not saying that it is not JMS compliant to use the Session.createQueue method. However, the documentation for that method is warning that your application may become non-portable if you use it.


No it is not saying that. What it is saying is that the INTERPRETATION of the string may be provider-specific. So I would definitely not expect "queue://QM/Q" to work if the JMS provider were not MQ. Because the string format may be handled differently.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Jun 09, 2021 6:58 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

I am asking them to do another test and will share what they used to send to and what the Local Event message shows the queue manager saw.

I will ask them to use this

Code:
"queue://HIPETER/QUEUENAMEHERE"


If they get a MQRC 2085 and I see QUEUENAMEHERE that means the vendor app is getting involved in interpreting / altering the string, yes?

If they get a MQRC 2087, success! It proves the QM they connected to saw the request to send to a queue manager called HIPETER(which does not exist).
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
tczielke
PostPosted: Wed Jun 09, 2021 8:23 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

markt wrote:
Quote:
I am not saying that it is not JMS compliant to use the Session.createQueue method. However, the documentation for that method is warning that your application may become non-portable if you use it.


No it is not saying that. What it is saying is that the INTERPRETATION of the string may be provider-specific. So I would definitely not expect "queue://QM/Q" to work if the JMS provider were not MQ. Because the string format may be handled differently.


When I read your reply, I hear you disagreeing with me and then making my point with your subsequent statements, so we are clearly not on the same wave length. My understanding of JMS portability is that you avoid using things that can be provider-specific, so your JMS classes and configuration (besides the wiring to your JMS provider) can be swapped between JMS providers with no need to recompile code, change configuration (besides direct wiring to the JMS provider, etc.). Perhaps that is where we have the disagreement on the meaning of JMS portability.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
markt
PostPosted: Wed Jun 09, 2021 8:54 am    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 502

The distinction - in my mind at least - is between configurable attributes and their values.

The configurable attributes are defined as part of the application code. These can be 100% portable.
The attribute VALUES are part of the user's deployment of that application, not part of the code. These are more likely to be provider-specific, and you should expect to have to change them when moving to a different JMS provider. But they get passed through from the app to the provider, hopefully unchanged.

An app might prefer you to use JNDI as a common indirection to get to the object attribute values but it's not a requirement.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » IBM MQ Java / JMS » JMS queue URI - Vendor app doesn't allow qMgrName
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.