What is your primary use case for IBM Integration Bus?

The use cases of IBM Integration Bus include transforming data from one system to another or from one application to another. Some of the systems are expecting a different format, while others may accept only a certain format. We do the transformation and routing of the data. IBM Integration Bus brings very beneficial improvements, as we use it for any data transformation. We utilize IBM Integration Bus to transform data, such as when someone has to buy one product. All the data is available in SAP, which includes amounts, purchase orders, and any related details, so the Finance team needs to know how many orders they have completed and what the sales amount and types of purchases are. Everything is examined, and the Finance team knows all the data through the IBM tool we are using for transformations.

IBM Integration Bus is primarily used for integrating different channels with the main core banking system, specifically in the banking sector. It can also be used to connect this Integration Bus in other verticals to easily add or integrate surrounding applications or channels with the main core application.

Our primary use case for IBM Integration Bus is that it is rigid, scalable, and offers high availability with minimal to no data loss. We have developed services that utilize IBM MQ to transfer data. Our service is running every day at the airport.

IBM Integration Bus integrates various systems by receiving, transforming, and routing messages in different formats, such as XML or JSON. It supports integration between different applications and services within the organization, enabling effective communication.

I worked with Integration Bus for a UK-based insurance client and banking domain client. Our main use cases are for integrating different systems. We were involved in integrating their master data management domain.

We use IBM Integration Bus to communicate with existing systems like COBOL. We utilize COBOL copybooks, which we need to transform for downstream systems. We create schemas and leverage the COBOL capabilities to convert messages to the target systems. This is one example of our integration use case.

Typically, when engaging in application integration, especially when receiving data through an integration gateway, the common practice involves routing or transforming the message. This process aims to enrich the data before forwarding it to other downstream systems, and we utilize IBM Integration Bus for it.

We use external integration with other entities and solutions outside of the enterprise.

We use the product to connect legacy systems to newer accounting platforms. SAP, more specifically.

We use IBM Integration Bus within a finance domain.

It plays the integration role between different systems in banks and telecommunication. In my case, the integration uses connection protocol to, like, servers, the MQ. It also involves sometimes consuming patch files and constructing different calls to different backends, collecting the result, and sending it to the callers.

The product helps us develop integration applications. It also enables communication between applications from different environments.

We work with multiple customers, and this is one of the tools we use to help them with integration.

The solution is deployed on-premises.

Our organization is a bank, so we use IBM Integration Bus for integration with core services and test applications.

It is used for the banking domain and telco. We use it for integration between vendors from core banking and the other channels, for example, buyers, CRM and codes.

We are using IBM Integration Bus as a messaging solution for our customers. They have legacy systems. Some are MQ systems, file-based systems, app-based systems, and ERP systems. We place it in the middle of integrations. One system sends messages or communicates to another system written by us.

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

IBM Integration Bus is mainly used to integrate banking systems.

IBM Integration Bus can be deployed in many ways, such as on-premise, cloud, and hybrid. The current customer that we have wants to have a hybrid deployment. We're investigating how they can manage to do it. For the hybrid deployment, they will have an instance running in a docker image, or in an Amazon AWS. The heavy operations will be done by the on-premise version. Which is what we currently have.

We use the solution for synchronizing data across the enterprise and opening data to extend its use by simplifying and making it consistent regardless of its source. It's for installing a line of indirection between data source and consumer to reduce contention at the source, and to add security, audit, and combine data from multiple places. With it, we are implementing GDPR rules on data use, compensating for systems being unavailable, and delivering low latency for website users. I have designed solutions for payment processing, Service-Oriented Architectures, micro-service architectures, data sharing and synchronization, and point to point data sharing using this product across banking, retail, and many other industries.

A retail customer used it to connect with the backend Oracle retail system. There were some plugins that were available for that particular use case on top of the Integration Bus for message transformation, schemas, etc. It has also been widely used in banking. It is mostly deployed on the hardware, but it is also available on the cloud.

We use IBM Integration Bus for application integration. For example, when application A needs to communicate with application B, if Application A is sending the message data in XML format but application B understands the data in JSON format, there needs to be a tool that helps to transform the message data and route the data from one endpoint to another. In such a use case, we use IBM Integration Bus. I'm working on version 10.0.0.12 of IIB, but we will be migrating the project that I'm currently working on to IBM App Connect Enterprise. It will most probably happen in the summer of this year. It is deployed on-premises. After the migration to IBM App Connect Enterprise, we're planning to migrate to the cloud from on-premises.

We use IBM Integration Bus as a bank middleware solution.

My primary use case of IBM Integration Bus is for designing and developing solutions. We use App Connect Enterprise as a micro ESB and, in cases where we need rapid development, as a microservices platform as well. I'm currently dealing with an on-premises version, but it's deployed on an internal cloud.

My only client at the moment is a national government bank. Currently, the IBM Integration Bus is the integration platform for all the various departments of the bank. There are probably six or seven major departments across the bank that subscribe to or use the integration services like MessageQ, Broker, or the platform's orchestration capabilities. And we have a team of about 15 people managing it. Integration Bus has also been put in place to lay the foundation for hybrid integration into the two specific systems on the cloud. We are still deploying it, so we haven't gotten into any actual use cases yet. In the past, it was relatively easy for the team, but I don't think they've ever leveraged the suite's full capabilities. It hasn't been easy in some instances because the reserve bank is unique. It's not the same as other financial institutions, but we've had challenges on the platform before.

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.

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

In general, we are using IBM Integration Bus for integration purposes only because we have multiple applications to integrate.

We are, of course, using the latest version. We use the solution for bridging the gap between different legacy systems. Re-usability is another function of the solution. So too, we use it to limit the challenges faced between different systems that are unable to communicate at the same speed and rate, or that need to talk among different systems, to utilize a channel which is bigger and better, to make use of the back-end or in respect of some other point-to-point integration need. As such, our uses for the solution vary depending on the customer. An example would be that which relates to a banking industry, for which there would be a core banking system, the need for card systems, ATM transactions, et cetera. Middleware plays a key role in the usability of these services. The goal is to avoid point-to-point integration between the channels and the back-end systems making use of the solution.

We primarily use the solution for integrations of traffic between internal applications, communications, and transactions between various internal applications. We also use it for integration with various external parties.

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.

Although my organization is not a bank, it does have communication needs throughout its different departments.

We are a system integrator and this is one of the products that we propose for our clients. Some of our clients for this product are banks.

We use the solution for data integration. We have different kinds of information such as file feeds, messages, and inbound software that need to be confirmed and delivered to the platform of our clients as a message.

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.

We are working on MQ, soap and rest based services. Some clients are accessing our services and vice versa.

I'm responsible for Strategy and Architecture for an IT consulting company they are partners with IBM.

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.

We are a solution provider and this is one of the products that we implement for our clients. Usually, they want to use this for consolidating the services. It is used to integrate their core insurance systems with the rest of the environment.

I am a developer and this is one of the products that I use in that capacity.

We use the solution for supply chain management between ERP systems and warehouse management systems. We use it with multiple external partners.

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.

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 primary use case for the solution is infrastructure optimization. Most times the client wants to optimize their integration infrastructure and they want to simplify it. When they feel home-grown solutions are not scaling well for them in terms of complexity, in terms of speed to market, they look to this solution. Projects take long and they break down all the time. That's when the clients start thinking Integration Bus. It's a solution that offloads all the integrations of their system.

We use it for migration.

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

We implement this solution for our customers.

The solution is primarily a middleware. It's security-enabled and we are using the same credentials for development. We plan on making a backend to handle growing requests.

We primarily use the solution as a basic integration platform for all the complicated technology solutions we have.

Our primary use for this solution is to integrate different applications into the aviation area. We have an on-premises deployment.

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.

The IBM Integration Bus platform is Advanced Enterprise service bus , Typically used in SOA Environments . with newer version it can work it container based platforms and can be used to implement Micro services. We have implemented IIB/WMB Based Solution in multiple organizations helping them to adopt Service oriented architecture , and eliminating point to point integrations.

My primary use case of this solution is for establishing an enterprise service between the orchestrated transactions of two different channels. This is the main purpose of this product.

Our primary use case is a content-based tool for system messaging. IIB comes with IBM MQ as its messaging backbone. With respect to our requirements, IIB fits well, and it does its job.

We have used IIB as a complete ESB solution with IBM MQ for various financial institutions. IIB supports various connectors, message formats, and transport protocols. Its transformation language, ESQL, is easy to learn and use. Rich support of the mapping node (GUI mapping), JavaCompute Node, XSL, etc. make it useful and developer friendly. IIB 10's primary features: * REST API design and development support out-of-the-box. OpenAPI compliant. * Lightweight run time, hence it is ideal for Docker/microservices implementation. * Several ways to admin using web interface, REST API admin capabilities, and console administration. * Long list of already built-in connectors for legacy systems (CICS, MQ, etc) and modern system connectors (Salesforce, LoopBack, etc.). * Long list of parsers (XMLNSC, DFDL, JSON, etc.). * Easy to understand documentation with a huge list of examples and tutorials.