IBM Integration Bus Reviews

We use IBM Integration Bus for 600 applications that we're running.

The most valuable feature is the security.

Sometimes migration takes too long.

I have been using this solution for nine years.

It's a stable solution.

It's very scalable. When you deploy the solution, you have the option to create two different policies.

We haven't needed to use technical support very much. We reached out to IBM about a problem we had with HashMap.

I was the developer consultant.

I would rate this solution 9 out of 10.

It is used to enable communication between applications. For example, when application A needs to interact with application B, IBM Integration Bus provides a kind of bridge that helps application A to communicate with application B in terms of messaging. Application A might be using a specific format, such as XML, which needs to be converted into the format understood by application B. IBM Integration Bus takes care of this transformation and routing of messages from application A to application B. I have seen IIB been used in the banking, payments, and finance domains.

It makes the communication between multiple and heterogeneous applications so easy. We can bring together different messages and applications from different platforms and connect them through IBM Integration Bus.

They need to come up with Integration Platform as a Service (iPaaS). It should also have a feature for integrating with those applications that are on the cloud.

I have been using this solution for the past four years.

It is stable. There are plenty of projects that have been using this tool. My friends or my ex-colleagues who have moved to other organizations also find it good.

I don't have an insight into the scalability as such, but based on the meetings related to the maintenance of the application, I did not come across any scalability-related issues.

There were a couple of instances when my team approached them, and there was a good response from the IBM team. There were some delays, but that happened almost three to four years ago. Their support might have improved recently.

It is quite straightforward. For our project, we do have different needs. We build artifacts that are ready to be deployed. These artifacts need to be placed in a specific folder or directory. They are then picked up and deployed in the servers. It is quite automated these days.

Its deployment is quick. It is a matter of seconds.

I would recommend this solution. I would rate IBM Integration Bus an eight out of ten.

We are using Integration Bus for SOA (Service-Oriented Architecture) services. We are using it to connect APIs to servers, we are using it as an integration bus for hosting, and we are hosting our web services over it. I am using and testing this from the QA (Quality Assurance) perspective.  

The Integration Bus has provided us with a certain level of security. For instance, before we used this solution, we were directly connecting to databases through a DB link. We were able to stop that practice and make it more secure using Integration Bus. It has also provided us with the capability to reuse developed services. Services we developed can now be used with multiple systems and we are able to remove duplicate applications due to this advantage.  

Surely something that can be improved is session management. Sometimes sessions hang. Practically every day we hear about session congestion and this kind of thing. Troubleshooting the issue has become a long-standing problem. Where the true problem lies is a challenge for our support team.  

The session management issue may be a bigger problem for us because our support team is not so highly trained. Also, sometimes our developers are not able to dig down to locate the actual problem. To resolve the issue when it occurs, we have to at least restart the server. It is not really solving the problem, it just relieves the symptoms. These session management problems are the basic issues we are having, but otherwise, our services have become better after bringing in the Integration Bus.  

One thing I would like to have added to Integration Bus is a plugin — or some other software, — to enable testing the performance of our services from the application hosted on the IBM service. I think that the users of the system should be able to get something like that and somehow do performance testing on their own. Currently, I have used some studio or some plugin to find these results. Another option is using services that are available that I have also tried. If IBM could provide this same type of testing capability in its application, that that would be great. It would enable us to report to our business on the facts about how much we have improved from the earlier architecture.  

We have been using IBM Integration Bus for the last three years.  

It is a stable product especially with the release of version 10. We had problems with version 9. But now, version 10 was really a lot more stable and a lot of things have improved. We are much more satisfied with the product and stability of the performance. It is fairly rare that we are unable to troubleshoot something. But I think that most of the problems that we have, from my point of view, is because we are not better trained on the product as a whole. Maybe training could resolve some of our troubleshooting issues. Everything may not be the fault of the product.   

We had scaled up the product usage, so I know it is scalable. We were only using it with a few systems in the beginning and now we are using it with a whole bank of systems and all of the systems are integrated tools.  

The IBM partner that we are working with here is System Limited. IBM was not directly supporting us during the installation and if we have issues we work with the IBM partner.  

We did previously have another solution called BixTalk which we were using four to five years ago. One major problem with BizTalk was that we had very few people available who were actually trained on it. Secondly, there were some sever issues as well. We had a synchronization problem on top of that. Because it was so long ago I do not remember all the issues. Maybe we did have some other problems also. But we had a problem with the product support as well.  

From an installation point of view and just initially setting up this product, it required a lot of configuration. The configuration is the harder part of the installation. Otherwise, the installation was done in a few days by our team. I do not remember exactly whether we had any major problems in doing that, but it could be there were problems and I just did not hear about them.  

There were a lot of things to configure, but that was taken care of by a different department. Our operations department would be the group that handled this. So I do not have actual first-hand information because I did not participate in the process.  

It is a little hard to suggest a product for someone else without knowing anything about their situation. I would surely recommend it for companies that have lots of applications that they want to integrate. This is mostly what I would recommend it for. If you want a platform that seamlessly integrates your different applications, IBM Integration Bus for you.  

On a scale from one to ten where one is the worst and ten is the best, I would rate IBM Integration Bus as something like seven to eight. For the time being, I will give it a seven. I am pretty much satisfied with the product, but there are certainly ways I have mentioned in which it could improve.  

We use this product as an integration point between systems. We use it for logging and transformation of data between backend and frontend.

Our use case involves the communications industry.

The most valuable feature is that it is clear and easy to learn.

There is a community available where I can find a solution if I am facing a problem.

The interface could be more user-friendly.

I have been using IBM Integration Bus for about one year.

IBM Integration Bus is stable, although it depends on the efficiency of our code, the network stability, and the infrastructure. It will be stable if all of the applications are running efficiently.

We have a support agreement that is included with our license and whenever we have a problem, we contact them. In my experience, they provide good support. They also provide good material and documents.

I have not used another similar solution by another vendor, although I have been part of projects where other systems had been implemented.

The initial setup is straightforward, especially with Java and EasyCODE.

We make use of tools like bash scripting when we deploy files. When we deploy a single file, it takes about five minutes.

In summary, I can recommend this product because it is easy and straightforward to learn and use. It is also stable and has a good market share. All of the features that I have needed already exist.

If a developer would like to shift and try becoming an integration developer, then this is a good product to work with.

I would rate this solution an eight out of ten.

Our primary use for this solution is to integrate different applications into the aviation area.

We have an on-premises deployment.

The whole of the radar data that we receive from the ARPA (Automatic Radar Plotting Aid) is transformed by the IBM Integration bus.

This product provides a relatively easy way to develop integration solutions.

This solution has very good, high-availability features.

From a performance point of view, it's very good and it doesn't need very much in terms of CPU resources.

This product uses the PVU (Processor Value Unit) license model from IBM, and it is something that should be improved. It requires you to install monitoring software that ensures you are only using the number of CPUs that you have paid for. This license monitoring tool is very complicated. 

This solution is very stable.

We use this solution on a daily basis, and it is very, very important to us.

This solution is very scalable because there are different possibilities available when it comes to scaling it up.

We have two people who do the operating, and there are three to four people who are responsible for the development of the integrations.

I think that the support from IBM is very good for this solution. Usually, they answer very fast.

When I started at the facility, they were using CORBA (Common Object Request Broker) for the integration. It was used very intensively, and the project to introduce this solution was the replacement.

We had a consulting team from IBM on-site to perform the implementation. For the first three years, we had IBM consultants with us to guide us in the development and also in the operating of the solution.

Our licensing is based on a five-year contract, and as far as I know, there are no costs in addition to the standard licensing fee.

We evaluated several similar products including solutions from Oracle and Software AG, and we chose this solution not only because of its technical features but also because of the on-site support that IBM gave us.

My advice for anybody implementing this solution for the first time is to have people from IBM on-site to help you establish the operating procedures and the development procedures.

My understanding is that the new release will have a lot of new features, including support for Docker containers. At this point, I don't have any requirements for the new release. It has also been rebranded.

This is a good solution from a technical and operational point of view, but they should really remove this technically complicated license controlling. It is very complicated software that you have to install.

I would rate this solution a nine out of ten.

We are trying to use IBM Integration Bus in our organization. We have multiple things to do. Like DataStage, we also have SAP BODS as another ETL. We are also using JAM Server and Java. 

Instead of separately writing the Java code and restful web service and then using the ETL and JAM Server to call on a file basis, I am thinking of using IBM Integration Bus. I have a message flow. Once I drop a file, IBM Integration Bus will pick up all the functions, do everything on the MQ Server, and finally fit it with the web service, which is also created in IBM Integration Bus. I would have the complete message flow in one architecture site. I can apply it by using ETL, Java, and the JAM Server. However, it is failing at the data mining stage itself. It could be because of my lack of knowledge of IBM Integration Bus.

I use the integration of Kafka and the message flow, which is really good. It is also good for moving any file from one location to another. 

Using IBM Integration Bus in the data stage is pretty simple. You can see the preview and other things.

The MQ server integrated with IBM Integration Bus is really great. I don't have to do a lot of configuration from that side. It is really good.

It needs improvement in terms of technical support as well as in terms of integration of data mining. I am not convinced about many things in this solution, such as the conversion of the DFDL or copybook file, which is the conversion from a text file to XML. It is very complex.

They should also provide more information about this solution in the IBM Knowledge Center. I can get a lot of information from the IBM Knowledge Center about DataStage, but I don't get that much information about IBM Integration Bus. There is hardly any information even on the internet and various channels such as YouTube. They can provide good step-by-step documentation based on a company's requirements. It would be really helpful.

My company is mainly looking for data mining and communicating with multiple servers. IBM Integration Bus is good for communicating with multiple servers, but it needs improvement for XML conversion and data mining. We have a lot of old systems that use XML.

I have been using IBM Integration Bus for two to four months.

I contacted technical support, but I wasn't able to get the correct answer. I feel I wasn't given a good response. I was communicating with a person from technical support, and he took two to three months to help me with the support. Finally, he delegated that ticket to some other person, and he resolved my issue in one week, but the solution was not convincing. 

I wanted to know how DataStage does one-to-many and many-to-one mapping because it was failing in IBM Integration Bus. I have a DFPL file, and I have an XML Schema. I want to map the added element from the DFPL file to the XML Schema. The technical support person was saying that you have to write the ESQL code for mapping, but I don't know how many elements are there. Suppose I have 100 elements for one area at present, but next time, I might have 90 elements. He was saying that you should know somehow where IBM Integration Bus is failing, but there was no way to find that out. The mapping for that element was not there in the dynamic run-time query.

The initial setup is complex. It is not user friendly. When you have a file in the MQ Server, it moves to the next directory, which is the output. It is very complex to call a web service. It should just give the setup of the endpoint and do some basic stuff so that it can be consumed by the web service. It might be complex because of my less experience in using IBM Integration Bus.

I would recommend this solution if you are not doing any XML conversion or data mining and just want to use a message flow, such as reading a file and transporting to another location and then calling some message and integrating it with an existing system such as Salesforce.

If you have a lot of integration, I would recommend hiring some experienced people for it. IBM Integration Bus is a very big product, and people don't know even 20% of this product. If people have good knowledge of it, they can really do a lot of stuff. Based on my understanding, its complexity is the reason why people don't have good expertise in this product. I am an experienced Java professional, but I am facing a lot of difficulties in understanding IBM Integration Bus.

I would rate IBM Integration Bus an eight out of ten. It needs improvement for data mining, DFDL, and schema converter. There should also be more documentation and information in the IBM Knowledge Center.

The primary use case of this solution is as a corporate integration bus, between different financial applications. We use IBM Integration Bus (IIB) with IBM MQ for asynchronous interaction. Additionally, web services for synchronized integration such as REST APIs, SOAP and HTTP Interfaces with XML interaction. For instance, it uses for the integration of the Banking front end with the banking core application. IBM Integration Bus installed on-premise.

Before, we used to use client-server applications with strong interaction. Using the integration bus we quickly broke through the border between client-server and service-oriented architecture. Additionally, we were able to quickly link many other financial services with core bank system or exposed some API for financial services.

This solution is very reliable and it is easy to learn.

There are many connectors to different sources and it's easy to scale.

Also, it is easy to parametrize the integration of bus applications during building or deployment. For instance, set up names of the queues, set up binded services URL, set up or change user-defined parameters.

I like the IBM Integration Bus and I hope that it will change in micro-service architecture. My understanding is that it will change to be less connected, and less depends on the operating system or the hardware resources.

I would like to be able to run and install this solution on different platforms and using containers and using modern micro-service and cloud environments.

This solution is quite stable. We use this solution every day.

There are many financial services to be integrated with different APIs, so it was easy to develop it with Integration Bus.

This solution is scalable. As an example, If you are using web services and you want to upscale several connections, we do it by changing one parameter in the application: "Number of additional instances".

Also, it is easier to scale a synchronized interaction with MQ to change one parameter to indicate how many instances you want to execute simultaneously. On the other hand, you can deploy the same application on different integration servers.

We have not used the technical support. We found all of the information that we needed with the IBM documentation.

We used to use client-service applications with strong integration between application. The company implemented many other applications with different interfaces and aimed to link with external services. So that we started using Integration bus for integration legacy application with new applications.

The initial setup was easy. For Windows, you will run the installation file and you have an environment that is ready to develop an integrated solution.

If you want additional resources such an MQ, or databases, you will have to read the manual to understand how to connect them.

The building and deployment are quick and easy. It only takes a few minutes to deploy, depending on the size of your application, but it's fast.

There are two methods of deployment. You can use the manual deployment method using the drag and drop. On the other hand, you can use command-line interface for building and deployment applications. The application represented as one or some number of .bar file. It's something similar to .ear but other structure inside.

You only really need one person to deploy this solution, but we shared build and responsibility using GitLab tool-chain and Nexus Repository. The first factor is for development and building and the other one is for deployment. We use the same process for different environments. All necessary parametrization inside the application are stored as a file and substituted depend on the deployment environment during the building process.

The implementation was done with our team. Additionally, we used the standard development process for teamwork.

We have gone through different comparative solutions and other integrated systems, and IBM Integration Bus is better for enterprise.

My advice for anybody who is implementing this solution is to start with reading the documentation. Have a good understanding of how to integrate Integration Bus with different resources, and to have experience with a synchronized interaction with IBM MQ or Apache Kafka. But IBM MQ is preferable.

Also, it is better to have an understanding of the HTTP Interaction and REST API interaction.

I also suggest people participate in IBM online learning. There are two courses that go over features that are related to integration development. They are very helpful. They also teach how to develop an integration solution, so it is an interesting program.

Additionally, explore the IBM blog about Integration Bus and App-Connect. You can find there a lot of integration patterns.

Other Integration solutions require an application server, but with IBM Integration Bus, it doesn't require a special application server.

I would rate this solution a nine out of ten.

We use IBM Integration Bus as a bank middleware solution. 

The solution does omnichannel integration with the core banking and other systems, including core banking, ETC, and click systems. It does so for a host of systems. 

The solution addresses all of our middleware needs in respect of transformation, parsing, security and stability; everything really. 

IBM Integration Bus could have better REST API, which could be more powerful,  and this accounts for why we are looking for alternative solutions concerning this and open banking. 

The initial setup was complex. 

Technical support is below what I would consider to be very good. It's good, but not too much or very much so.

The solution is complex and there is a need for more resources and greatly improved quality. 

The solution addresses our stability needs. 

Thus far, we have been making maximum use of the solution. 

Technical support is below what I would consider to be very good. It's good, but not too much or very much so.

We previously used a local solution and replaced this with a new enterprise solution. 

The initial setup was complex. 

Including preparation time, addressing the environment and building the POC, deployment took around one month. We are talking about active, on-premises deployment. 

There are nearly five people required for deployment and maintenance. 

Management would be in a position to address whether we have seen a return on our investment. This said, we have witnessed some returns on our business so far. 

I prefer not to address the licensing costs, or any other for that matter, as this is confidential. 

We did evaluate other products before going with IBM Integration Bus. 

We are customers of the vendor.

From a development perspective, there are nearly 40 people using this solution in our organization, although we have thousands of customers who do so indirectly. 

The solution probably covers more than 95 percent of the integration requirements. 

I rate IBM Integration Bus as a seven out of ten.