We have a couple of different interfaces through SOAP, REST, FILE, and Kafka. We receive different inputs from the external interfaces, transform them, and do some kind of enrichment. Finally, we use the routing to publish to downward streams.
We are mainly using it for integration with external solutions. The interface is satisfactory. Mainly, we are using a few integrations with Red Hat Fuse, specifically on OpenShift. Because recently, they renamed it.
Our customers have APIs and they develop them while we are using the gate for the code changes. They commit with the help of Jenkins so we pull that service and install that service on Jabber's use. After that, we create an ACL for that service and the rest is on the web server.
Principal Solutions Architect at a computer software company with 501-1,000 employees
Real User
Top 20
2023-01-10T16:13:35Z
Jan 10, 2023
We use the solution to transform messages and integrate with backend systems for an ESB. We're a solution integrator, so we provide solutions to our customers. The solution is deployed on-premises, but we might move to the cloud version. We're one version behind the latest version.
Sr. Enterprise Architect at a tech services company with 501-1,000 employees
Real User
2022-11-14T17:31:32Z
Nov 14, 2022
The primary use case of this solution is to implement our microservices and refactor our monolith products. Not the environment, but libraries that you can build pretty sophisticated workflows
Integration Consultant at a financial services firm with 1,001-5,000 employees
Real User
2022-06-17T19:30:00Z
Jun 17, 2022
I am an Integration Consultant. At my company, we are using Red Hat Fuse as our integration suite so we can connect all of our different software components.
Red Hat Fuse is mostly used for integration, where you have different sets, different APIs: northbound and southbound, and you just integrate them, so Apache Camel and Red Hat Fuse become an ESB container.
My current project is using OpenShift Container Platform (OCP), which is a container-based application run by Red Hat. We have deployed the Red Hat Fuse and 3scale applications, the API management stuff, and ESB stuff on OCP containers. In my last project, we were using on-prem enterprise systems and applications as well as the container version of Fuse. Now, it is SaaS-based. It is deployed for our client organizations. One of my clients is a postal and telecommunications client. We do some internal systems integrating with them, some scheduled jobs from one system to another system, and data transfers. There are some of the data integrations, postal integrations, and their integrations with different banks on payments. Therefore, we are using Fuse ESB for this. On top of that, we use the 3scale API Management platform, which is also an acquired Red Hat, open-source, SaaS platform for the API management layer. This is basically the use case for data transfers and data transformations from one system to another. In every other project, the use cases are similar in nature. For some security layers on systems, we use OpenID. For integrations with banks, we always use SSO-based integrations. Our client is using the private cloud with its own data center, but interim projects are managed by the client. The services run on 3scale, so the ESB is managed and supported by Red Hat. Red Hat Fuse offers hybrid, on-prem, and cloud versions. The cloud version is managed by IBM Cloud, which is well-supported, but you can set your infrastructure in any cloud version, such as GCP or AWS. Basically, Red Hat-managed infrastructure is on IBM Cloud.
Manager at a energy/utilities company with 501-1,000 employees
Real User
2021-11-25T20:09:00Z
Nov 25, 2021
We have Fuse installed on our on-premises servers, and we use it as an enterprise service bus for connecting different applications. For the time being, all of these applications are installed on-premises. We also use cloud-based applications, but none of them is currently interacting with Fuse. We try to implement third-party applications, if possible, out of the box and, if not, with minimum customization. That leaves something which is very important outside. The applications in many cases have to talk between each other and this is why we need integrations. So, we chose Fuse to act as a membrane or glue for all of our applications to be able to interact. For that particular purpose, we hire third-party development companies that create the integrations for us, but we chose Fuse as this membrane that glues everything together because that was, when we first evaluated it, the best approach that we could select at that point in time.
Manager of Integration Services at a educational organization with 10,001+ employees
Real User
2021-11-09T21:23:00Z
Nov 9, 2021
We use Red Hat Fuse in conjunction with ActiveMQ as our healthcare integration platform. Our electronic medical records (EMR) system is called Epic, and we have to send information from it to all of our ancillary systems. The process is that we take the data coming from Epic and we send it to the downstream apps, for example, to the radiology lab. As an overview, it can be thought of as a hub and spoke model. The EMR sits in the middle, like the center of the universe. We have the Fuse interface and we also have APIM, both of which take information that is coming from EMR. Surrounding these are approximately 140 applications, all receiving data from these systems. We categorize these as lab, radiology, pharmacy, and materials management. A lot of these apps need demographic information. For instance, a patient logs into the system and needs a demographics update. This is one of the purposes that the system serves. It's a well-integrated platform and without the Fuse interface engine, Epic cannot talk to the downstream, ancillary systems.
Systems Architect at a tech services company with 51-200 employees
Real User
2021-11-08T13:41:00Z
Nov 8, 2021
Our company provides IT services. Some of the projects that we do are integration projects and we use Fuse to help customers solve their integration problems. In our latest project, we integrated one legacy system with a new system they were implementing. We used Red Hat Fuse and AMQ to solve the integration situation. One system did not have a modern API, and the only thing exposed as integration points were database tables. The other system had more options, but to connect it to the database interface, we decided to implement a Fuse application to translate things and make it reusable and modular. It's deployed on-prem, as a stand-alone, on Red Hat Enterprise Linux, with an AMQ master sight configuration and two clustered Fuse nodes.
Business Solution Analyst at a manufacturing company with 10,001+ employees
Real User
2020-11-05T06:31:00Z
Nov 5, 2020
We used RH Fuse solution for some integration between the new ERP system to our local legacies systems. We take messages from MQ and then call a local API or leave a transformed file for a legacy system, and viceversa. That has allowed us to reduce legacy system adaptation efforts.
Solution Architect at a tech services company with 5,001-10,000 employees
Real User
2018-11-22T10:29:00Z
Nov 22, 2018
Our primary use case of this solution is to connect our servers and external locations that we are dependent on for solution monitoring. We mainly use it for integration to our other systems. The reason we chose this is because it is good support for Camel which we use to some extent in our solution. Developers like to use Camel in their solutions. It has performed very well.
Red Hat JBoss Fuse is a lightweight, flexible integration platform that enables rapid integration across the extended enterprise - on-premise or in the cloud. JBoss Fuse includes modular integration capabilities, an enterprise service bus (ESB), to unlock information.
We have a couple of different interfaces through SOAP, REST, FILE, and Kafka. We receive different inputs from the external interfaces, transform them, and do some kind of enrichment. Finally, we use the routing to publish to downward streams.
Regarding use cases, the solution is not for internal consumption. It is used for our customers. The solution is an Enterprise Service Bus or ESB.
We are mainly using it for integration with external solutions. The interface is satisfactory. Mainly, we are using a few integrations with Red Hat Fuse, specifically on OpenShift. Because recently, they renamed it.
Our customers have APIs and they develop them while we are using the gate for the code changes. They commit with the help of Jenkins so we pull that service and install that service on Jabber's use. After that, we create an ACL for that service and the rest is on the web server.
We use the solution to transform messages and integrate with backend systems for an ESB. We're a solution integrator, so we provide solutions to our customers. The solution is deployed on-premises, but we might move to the cloud version. We're one version behind the latest version.
The primary use case of this solution is to implement our microservices and refactor our monolith products. Not the environment, but libraries that you can build pretty sophisticated workflows
I use Red Hat Fuse for integrating systems.
I am an Integration Consultant. At my company, we are using Red Hat Fuse as our integration suite so we can connect all of our different software components.
Red Hat Fuse is mostly used for integration, where you have different sets, different APIs: northbound and southbound, and you just integrate them, so Apache Camel and Red Hat Fuse become an ESB container.
My current project is using OpenShift Container Platform (OCP), which is a container-based application run by Red Hat. We have deployed the Red Hat Fuse and 3scale applications, the API management stuff, and ESB stuff on OCP containers. In my last project, we were using on-prem enterprise systems and applications as well as the container version of Fuse. Now, it is SaaS-based. It is deployed for our client organizations. One of my clients is a postal and telecommunications client. We do some internal systems integrating with them, some scheduled jobs from one system to another system, and data transfers. There are some of the data integrations, postal integrations, and their integrations with different banks on payments. Therefore, we are using Fuse ESB for this. On top of that, we use the 3scale API Management platform, which is also an acquired Red Hat, open-source, SaaS platform for the API management layer. This is basically the use case for data transfers and data transformations from one system to another. In every other project, the use cases are similar in nature. For some security layers on systems, we use OpenID. For integrations with banks, we always use SSO-based integrations. Our client is using the private cloud with its own data center, but interim projects are managed by the client. The services run on 3scale, so the ESB is managed and supported by Red Hat. Red Hat Fuse offers hybrid, on-prem, and cloud versions. The cloud version is managed by IBM Cloud, which is well-supported, but you can set your infrastructure in any cloud version, such as GCP or AWS. Basically, Red Hat-managed infrastructure is on IBM Cloud.
We have Fuse installed on our on-premises servers, and we use it as an enterprise service bus for connecting different applications. For the time being, all of these applications are installed on-premises. We also use cloud-based applications, but none of them is currently interacting with Fuse. We try to implement third-party applications, if possible, out of the box and, if not, with minimum customization. That leaves something which is very important outside. The applications in many cases have to talk between each other and this is why we need integrations. So, we chose Fuse to act as a membrane or glue for all of our applications to be able to interact. For that particular purpose, we hire third-party development companies that create the integrations for us, but we chose Fuse as this membrane that glues everything together because that was, when we first evaluated it, the best approach that we could select at that point in time.
We use Red Hat Fuse in conjunction with ActiveMQ as our healthcare integration platform. Our electronic medical records (EMR) system is called Epic, and we have to send information from it to all of our ancillary systems. The process is that we take the data coming from Epic and we send it to the downstream apps, for example, to the radiology lab. As an overview, it can be thought of as a hub and spoke model. The EMR sits in the middle, like the center of the universe. We have the Fuse interface and we also have APIM, both of which take information that is coming from EMR. Surrounding these are approximately 140 applications, all receiving data from these systems. We categorize these as lab, radiology, pharmacy, and materials management. A lot of these apps need demographic information. For instance, a patient logs into the system and needs a demographics update. This is one of the purposes that the system serves. It's a well-integrated platform and without the Fuse interface engine, Epic cannot talk to the downstream, ancillary systems.
Our company provides IT services. Some of the projects that we do are integration projects and we use Fuse to help customers solve their integration problems. In our latest project, we integrated one legacy system with a new system they were implementing. We used Red Hat Fuse and AMQ to solve the integration situation. One system did not have a modern API, and the only thing exposed as integration points were database tables. The other system had more options, but to connect it to the database interface, we decided to implement a Fuse application to translate things and make it reusable and modular. It's deployed on-prem, as a stand-alone, on Red Hat Enterprise Linux, with an AMQ master sight configuration and two clustered Fuse nodes.
We have our web server, our app server, and our database installed using the Red Hat OS.
We used RH Fuse solution for some integration between the new ERP system to our local legacies systems. We take messages from MQ and then call a local API or leave a transformed file for a legacy system, and viceversa. That has allowed us to reduce legacy system adaptation efforts.
We are a solution provider and Red Hat Fuse is one of the products that we have experience working with.
I am using Red Hat Fuse to implement microservices.
Our primary use case of this solution is to connect our servers and external locations that we are dependent on for solution monitoring. We mainly use it for integration to our other systems. The reason we chose this is because it is good support for Camel which we use to some extent in our solution. Developers like to use Camel in their solutions. It has performed very well.