IBM MQ Reviews

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. 

I use the solution in my company since our clients always go for a middleware solution. IBM MQ is a part of the middleware solution category. When I design a middleware solution for our clients, I use IBM MQ to basically store the message.

The most valuable feature of the solution stems from the fact that it offers guaranteed delivery of messages to users. One good thing about the product is the guaranteed delivery since it guarantees that the message won't get lost. My company uses IBM MQ since we handle a lot of asynchronous modes of the design flow, and that is why we choose to use the solution to host the message before we proceed with the other sub-processes. The tool is effective in areas like message delivery and managing large message volumes. It is a very good solution.

In IBM MQ, the channel connection is an area where my company faces some limitations. At times, we hit limitations on the connection, meaning the connection is fully occupied.

I have been using IBM MQ for more than ten years. My company is a reseller of IBM tools.

Stability-wise, I rate the solution a nine out of ten.

Scalability-wise, I rate the solution an eight out of ten.

I rate the technical support a nine out of ten.

Positive

The product's initial setup phase is very easy.

The solution can be deployed in an hour.

The tool saves on development, implementation, and operation costs. The product is quite easy to maintain.

If one is cheap and ten is expensive, I rate the tool's price a seven. The product is expensive.

Maintenance is quite easy when there is an upgrade of any version. You just need to migrate the configuration to the other platform, and it is quite easy.

I rate the tool a nine out of ten.

MQ is the middleware, which takees the files from an upstream system to a downstream system or the downstream system to an upstream system.

The system integration is good. 

The pricing needs improvement. 

I have been using IBM MQ for six years. 

The scalability is a nine out of ten. 

The initial setup is complex. 

Overall, I would rate it an eight out of ten. 

IBM MQ could improve capacity, monitoring, and automatization.

I have been using IBM MQ for approximately 22 years.

IBM MQ is a stable solution, it is used mainframe computers and it is secure.

The scalability of IBM MQ is good.

We have approximately 100 people using this solution in my company.

The support from IBM MQ is good.

IBM MQ has a complex setup. The time it takes for deployment take approximately two to three months.

We have a special contract with IBM MQ that give us a certain price.

I am satisfied with the solution overall.

We have five to six people for the maintenance of this solution.

I rate IBM MQ an eight out of ten.

We use this solution locally and work in port authority where we deal with multiple parties like warehousing, containers, customs and Egyptian customs. Therefore we can communicate with each other and achieve middleware goals. We use the MQ Server and MQ client in each party and control it with the MQ server in port authority.

The product has allowed our organization to deal with all parties, like containers and warehousing. As a result, we can deal with these parties, exchange messages, and achieve our goals.

We have found the security and monitoring capabilities of the product most valuable. The product helps us monitor messages with other queues, view duplicated messages and control undelivered messages so they can be stored in pack-out queues and restored. We like more than one feature in MQ as the product is secure. For example, we can exchange messages between all parties with a stake and have control of undelivered and unrouted messages. Furthermore, with a scheme of validation, we can report access.

The dashboard is handy because we use it to monitor the messages and know how many messages are delivered to parties' dashboards. For example, we can notice how many letters are delivered, how many messages are undelivered, and how many messages are brought incorrectly by the dashboard. However, it would be great if the dashboard had additional features like a board design or picture management features.

We have been using this solution for over six years and are currently using MQ version nine.

The solution is stable.

The solution is scalable. Over ten parties, with 10,000 people, are using this solution in our organization, and two employees are required for maintenance. One employee is a system analyst, and the other is an integration developer.

I rate technical support a ten out of ten.

Positive

We did not previously use any other solutions.

The initial setup was straightforward. It was easy to install and configure.

The deployment was done in-house.

The product is good, and our organization has used this product for more than ten years.

The licenses for our company are according to port authority contract sales and we buy a license for six months or one year. I don't know the exact costs of the licenses.

I rate this solution a ten out of ten because we have no issues with it. The solution is good, but improvements could be made to the dashboard.

Primarily, I use IBM MQ for microservices, modeling, and communications.

IBM MQ's flexibility has sped up our active communication. 

I've been using IBM MQ for five and a half years.

IBM MQ's stability is good.

IBM MQ can scale, but there are some challenges with it.

IBM MQ's pricing is higher than its competitors'.

I would rate IBM MQ seven out of ten.

I am an integration developer at a bank, and we use IBM tools to develop our solutions. We use IIB (version 10), IBM App Connect (version 11), IBM MQ (version 9.1), IBM web servers, and IBM ODM. We use IBM MQ for exchanging messages between applications.

It is useful for exchanging information between applications. 

It could always be more stable and secure.

I have been using this solution for about three years.

I didn't use anything before IBM MQ.

It was straightforward. It took less than a minute.

We didn't use any integrator. We have a team of about five people who work with this solution. We have developers, a team lead, and a project manager.

I would recommend this solution to others. I would rate it an eight out of 10.

We use MQ for our transactional layer in conjunction with IBM Bus. We use MQ for our web application servers and many of our processes.

We like IBM MQ for our synchronous communications and transactional applications that require a lot of CPS.

We've been using IBM MQ for about 10 years, but we are currently in the process of migrating our IBM workload to the integration layer in AWS.

IBM MQ is highly stable.

The portion of IBM MQ that we have in the cloud is scalable, but the on-premise part isn't so much. However, we are working on sending our loads to cloud.

IBM support is good. I would rate it nine out of 10.

Positive

It's straightforward to set up IBM MQ because we can use it in lightweight modules, like containers, for example. It's not always easy for applications to connect to IBM MQ, but I think it's fine in general.

I rate IBM MQ nine out of 10. It's a good solution.