IBM MQ Reviews

We use MQ for guaranteed delivery and once only delivery of important business to business transactions.

We use persistence messaging to ensure messages are not lost in case machine is restarted.

We have implemented business to business transactions over MQ messaging. The guaranteed and once only delivery ensures business integrity.

Reliability of message transmissions and ability to replay messages in case message ends up in backout queues.

It needs a User Interface which is better than the aging MQ Explorer. The existing solution MQ Explorer is outdated.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

The technical support is good.

We have always used MQ.

The setup was straightforward for simple usage. Load balancing is more complex.

I think the pricing is reasonable, especially with IIB as a part of it.

We did not evaluate any alternative solutions.

Get a good MQ expert to get it right from the beginning.

It allows us to process online transactions for our customers and we can connect between open system platforms and CID platforms. I think this is the most important.

This is the main component of our systems for delivering service to our customers. Without MQ, we would not be able to work or offer our services.

I am not working on the solution directly, but my team does, so technically I don't know the solution at the level where I could provide information about areas with room from improvement.

I'm satisfied with the stability.

Sometimes scaling is not easy because we are trying to connect open systems with mainframe and it's not easy. It is difficult sometimes. I'm not sure about that.

Technical support is great. We are satisfied. We call them every time we need. I would rate them a nine on a scale of one to ten.

Our support from IBM recommended the solution from the beginning, so this is what we use.

In some places, setup is very easy and in others, it is a little bit complex. When we are trying to deliver all of our transactions from web to system CID, it's a little bit complex because the workload is not the same in both platforms. To make this work is sometimes difficult.

We did look at alternatives, but our main platform is from IBM. We were thinking about other vendors but they are smaller, such as Compuware.

Well, I think you should try to use MQ. It's a great solution. I like it.

Specifically for MQ, the most valuable feature is the ability for us to deliver messages between applications using the MQ message queuing.

It's more of a guaranteed delivery. So, even if some of our systems are down at that time of delivering messages, when our systems come back up, it goes ahead and resends the messages, so we ensure that the messages are guaranteed.

I haven't seen any features that we could exploit today that's not currently available. I think everything that's in there today in terms of features; it meets all of my requirements. Everything that were shortcomings in the past, they've already been addressed from different users. The current version 8 is very stable and contains everything that we need to run our operations.

It's one of our more stable products on the CMS platform. We really haven't had any issues with that in terms of severity incidents, at least of what I'm aware of for the last three years.

It's very stable; we've not had to dedicate a lot of resources to support the product and that's a plus.

We have always had some unexpected workload coming in and we haven't had any issues of scaling up or down as and when we need to, so as to handle larger message workloads.

The only time that we have used support is when we do upgrades. We'll talk to IBM and maybe resolve some of the discrepancies in the product. IBM is very helpful. They are very responsive and if they can't answer the question, they find the person that can.

Look at the use case and verify that this product, i.e, the IBM MQ, can meet all of those requirements. If not, then go back and say that this is the feature that we probably may need, because every company may be different in terms of requirements for the product. If they have something that is beyond what this product is capable of delivering, then go ahead, open up a price quote for it.

It has always delivered and met all of our application requirements. Due to this, it has no shortcomings that I've experienced.

The criteria we look for while selecting a vendor are stability, where they are in the market place, what other research firms have placed them for the area we are looking for like Forrester and RAD group. We depend on them a lot to narrow down the number of vendors that we are looking for.

I worked as an employee for a bank where we recommended IBM MQ, and we used it.

It's for real-time messaging, an exchange between applications.

On the IBM side, we use Message Queue, all the Message Queue products from IBM. For six years, we used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

IBM MQ is highly scalable and has a reconciliation mechanism. These are the two main reasons we use IBM MQ. 

IBM MQ should have more extensive documentation because I couldn't find a lot of information on the system API side to help us monitor the message queuing. 

I would like to see more documentation.

I have been using it for six years. We used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

It has been a stable solution. 

It is a scalable solution. 

The customer service and support have always been great.

Positive

I know there are competitors like RabbitMQ and Dell Boomi. I believe RabbitMQ is built on open source and they have a licensed version as well. I don't know much about RabbitMQ or Dell Boomi at this point.

IBM MQ is highly stable and quite customizable to integrate with our systems.

We definitely installed using a service provider, and it's not that complex. It's easy. It took three to six months to start implementing the first use case. 

Around six to ten people were involved in the deployment. It is easy to maintain and stable.

The ROI is  good, but we only used it for a few use cases like banking customers. It's quite stable, so we got the value out of the installation.

I would rate it an eight out of ten. It's expensive, not cheap.

I would like to rate it as a seven out of ten. It is quite stable, but it needs to have more documentation, and that is why I rate it as a seven out of ten. 

At this moment, we don't see a use case for implementing AI, but it is definitely in our roadmap. We will definitely try to find a use case to implement any new features that get announced.

There were some long-running processes where it was timing out. We got the request from this source application, and we put the data into IBM MQ. Then, we read the data from IBM MQ before doing the rest of the processing. Especially for real-time processes, we have just decoupled it into two different ways to ensure there is no time-out.

The publish and subscribe features are the most useful aspects of the solution.

It's not too difficult to set up the solution. 

It's stable.

Technical support is quite helpful. 

The moment you send the data, there is no latency there.

We haven't experienced any data loss. 

If they could have some front-end monitoring tool that could be easily available for the team to use, that could be great. While you may not be able to edit your messages, at least if you could look at them, see the queue, and what's inside, et cetera, that would be helpful. We'd like visibility on the health of the environment. 

I've used the solution for two years. 

The stability is good. In fact, we have not seen any issues. Only recently have we observed an issue. There was a limit on the number of messages it could contain. We are having an issue now, however, we have not usually seen any issues related to IBM MQ. Therefore, in general, the solution is stable. I'd rate its reliability eight out of ten. 

I haven't seriously explored the scalability of the product and therefore don't know the full scope of scalability.

We handle about 300 to 400 transactions per day. 

Technical support is very helpful and responsive. We are satisfied with the level of support we get. 

Positive

I have previously used TIBCO EMS as well. 

The initial setup is pretty easy. It's not that complex. I'd rate the ease of implementation at a seven or eight out of ten.

The deployment time is pretty short. It's not a long process. 

In an integration scenario, like payment processing, where the payment has to go to the backend system, SAP, or talk to multiple applications, due to the fact that it's a lengthy, complex business process, we just decouple it. Some of the information we get immediately after receiving the request, and we pass on the information to the customer. Then, we put the payload into the IBM MQ, and then we started processing from IBM MQ. So there are integrations that sometimes need to be done or worked with. 

We have an admin team that does the configuration and setup of the solution. They can do it in one or two business days. 

We have witnessed an ROI while using this product. For example, we've had no data loss since using the solution

A different team handles the setup, and likely they also handle the licensing. I don't have any visibility on the cost of the product. 

I'm a user and customer. I'm not a core developer of IBM MQ. However, I'm a user of IBM MQ.

I'd recommend the solution to others. I'd rate it seven out of ten overall. 

We provide a channel that we call "the link," so we are distributors of numbering services. These links are connected to a simulator, for example, when MQ is related to some application or the scanner. It's a synchronized communication where we first check two-step authentication. So first, we start with the authentication. In the second step, the MQ server provides the connection. Then the system decides if it can make the connection or not. For example, if I'm uploading something, it will check one cluster, not the other five. So next time, I'm just checking to see if we can connect. After that, the other side is also checking. Those clusters are physical connectivity clusters.

We are sending everything. The partner and we create an acknowledgment number and check to see if everything is fine or not. Once everything checks out and we have verified the person with our partner, we establish the connection, sending a message. Then we are also checking the permissions and format. Sometimes there are some errors, so we have to check the login acknowledgment number and figure out what the error code means. We are handling everything for the project, from the code and deployment to support. We are handling everything through an RFP repository. So from there, we are handling every version released in the last two years. Every year, we upgrade according to the guidelines.

There are so many good things with IBM MQ networking. So many complicated issues arise when you're trying to configure your network, and MQ helps by providing the clustering. In our project architecture, we have a cluster that distinguishes between major requests from applications. There is also a centralized cluster. Let's suppose 10 applications are connecting to that cluster. In each application, we add differently. 

If I need to add multiple features to the centralized cluster, we can create another cluster. From there, the GMG is connected. Also, clusters can provide a backup. So suppose this solution faces some failure, like a power outage, MQ can automatically redistribute the load to other servers. 

We are using the synchronizer and another module in our product. We are stepping the connection from the IBM channel. After that, we can send or receive any message. This is synchronizing. We are handling the clustering, and we have created a design for how the NP is built with the partner.

IBM is still adding some features and coding some other systems on the security end. However, it has the most security features I've seen in a communication solution. Security is the most important thing for our purposes.

Sometimes, there are network issues, which means more applications are connected to those messages, so I would like to fix that. For example, suppose there's a new network, and I want to add virtual memory to address a network issue within the cluster. So there is a network issue that needs to be resolved from the cluster. So I need to add the permissions for that particular team or particular time. There are many complications with IBM MQ servers.

I've been using IBM MQ since last year.

IBM MQ is reliable.

We don't use IBM support much. Sometimes partners will come to us with questions, so we just guide them. Sometimes, you need an MQ person because they have access. We guide the customer to ask this question. You have to ask the MQ entity or the entry person. They will help you. And we are not writing any protocols because a separate team does that. And also, if anything goes wrong with the MQ product, then IBM will address that.

From a coding perspective, it's a straightforward process. There are no complications. We cannot directly access the IBM server because there is a separate team assigned to do some security and get some code of conduct from the MQ team. They are handling the MQ server. So we ask them to create these entry servers to discuss that. And also, we are defining everything. We are responsible for handling invalid queries. So they recreate a wrong question or wrong to them. So, whatever is an appropriate question. 

In terms of maintenance, there are three reasons you'll get a maintenance window. On the maintenance window, we are just restarting the epicenter. Nothing else. If it requires any patching or updates, we perform those. But you don't have to restart the application.  The epicenter typically runs continuously.

I rate IBM MQ seven out of 10. It's a good option for anything banking-related where you need secure communications. There are some other similar products out there, but I'm not about other servers. But I'm aware of our BME. So if you're doing banking or anything that requires secure channels, I would recommend IBM MQ. 

We use it for application-to-application integration.

Reliable messaging and throughput are the most valuable.

We are looking at the latest version, and we hope that resilience, high availability, and monitoring will be improved. 

It can have some more improvements in the heterogeneous messaging feature. The current solution is on-premises, so good integration with public cloud messaging solutions would be useful.

I have been using IBM MQ for 20 years.

Its stability is great.

Its scalability is okay. The inside scalability is great. We are hoping that the outside scalability is improved in the latest version.

Most of the users are just using the applications, and they are using IBM MQ without realizing it. In terms of the number of people really dealing with IBM MQ on a global scale, there are probably around 30 users. They are actually working with the product. There are thousands of developers who are using applications with IBM MQ.

I am an architect, and I talk with the architects of IBM. The engineers talk with technical support when needed.

The basic setup is simple. The deployment is fully automated.

We received the software from the vendor, but we deployed it on our own. We also do the maintenance ourselves. 

There is real money involved here. As compared to RabbitMQ, IBM MQ is on the higher side in terms of cost.

I would recommend this solution for similar companies. I am very fond of IBM MQ because of the reliability and throughput part, at least on a single server. On the consumer and application side, RabbitMQ seems a bit easier to consume. It is a bit ahead in terms of the scale-out feature.

I would rate IBM MQ an eight out of ten.

We work with an organization who has only one product and that works with IBM MQ. Combined with IBM MQ, this product is our primary data store.

There are many things that I like about IBM MQ, such as, its performance and reliability. 

I'm not sure that current version has event-driven mechanism requests that people go for. I would like the latest version to come with both type of event-driven mechanisms: an email server and a POP server. If that is not there, then that would be a great addition.

I have been with a company for the last three years who has been using IBM. I was with another organization before that who used it for four or five years.

For the last three years, I haven't faced any stability issues. I would rate the stability as a nine (out of 10).

Support is managed by the vendor management team. This is being taken care by some of the managers.

I was not involved in the pricing structure.

There are quite a lot of competitors of IBM MQ who have high capabilities.

I would rate the product as a seven (out of 10).