| Author |
Message
|
| swood |
 Posted: Fri Dec 10, 2004 6:00 am Post subject: .Net to MQ requirements? |
 |
|
Novice
Joined: 10 Dec 2004
Posts: 20
|
I have a request to send messages to a customer's MQSeries from my .Net application.
I will apologize in advance since I don't develop using message queues and of course have never used MQSeries. I don't expect anyone to walk me through everything, just point me in the right direction if possible.
I need to know the hardware / software requirements to make this happen? The customer's MQ is within a different global location behind a CheckPoint firewall and our application is behind a router/firewall (dlink). I have done some research and it looks like the .Net classes talked about in this forum should do the trick with the MQ client 5.3 installed on the computer with the .Net application. I have the setup done but of course I don't have a queue manager to talk to. The customer has suggested that a VPN connection using IPSEC tunneling / shared secret is necessary. Once this is set up, will I have access to their MQ to use the q manager they set up and if so....will they have access to my MQ client to respond (guaranteed delivery is required).
I am not sure if it will be required for me to purchase MQSeries server. I noticed that there is no GUI interface for the client so I am also assuming that I will have to set up the Q manager and local Q through code?
Thanks in advance for any help at all
_________________
I don't know as much as I wish I did. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Dec 10, 2004 6:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay.
For what you are proposing, you do only need the MQ Client.
But you won't be able to do any local testing with out an MQServer.
The client is incapable of doing anything without an MQServer somewhere.
So you will likely want to purchase an MQServer license for your own development purposes.
Or you can see if there's currently a downloadable demo available.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Dec 10, 2004 6:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You will find it very hard to initially test your application without a queue manager locally. You may find a trial version available or get an IBM developer license.
If you do not have your own queue manager - you will not be concerned about MQ administration (GUI or otherwise) since you won't be doing it!
You will need to know the queue manager name, port, queue names, client channel names etc for use in the program - BUT whatever you do - DON'T hard-code these - read the values from .ini files or some other form of external storage that can be changed without a program source code change.
Make sure you issue MQGETs with CONVERT, WAIT, FAIL_IF_QUIESCING
Make sure you issue MQPUTs with the MQMD.FORMAT set to MQSTR
Only connect and open queues once, not for each message.
I can send you some more coding tips if you post an Email address. |
|
| Back to top |
|
|
| swood |
| Posted: Fri Dec 10, 2004 8:33 am Post subject: |
|
|
Novice
Joined: 10 Dec 2004
Posts: 20
|
Thanks for the speedy reply.
I now have MQSeries (90 day trial) installed with a queue manager and queue. I can access the queue from .Net code on the local machine but not from client code on another machine...error with the Q manager name. I think I will have to find out how to set up the ip address, port etc then maybe I can access the Q manager.
After I can access the Q manager/Queue on another computer within my network then I will be ready to test against the customer's network.
Thanks again
_________________
I don't know as much as I wish I did. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Dec 10, 2004 9:19 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
You have installed the MQ Client on the other machine too haven't you?
If not then you will need to. Then you will need to set the MQSERVER variable.
There is a pretty good MQ Clients manual that details all of this. I think it is under the Documention button on this site. |
|
| Back to top |
|
|
| swood |
| Posted: Fri Dec 10, 2004 9:54 am Post subject: |
|
|
Novice
Joined: 10 Dec 2004
Posts: 20
|
I'm not sure if I understand.
currently:
computer A has MQSeries server
computer B has .Net classes and client.
are you saying:
computer A needs MQSeries server and client?
computer B needs .Net classes and client.
I have set the environment variable as per the online documentation, to the ip address of the server (within our firewall) and still get the error "reason 2058" which I think means it can't find the Q Manager ( for whatever reason).
_________________
I don't know as much as I wish I did. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Dec 10, 2004 10:02 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| No. That setup that you currently have is correct. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 10, 2004 10:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
And there's a lot of discussion of solving 2058 and 2059 error codes when dealing with clients.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 10, 2004 10:39 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
swood, the first thing I would do, even before coding the .NET, is to prove the client can get to the QM.
You have an executable called amqscnxc that is super simple and is just for this.
| Code: |
X:\>amqscnxc ?
Sample AMQSCNXC start
Usage:
amqscnxc [-x ConnName [-c SvrconnChannelName]] [QMgrName]
X:\>amqscnxc -x ERDHFDMQXXXX(1415) -c MQXXXX
Sample AMQSCNXC start
Connecting to the default queue manager
using the server connection channel MQXXXX
on connection name ERDHFDMQXXXX(1415).
Connection established to queue manager HIGXXXX
Sample AMQSCNXC end
X:\>
|
This shows me connecting as an MQClient to server ERDHFDMQXXXX using channel MQXXXX. Because the QM listens on port 1415, I put (1415) after the server name. And you see that it returned the name of the QM that was listening there.
If this works for you, now you know basic MQ functionality is verified, and you can focus on your code. You build the MQEnvironment class to set all these values.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Sat Dec 11, 2004 1:23 pm; edited 1 time in total |
|
| Back to top |
|
|
| swood |
| Posted: Fri Dec 10, 2004 12:29 pm Post subject: |
|
|
Novice
Joined: 10 Dec 2004
Posts: 20
|
Thanks!
After installing the latest fix pac U200215A.exe on the server and using your sample code (enourmous time saver!), we can now retrieve and put messages on the server running on a windows platform within our network.
Fantastic group of people you are.
I guess the next step is to see if I can connect to a(n) MQSeries server on a non-windows platform and get a recieve message back from the server.
Have a great weekend and if you are ever in Saint John, N.B. Canada I'll buy you a beer.
_________________
I don't know as much as I wish I did. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 10, 2004 12:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
I guess the next step is to see if I can connect to a(n) MQSeries server on a non-windows platform and get a recieve message back from the server.
|
Your client does not care what the other side is, so just changing the MQEnvironment parameters to point to the new server would do it.
The only thing that might bite you is security, in that your ID will need to be defines on the other server, or hard code a value in the channel. (Kinda cheesy if you are worried about security, but at least it gets you going.)
Passed thru St.John a few years back on my way to the tip of Nova Scotia. I wanna go all the way to NewFoundland next time!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
