We are using BizTalk 2016 and MQSC adapter to send message to IBM MQ. We wanted to set MQMD_PutApplName property which we passed the value via Orchestration/Pipeline Component and we could see BizTalk is sending the value for MQMD_PutApplName property as shown below.
When we checked in MQ side it takes the default value as shown below and not taking the value BizTalk is sending.
Looks there is issue with BizTalk 2016 MQSC adapter so could anyone suggest on this issue and how to get the put app name value in MQ in BizTalk 2016
In order to set the values of context fields in the MQMD header, you need to be granted a particular authority or the queue manager will ignore, and over-write, what you wrote in there. You also need to explicitly ask to do this.
In MQ API parlance, asking to set the values in these context fields is done by using the Open Option MQOO_SET_ALL_CONTEXT
I don't know BizTalk configuration, it is there any setting that sounds like "Set Context"? Also, the user ID that you are running this program with, is it in the mqm group? If not, what authorities does it have granted on the queue manager?
Try issuing this MQSC command to learn the answer to that.
DISPLAY AUTHREC OBJTYPE(QMGR)
Further Reading
Message context
Related
I have a local MQ which my IIB connects to in client mode (i.e. not as a trusted application). I've set check client connection security on in the QM and now the IIB can't connect because it doesn't send a password and it's sending the wrong username (by default it uses the user that the process starts with). I've seen lots of documentation around setting dbparms mq::*. I could be wrong that but that only seems to affect the MQ Input and Output nodes ? Not the actual broker and it's config manager connections to MQ?
However, I've tried setting those values so that all client connection to my QMGR get a user/passwd but it still comes across as failing and I can see in the MQ logs that it's trying to connect using the userid that the IIB process was started with (and presumably without a password).
So, how do I get IIB to ALWAYS send a user/passwd to MQ when connecting the node/config mgr to the QM using client connections??
Clarification:
I have set mq::MQ -u -p and still the node attempts to connect to the QMGR using the ID that the MQSI process is started with and not the -u param. I have no execution groups and (of course) no flows in my broker so this can only be a core IIB component that's attempting the connection.
According to the IBM Integration Bus v10.0.0.10 Knowledge Center page "Connecting to a secured WebSphere MQ queue manager" you can set this in three ways:
On each MQ Node by specifying a Security identity property.
For all MQ connections to a named queue manager
For all MQ connections.
The order of which ID will be used is the same as above, so if you have a ID setup for all queue managers, you can override it for a specific queue manager or a specific MQ Node.
If you have a queue manager you are already connecting to called for example IIBQM, you could specify the following command so that all connections to that queue manager would use the specified username and password.
mqsisetdbparms integrationNodeName -n mq::QMGR::IIBQM -u username -p password
The KC page tells how to set it all three ways. If you have any specific questions please update your question by clicking edit and add more details and I can update my answer.
Hurrah - I've worked this out !
Although, I had not enabled chcklocal or chckclnt MQ, the fact that I had a idpwldap authinfo set meant that MQ was going to LDAP to find out who the user was that I was logging in with (presumably so that it could check what group permissions it had). So, I had to put my local user into LDAP and set its group.
This got my broker working (with no execution groups or flows). Once I deployed my simple mqinput and MQ output node flow it failed due to authorisations using the same ID. I could then see that it was binding locally and not as a client (which i had first considered). Phew - all done. So, to review: the answer was to put the user id that the mqsi bip/bipbroker process runs under into LDAP. Then give various MQ permissions so that the broker NODE and it's MQ flow NODES could connect to MQ correctly and put/get etc.
thanks for your help - and maybe this will help someone else in the future when someone puts on MQ security and they have a local QM with IIB.
In my application, I am sending message out to a Websphere MQ queue. Here in the application, users have the flexibility to set the user id in the message. However my problem is, since the parameter is configurable in my application, if users does not set it, from where the value will be taken?
I have gone through the below links, but got little idea about what value will be set for user id if it is not set at application level.
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqzaw.doc/jm41030_.htm
How to set MQMD ApplicationID field via JMS API?
Any help is appreciated.
The MQMD.UserIdentifier field is set by the queue manager to the user ID associated with the connection (hConn) that put the message. You can see what this user ID is by looking at DISPLAY CONN or the Applications... display in MQ Explorer.
If your application is running using local bindings, that is, it is on the same machine as the queue manager and it chose not to use a socket, then the user ID that the queue manager will discover is the user ID that the application process is running with.
If your application is running using client bindings, that is, it is using a network conncetion to the queue manager, then the user ID that the queue manager will use is the one assigned to the MCAUSER of the channel connection which can be set by CHLAUTH rules, or security exits, or flowed from the client etc.
If your application is going to set the user ID in the MQMD of the message then the application must tell the queue manager it is going to do this, or whatever is in the MQMD.UserIdentifier field will be over-written with the above. To tell the queue manager it wants to do this, the application must use an additional option when it opens the queue, MQOO_SET_IDENTITY_CONTEXT and when it puts the message, MQPMO_SET_IDENTITY_CONTEXT. The open option also requires you to have the authorization to be allowed to do so, +setid when using setmqaut
Further reading:
Message Context
Controlling context information
(First of all, sorry for my poor English)
I've got MQ client (v6.0 or higher). I use mqic32.dll to connect to MQ server. I call MQCONNX to connect to the Queue Manager. MCAUser is not specified for this manager. So, I authenticated at server as a current Windows user.
Well, my program option's window has a 'Test' button and 'Login' Edit. When 'Test' pressed, I call MQCONNX - MQOPEN - MQCLOSE - MQDISQ functions sequence to test the connection/queue opening. There are 2 types of users who starts my application - admin & operator. Admin sets options and performs connection tests, simple users sends and recieves MQ messages. They shoul log in Windows as different Windows users.
And my question is:
I call MQCONNX() being logged as Admin. What parameters (among MQCD struct [sub]fields) should i set for MQ server authenticate me as Operator.
Yes, I can start new process (CreateProcessWithLogonW) as an Operator. But is there a decision keeping me in single process?
I know, using client java- libs I can specify user. So, I think, there should be equivalent ability for mqic32.dll, am I right?
I authenticated at server as a current Windows user.
The queue manager does not authenticate an incoming connection. It will use the UserID to check if the user can do those particular actions i.e. MQCONN, MQOPEN, MQPUT, etc.. But that is not authentication.
If you have not implemented an MQ security solution then anyone can connect with any UserID they want.
I call MQCONNX() being logged as Admin. What parameters (among MQCD struct [sub]fields) should i set for MQ server authenticate me as Operator.
You need to create a client-side security exit and use MQCSP structure but it will not do you any good if you do not have a server-side security exit to read it.
Note: You cannot protect your queue manager from a client-side point of view because anyone can simply download one of the free MQ SupportPacs or one of the many free MQ applications and use it to connect to your queue manager. You need an MQ security solution that is implemented at the queue manager.
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 am new to Websphere, and at this client site, we are running an older version of Websphere in an older version of RAD. I used a python script to define a queue factory and some queues, using a script provided by another individual at the site. However, there was not mention of a queue manager in the script. It appears that the queues are created, I can see that they are defined in the Admin Console. Same is true for the queue factory. The admin console does not seem to expose the name of a queue manager, however.
I have been googling for a few days trying several different angles, but always come back to no answer. There seems to be tool called MQ Explorer, but that comes with Websphere MQ, which is not installed. No one here seems to have tried anything like this before, of if they have, may not have attempted what it is I am trying to achieve.
Ideally, what I would like to do would be to connect to the queue with a third party tool called MQ Visual Edit, for example.
There are about 3 or 4 questions here. Let's see if I can address all of them.
First, creating administered objects is completely separate from defining queues in the queue manager. Typically, the WebSphere MQ admin defines the queues and topics, then provides the host, port, channel, QMgr and queue/topic names to the WAS admin who then generates the matching connection factory and queue or topic objects. Defining the WAS objects does not create the corresponding WMQ objects, nor does it even imply that they exist. From your description, it sounds as though they may not have been defined on the QMgr.
In fact, it is not even obvious from your description that you are using MQ as your transport. If WAS is configured to use it's own JMS implementation (System Integration Bus or SIBus for short) then the connection factories and other objects may point to SIBus instead of WMQ. If you created a QCF for WMQ then someone should have already provided the details you are requesting - QMgr name, host, port and channel name.
WMQ Explorer is available as a free, stand-alone download called SupportPac MS0T. In order to use it, or any of the other 3rd party desktop tools such as MQ Visual Edit or SupportPac MO72 you will need to know the QMgr name as well as host, port and channel name. In addition, if the WMQ admin has enabled any security, you will need to be authorized to connect and, at a minimum, inquire on WMQ objects. The WMQ admin will provide these details to you. Assuming you have the QMgr details and are sufficiently authorized, just download and install SupportPac MS0T and point it at WMQ. Instructions on all things WMQ (including WMQ Explorer) are at the Infocenter pages. Since the stand-alone WMQ Explorer is V7 you will want the V7 Infocenter for any Explorer help. If the QMgr is at V6 then you may need to refer to the V6 Infocenter as well.
That answers the questions in the body of your post. The answer to the question in the title - how do I find out the QMgr name - is "ask the WMQ administrator." You should be given the name when you get the host, port and channel. That said, you often do not need it. A WMQ client will connect to any QMgr if provided the host, port and channel. This is what allows your client app to fail over to a different QMgr. Things like WMQ Explorer are the exception because they should not fail over. If you have a primary and backup QMgr, you typically want WMQ Explorer to see them both at the same time (so for example that you can configure them identically) and if one QMgr is down you want Explorer to report it as such. Therefore Explorer requires a QMgr name but most apps do not.