IBM Integration Bus Reviews

We are using the solution as an outer layer for all of our API calls we are making outside of our own devices. All APIs integrations are routing through the ESB only. We are using it for IIB server components and the DataPower, which is an API gateway. It is providing us with a security layer because all the outside calls do not have direct communication with our own server, this middle layer is called the ESB. 

The solution has helped my organization because any new integration coming to my backend system, we can easily implement it in a shorter time. This is because the middle layer takes care of all API language conversions or the code conversion, and also does the maintaining of the logs.

Having the solution come from IBM you know you are receiving a product of quality in components and in the services, it is very good.

I do not think there are any improvement areas because it depends on what exactly the use case for this ESB is. Some organizations are having a lot of integration and they will choose a regular ESB. While others will choose the security purpose route, making an extra layer. It depends from organization to organization, to determine how this solution can be improved from their specific use cases. Otherwise, I think that there are not any relevant improvement areas to give.

I used the solution in my last company for a long while.

The solution came to the market a long while ago, it has had time to mature. It is really stable and large organizations can rely on it. Smaller companies could too but it is too expensive.

It is a scalable solution. You can have any number of integration, it depends on the server and how much space you are providing to the IIB servers. We plan to have more than 50 wired integration by the end of the year.

The installation is not easy. You need experts who know how to install this IIB. The common technician will not have the knowledge to do it. You will need assistance installing the solution even though on IBM's website you can download the complete user manual explaining how to install the IIB servers. 

We used a third-party vendor, who help us install the solution and it was not easy. If you have most things in place at the site the whole installation process can take approximately three days. 

To do the complete deployment you will need at least one architecture that understands this IIB solution. It all depends on what kind of IP division architecture you have. Based on the project's scope, you then can define your team. There is no certain number of how many team members is required. It depends on your project, how large it is, and based on that you can decide how much manpower is required.

The solution requires a license and is very expensive here in India. Large organizations will be able to afford it but smaller companies will have a difficult time paying for the solution at the current price.

I am going to continue to use this solution, when you purchase this solution you have spent a lot of money, you have to continue to use it to make a return on investment.

I would recommend this solution if they have a large budget.

I rate IBM Integration Bus an eight 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.

The solution is deployed on-premises.

The message queue feature is very valuable.

The product could be improved by including more resources on SQL and improving the simplicity of the resources available. Additionally, the price can be reduced.

We have been using this solution for approximately four years and are currently using the first version.

The solution is stable.

The solution is scalable, and there are currently many people using the solution in our organization. We have plans to increase the usage of the feature.

It is quite expensive and can be lowered.

I rate the solution an eight 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. 

Our prime use case of Integration Bus is for message enrichment and message transformations. 

The solution offers good performance and it's stable. The message enrichment and message transformations are great features and the solution also has great security.

There are a few issues; the memory footprint needs to be improved. Memory replacements for on-prem should be minimized. Nowadays, if an application takes 4GB of RAM, that should be the minimum. Having this solution on-prem, is taking more memory and that memory footprint should be minimized.

I've been using this solution for five years. 

The solution is stable. 

The solution can be scaled horizontally and vertically.

The initial setup is straightforward and took a maximum of two hours. Our technical team had eight people dealing with the end-to-end deployment. 

I recommend this solution, it's an industry standard product.

I rate this solution eight out of 10. 

We are a financial institution and we are using this solution for the APIs that we provide.

The biggest advantage of this solution is that it is very easy to learn, and very easy to build applications. The learning curve is not steep and it is something that you can pick up within about two weeks.

There are a lot of inbuilt interfaces like ISO and SAP. Having all of these interfaces already built makes integration very easy and straightforward.

One drawback that I have found is that there are issues with using the Java connector. I was running out of heap space.

I have been working with IBM Integration Bus for three years.

The stability is fantastic.

With respect to scalability, IBM Integration Bus is very good.

I have been in contact with technical support and I found that they were very good.

I have not really used any other ESB solutions.

I was not part of the original deployment.

I like to view comparisons to see what people have to say about similar products because I have just recently changed jobs and my new company is trying to purchase an ESB. Although I fully recommend IBM Integration Bus, I think it is important to look and see if other solutions may be better.

Generally speaking, this is a very good product. It is easy to learn and use, and it is robust as well.

I would rate this solution a nine out of ten

We are a software development company and we use IBM Integration Bus for integrating different internal systems for the customer side and to integrate the internal systems with external systems for different kinds of flows.

There are three elements that make IBM Integration Bus very important for our organization's payroll systems which are the solution's high scalability, performance, and reliability.

The current version of IBM Integration Bus, now called App Connect Enterprise, provides operators for deployment in the OpenShift cluster, which makes deployment much easier and significantly increases the scalability and reliability of the integration solutions.

I have been using IBM Integration Bus for approximately two years.

IBM Integration Bus is very reliable and stable. If the right configuration is done, in operation everything is runs very well. If you have not configured everything well then you most likely will have some stability or performance issues.

IBM Integration Bus is scalable. If you are using OpenShift then the solution's scalability becomes even better.

We have approximately 12 people who have the experience to use this solution.

I would rate the support from IBM Integration Bus a seven out of ten. They are very helpful but sometimes it takes too long for them to respond.

The implementation of the solution at the beginning phase can be complicated. The time it takes for the implementation depends on the environment a lot of other factors.

The development toolkit that is provided is very good. It helps to configure all the message flows and data transformation. They also provide Extended SQL language (ESQL) for different types of data transformation.

The solution does not require much maintenance.

IBM provides a quite complicated licensing model.

We have evaluated other solutions and we have found that IBM solutions to be highly stable and scalable.

I would recommend this solution to others.

I rate IBM Integration Bus an eight out of ten.