We are using Red Hat Fuse for integration purposes, in particular, we are using it as an integration layer. It's for connecting through various adopters, for example, web service consumptions and other file-based interactions. Red Hat Fuse gives a lot of capabilities for various integration points. We are using Camel, then along with that solution, we are using Red Hat Fuse for all integrations, mainly for file-based and web-service based interactions, as this is how our projects were designed.

Red Hat Fuse is used for communicating and interfacing between systems. It's used for system integration and it's also used for messaging.

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.

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 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 use it because it is easy to integrate with any other application, and when we tried to do an upgrade, it was really easy for us to do that. Plus, it is compatible with other programming languages. Then, to learn and to upgrade ourselves to this platform was easy to train people who were working with us on this platform was not something new or out of the box kind of a thing. It was something people were familiar with, so that is the reason. That is one of the reasons for choosing it. Additionally, we are getting support, specifically continuous support, which is always there for us.

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.

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

Mostly it's combined with API management. It is for API management switches as well as the USB portions. We are using mostly email-based USB portion but we are hosting our API so in terms of exposing the API, it had been used for API management. 

The key portion, for now, is mostly under API management software. It's for the publishing of APIs then pulling the security.

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 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.

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.

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.

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.

We primarily use the solution in financial operations and banking. 

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.

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.

I use Red Hat Fuse for integrating systems.

We have our web server, our app server, and our database installed using the Red Hat OS.

I am using Red Hat Fuse to implement microservices.

We are a solution provider and Red Hat Fuse is one of the products that we have experience working with.