| Author |
Message
|
| MCardinal |
 Posted: Wed Oct 06, 2010 11:04 am Post subject: VB .NET connecting to a remote queue manager on a network. |
 |
|
Novice
Joined: 06 Oct 2010
Posts: 18
Location: Ottawa, Canada
|
Hi,
I have been looking over many books, pdf and web article in the past days and I hope someone will be able to give me a good answer.
First I'm new with Webpshere and it's development platform. I was hoping to develop an application in VB .NET.
This is the step I can't get through. Connect to a remote queue on a server on my network.
This is my simple code
**************************************************
Imports IBM.WMQ
Imports IBM.WMQ.MQC
Public Class Form1
Private Sub Form1_Loadd(ByVal sender As System.Object, ByVal e as System.EventArgs) Handles MyBase.Load
Try
MQEnvironment.HostName = "Myserver"
MQEnvironment.Port = 1414
MQEnvironment.Channel = "APPLICATION.NET"
MQEnvironment.UserId = "MUSR_MQADMIN"
DIM qmgr As New MQQueueManager("THE.REMOTE.QUEUE")
Catch ex as MQException
MsgBox(ex.Message)
End Try
End Sub
End Class
********************
This code returns error MQRC_Q_MGR_NAME_ERROR as it doesn't find the host or queue at all. Logs on the server doesn't indicate it's trying at all to connect.
If I replace THE.REMOTE.QUEUE with THE.LOCAL.QUEUE it will connect without any problem. I have tested using the same code with a bogus port number and it does connect anyway to my local queue as if it ignores all the MQenvironment parameters except UserId.
I have registered the .Net classes and I'm not sure if I have to install SOAP or something else.
For the sceptics yes it does work and using the C sample all amqscnxc -x MYSERVER -c APPLICATION.NET THE.REMOTE.QUEUE will return Connection established to the queue manager THE.REMOTE.QUEUE
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Oct 06, 2010 11:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, let's be clear on a few terms:
Local means the queue manager to which you're connected. This queue manager could be a different one to the one on which your application is running. Remote is something on any other queue manager.
A remote queue is a specific object, hosted locally, which points to a queue hosted on a different queue manager and doesn't allow all the functions of a locally hosted object (for instance you can't read a message with an application from a remote queue object).
So to connect to a "remote queue on a server on your network" you either connect to the queue manager that hosts it over the network or get your local queue manager to pass messages for you.
Now queue managers are not typically called "THE.REMOTE.QUEUE", but many queue manager have local queue objects with the same names as other queue managers for reasons explained in the Intercommunication manual. I think it's one of those objects that amqscnxc is connecting to.
So you have 2 options. Stick with your code as written but change the queue manager object to your local queue name & use redirection, or alter the MQEnvironment to reflect where your target lives and connect that way.
Which you use depends on what your application intends to do with the connection and is a design question. Both methods are valid in various scenarios.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MCardinal |
| Posted: Thu Oct 07, 2010 3:49 am Post subject: |
|
|
Novice
Joined: 06 Oct 2010
Posts: 18
Location: Ottawa, Canada
|
OK let me use different terms, I'm not talking about queues yet. Only Queue manager object.
Local means my computer, remote means another computer or server.
So basicly your reply: "So to connect to a "remote queue on a server on your network" you either connect to the queue manager that hosts it over the network or get your local queue manager to pass messages for you."
This is what I'm trying to accomplish.
From the 2 options you mentionned, the first one I can do no problem but It's not the goal, because the user who wil run the application may only have the Webphere MQ client installed.
If you look at my code I'm trying to modify MQEnvironment object to reflect to my target. This object however doesn't seam to work and I'm wondering why.
Let look back at the code I posted ( I renamed the generic QM )
If I run this code from MYCOMPUTER, ip 192.168.0.2 and that I want to connect to the Queue manager name "THE.REMOTE.QM" on MyServer, ip 192.168.0.3, on port 1414 using the channel APPLICATION.NET .
Why is it that using my code posted previously it doesn't work? But all instance are there on the server, I have connected to that QM many time but not using this code.
What I'm I missing? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 07, 2010 4:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 07, 2010 4:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MCardinal wrote: |
OK let me use different terms, I'm not talking about queues yet. Only Queue manager object.
Local means my computer, remote means another computer or server. |
That's fine, but you'll find my terms are what the WMQ documentation uses for local & remote. Be aware when reading them.
| MCardinal wrote: |
| From the 2 options you mentionned, the first one I can do no problem but It's not the goal, because the user who wil run the application may only have the Webphere MQ client installed. |
Only having the client does not prevent you using the 1st option. It's very much the most common pattern to have only a client installed and connect to a queue manager hosted elsewhere via TCP.
| MCardinal wrote: |
| If you look at my code I'm trying to modify MQEnvironment object to reflect to my target. This object however doesn't seam to work and I'm wondering why. |
I'm not seeing that.
| MCardinal wrote: |
| What I'm I missing? |
I think you're using a binding connection that links to a queue manager running on the same machine as the application rather than a client that uses TCP & the MQEnvironment settings.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MCardinal |
| Posted: Thu Oct 07, 2010 7:23 am Post subject: |
|
|
Novice
Joined: 06 Oct 2010
Posts: 18
Location: Ottawa, Canada
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 07, 2010 7:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MCardinal wrote: |
| Can anyone show me how I can change my binding connection? |
In that same .NET manual there is a section "Defining which connection type to use" that explains it all.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 07, 2010 8:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| MCardinal wrote: |
| Can anyone show me how I can change my binding connection? |
In that same .NET manual there is a section "Defining which connection type to use" that explains it all. |
| mqjeff wrote: |
| http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzav.doc/un10480_.htm |
 |
|
| Back to top |
|
|
| MCardinal |
| Posted: Thu Oct 07, 2010 8:53 am Post subject: |
|
|
Novice
Joined: 06 Oct 2010
Posts: 18
Location: Ottawa, Canada
|
OH!! thanks all for replying to my post. I figured it out after long research.
The web link post doesn't help much but here it the line of code I was missing.
MQEnvironment.properties.Add(MQC.Transport_Property,MQC.Transport_MQSERIES_CLIENT)
Then it makes the connection. Hope it help others. |
|
| Back to top |
|
|
|
|
