We have to connect to IBM WebSphere MQ present on remote server through UFT 14.02v which is present on desktop. Here we are using API Test under UFT to test WebSphere MQ.
While trying to connect following error message getting displayed: "To run tests with IBM’s MQ client, make sure to install the MQ client on all machines running these tests".
Do we need to install MQ client on desktop(where UFT is installed)? or lets know the better approach to connect WebSphere MQ through UFT(API test)
Related
In one of the windows system the administrator has installed the IBM MQ version 8. But after installation we are not ale to see the IBM MQ (installation 1) listed in the services. and also not able to see the file amqsvc.exe file.
If we launch Prepare Websphere MQ wizard it also just exits without any actions.
But on the control panel -programs and features able to see the IBM MQ installation1 is present . how to find out if the installation was done correctly?
Was this a MQ client installation instead of MQ server installation? how to find out what is the issue here as the MQ service is not present or its related files?
I am trying to configure test automation project in UFT 12.02 for IBM Websphere MQ 6.0
I am facing the following error while connecting to MQ Queue Manager
(To run tests with IBM’s MQ client, make sure to install the MQ client on all machines running these tests.)
as per the above error description I need to install MQ client on my machine, but I cannot install it because IBM has been stopped supporting MQ 6.0 accordingly I didn't find it anywhere.
I have configured the same but in IBM RIT (Rational Integration Tester) and it was only required to configure the JAR files (com.ibm.mq.jar & connector.jar)
My question is; Is it applicable in UFT to configure only above two JAR files (just like IBM RIT) or it is necessary to install the MQ 6.0 Client?
And can I test the MQ 6.0 through UFT along with installing MQ 7.0 Client instead of 6.0, taking in consideration that the AUT is IBM Websphere MQ 6.0?
Also if applicable, can anyone provide the MQ Client download URL rather than IBM website?
Prior to V8.0 it was required to install the full client to receive support. Just grabbing the jar files worked but you risked IBM not supporting it if you wanted to open a PMR.
As of v8.0, IBM offers an all-Java client. I just provided the download instructions in another answer so instead of copying them, I'll link to that answer:
WMQ V8 Connection Factory setup on Tomcat using JNDI
One of the reasons this was not previously supported was that the old Java jars didn't have as much diagnostic function built in. IBM relied on the full client install for binary cient-side tracing, test programs, etc. The v8.0 stand-alone jars are really the way to go if you need an all-Java solution.
Note that support is based on the QMgr's license, not the client license (because that's free). If you are running a v6.0 QMgr other than the Linux Itanium version, then either you are paying a LOT of money for IBM Support or are running unsupported. If it is the latter, then you can't open a PMR anyway.
An unpatched v6.0 QMgr is effectively not secure. Even if you have applied the recommended security configurations, enough security-relevant APARS have now been discovered that you should consider an unpatched QMgr as being wide open.
As Tim notes in the comments, any version of MQ Client is supported with any version of MQ QMgr. Head over to the SupportPacs page and look for ones with names like MQC**. Pro tip - If you download a new client, it comes with XA transactionality enabled. No need to go grab the transactional client jar file (which put you out of license compliance anyway).
I have been using WebSphere MQ lately to send message from local machine to the WebSphere MQ present on same (local) machine. Which works fine as expected.
I dont know how to install WebSphere MQ in other/remote Machine so that I can send message form my local machine to that remote machine.
Thanks,
There are a number of ways to do this but the most likely is that you will need to install an Websphere MQ Client onto the remote machine. I am not sure what version you want to use but the WMQ 7.5 client is available here MQC75 You can google for other versions by changing the number (MQC7, MQC71, MQC8 etc).
You haven't said what language your application is written in, if it is Java then the WMQ Client provides everything you need, if it is C/C++ or .NET then the page I linked to has more information about what you need for these languages.
I've got a question with the MQ client configuration file mqclient.ini.
If i have one MQ JAVA application which put msg to queue of remote MQ server in another box through TCP， does that java application search mqclient.ini locally when connectting to MQ Server? Or will it even go find that mqclient.ini file in remote MQ Server? since there is one default such file under MQ sever data directory, like /var/mqm
thanks in advance
MQ Client libraries use the mqclient.ini file located on the local server. They don't use the one on the remote server. The mqclient.ini file on the remote server will be used by MQ applications running on there.
I am designing a new file transfer infrastructure using WebSphere MQ v7.5 FTE product and like to know for creating an FTE agent in a Windows box, what is the basic minimum requirement? Does it require the MQ v7.5 server edition installed or will it work with the MQ v7.5 client libraries?
You need at least one WMQ queue manager to act as the queuing hub for all the agents. The regular FTE agents can be client-based. Typically, these are placed local to the file endpoints and access the underlying filesystem directly. For most agents a client connection to a central queue manager works great. The exception is a node where the transfer volume is very high, in which case it might warrant having a local queue manager.
The exception is the "Protocol Bridge" agents which are the ones that talk to remote FTP, SFTP and FTPS servers. These must reside on the same host as the queue manager.
Short answer: on your Windows box a client agent is the minimal requirement. Just point its configuration to a queue manager somewhere on the network.