I am struggling connecting a Logic App to MQ in the IBM Cloud.
I created a Queue Manager in MQ and want to send some test message to any of the default queues.
The Logic App connector wants the Queue Manager, Channel and Queue.
I created a Channel of Type Receiver, not sure why this is needed, but created it.
When I try to connect I got an error.
Tried using the port as well, (tried 30127 and 1414, 30127 the port assigned to the Queue Manager) and received an error, though a different error.
This is my first time working with MQ, so any help would be much appreciated.
You don't need a channel of type RECEIVER, instead you need a channel of type SVRCONN. In your screenshot that asks for a 'Channel Name' with description 'The channel to connect to the queue manager on' it must be a channel of type SVRCONN whose name you supply in that field.
Could you update your question to show how you used the port? If the port number is not 1414, then you will certainly need to supply it as well.
Related
What is the use of a server conn in Websphere MQ and why do we go for it.
What is the difference between client conn and server conn.
In some respects these are two opposite things, but they need to match to make a client connection to a queue manager. Its quite a generic topic but fortunately there is lots of useful documentation about this in google / IBM knowledgebase e.g. https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q016480_.htm
As a queue manager, if you are going to let clients connect into you, you need to be able to provide some configuration details (heartbeat intervals, max message sizes, user exits) - these are configured on a SVRCONN channel
As an application, if you want to connect into a queue manager via the client bindings (usually to go to another machine), you need some information about the configuration to use and these are configured on a CLNTCONN channel.
The application 'provides' a CLNTCONN channel, and once the connection is made, an equivalent SVRCONN channel is looked up, and the configuration values are negotiated and the connection made.
An application can 'provide' a CLNTCONN channel at least 3 common ways...
- As part of an MQSERVER environment variable
- Via a client channel table (MQCHLLIB/MQCHLTAB environment variables)
- During an MQCONNX call it can provide the channel details
More details here:
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q027440_.htm
I have being trying to transfer a message between two host. I followed Jump start WebSphere MQ development on Linux article, It's work fine with two queue manager in single machine.
Here I created one local queue, one transmission queue and one remote queue and also create the sender , receiver and SVRCONN channel in both queue manager. I can transfer the message between two queue manager.
But I try this with two host, when I try to start the channel it doesn't work.
Much appreciated if anyone could help me with this issue Or let me know if more clarification on my question is required.
You will find a starter here:
http://www.redbooks.ibm.com/redpapers/pdfs/redp0021.pdf
The part which is relevant to your case starts at page 46 of the MQ Series Red Book.
At the very least you should enroll to a CBT course and get MQ training.
I'm a beginner on WebSphere MQ, I was working on MQ 6 and it was working fine, but now I've installed MQ 7.1 and when I try to create a new Queue Manager I can do it But it can't connect and it gives me the following error :
Do you have any idea about that? Thank you :)
You can look up any WebSphere MQ error code if either the WebSphere MQ Client or Server are installed using the mqrc command. In this case:
C:\Users\MUSR_MQADMIN>mqrc 2059
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
The 2059 usually indicates that the listener is not running or the queue manager is down. There's a different error code if the listener is running and the QMgr name is wrong and another one if the connection is made to the right QMgr but the channel name is wrong. Sometimes you can get a 2059 if the channel was closed at the server side by an exit but since you didn't mention any exits, I'm assuming in this case that its listener problem.
Hopefully by now you are defining a listener object rather than using inetd or the runmqlsr command. Defining an object and setting it to start and stop under QMgr control is the most reliable way to configure it.
Once you get past the 2059, you should be aware that as of WMQ V7.1, the queue managers are secure by default and won't accept any remote client connections unless you explicitly authorize them. This is the opposite of the behavior of V6 where on a newly defined queue manager running a listener, anyone with a TCP route to it could administer it and remotely execute OS code as the mqm user. So I expect that the next problem you run into will be 2035 errors.
I've been told this means more work for the WMQ administrator. The only case in which that's true is if the V6 or earlier queue manager had been configured without security. If the tasks to secure a V7.0 QMgr are compared to the tasks to provision access on a v7.1 and higher QMgr are compared, provisioning access turnds out to be easier. However if you liked the V7.0 behavior, you can always alter the QMgr to disable CHLAUTH rules. Needless to say, leaving security enabled is highly encouraged.
To debug security errors, alter the QMgr to enable authorization events using the runmqsc command ALTER QMGR AUTHOREV(ENABLED). Next, download and install SupportPac MS0P into WebSphere MQ Explorer. Then when you do get a security error, use WebSphere MQ Explorer to look at the queue. Right-click on the queue and select the option to parse the event messages. This will tell you in excruciating detail all the information you need to debug the authorization error.
Finally, if you wish to read up on the new security features, go to t-rob.net/links and look at the conference presentations there. There are also some articles indexed if you scroll down.
In the screen-shot, I see hostname "127.0.0.1" and port # 1414. If it is a local queue manager then connect directly to it.
Also, each queue manager MUST use a unique port number. If you had it working with WMQ v6 queue manager, is this the same queue manager? If not, then make sure each queue manager uses a different port number (i.e. 1415, 1416, etc...)
I got same problem. but i resolved this by :
1. created a listener manually (define lstr(lstr1) port(xxxx) control(qmgr)
2. setmqaut mcauser('mqm').
i kind of don't understand when to use the MQ client connection channel. From my understanding, when client trying to connect MQ server, it can be completed by defining the channel object with server connection channel value directly in application code. Therefore, if so, then why do we need to make use of such client connection channel?
Please help explain to me in detail. Thanks very much
A Server Connection Channel is used by clients to connect to a queue manager.
You don't really use a client connection channel to connect to queue manager. A client connection channel defines the connection parameters required to connect to a queue manager for example queue manager name, connection name, SSL etc. These channel definitions are stored in channel definition table (CCDT) files. CCDT files are used by client applications through MQCHLLIB and MQCHLTAB environment variables.
This link and another has little more details.
In older versions of WebSphere MQ, a Client Channel Definition Table was used to specify SSL parameters and for failover so the application could select from several equivalent queue managers at connection time. The CCDT file is a compiled artifact and the DEFINE CHL(channel name) CHLTYPE(CLNTCONN) command is what generates the entries in the CCDT file. So you would only use the CLNTCONN channel type if you wanted to create a CCDT file.
Newer versions of WebSphere MQ expose the CCDT fields in the MQCONNX API and the reconnection parameters are in the CONNAME parameter and the client.ini file. Although these have made the CCDT file obsolete for newer applications, the functionality is still required for commercial and legacy applications. IBM has not announced that CCDT functionality is deprecated and it is in V7.5 which was just released so that functionality will remain for the foreseeable future.
What is a channel?
A channel is a logical communication link between a WebSphere® MQ client and a WebSphere MQ server, or between two WebSphere MQ servers. A channel has two definitions: one at each end of the connection. The same channel name must be used at each end of the connection, and the channel type used must be compatible.
WebSphere® MQ uses two different types of channels:
Message Channel
MQI Channel
A message channel, which is a unidirectional communications link between two queue managers. WebSphere MQ uses message channels to transfer messages between the queue managers. To send messages in both directions, you must define a channel for each direction.
A message channel is a one-way link. It connects two queue managers by using message channel agents (MCAs). Its purpose is to transfer messages from one queue manager to another. Message channels are not required by the client server environment.
An MQI channel, which is bidirectional and connects an application (MQI client) to a queue manager on a server machine. WebSphere MQ uses MQI channels to transfer MQI calls and responses between MQI clients and queue managers
Source
I am a novice with Websphere MQ and require some novice help.
I am using Websphere MQ Explorer to connect to a queue but do not know how to write the connection string. I have all the details (host, port, channel, queue manager name) but do not know how to put them together correctly as a connection string.
Can any help this novice?
Thanks
Here is one way to get you started (assuming your queue manager under default configuration):
Queue Managers->Context Menu->Add Remote Queue Manager
Fill in Queue manager name:
Select Connect directly
Next
Fill in:
Host name or IP Address:
Port number:
Server-connection channel:
Next
Next
If you have a user configured usually mqm user, you will need to tick the "Enable user identification" here and fill in the user/pass here.
Next, Next, Finish.
As you see, you might need to fill in other information such as SSL if you configured it at the target queue manager.
Then you should be able to see the queue manager in the tree. Click on the Queues icon to find the queue you care about.
Hopefully you are using the latest WebSphere MQ Explorer which is now a stand-alone download. You can find it at SupportPac MS0T which is available from the main SupportPac page. There are significant advantages to using that version, including Explorer Plug-Ins for WMQ FTE, WebSphere Message Broker, the MS0P plug-in which parses event messages, and more.
The screen shot below shows the connection dialog in the latest WMQ Explorer. It has separate fields for hostname (or IP address). port and channel. Just plug in the appropriate values and you are good to go!