Red Hat Fuse

Dynamic case management in the event-driven era

Dynamic case management in the event-driven era

Case management applications are designed to handle a complex combination of human and automated tasks. All case updates and case data are captured as a case file, which acts as a pivot for the management. This then serves as a system of record for future audits and tracking. The key characteristic of these workflows is that they are ad hoc in nature. There is no single resolution, and often, one size doesn’t fit all.

Case management does not have structured time bounds. All cases typically don’t resolve at the same time. Consider examples like client onboarding, dispute resolution, fraud investigations, etc., which, by virtue, try to provide customized solutions based on the specific use case. With the advent of more modern technological frameworks and practices like microservices and event-driven processing, the potential of case management solutions opens up even further. This article describes how you can make use of case management for dynamic workflow processing in this modern era, including components such as Red Hat OpenShift, Red Hat AMQ Streams, Red Hat Fuse, and Red Hat Process Automation Manager.

Continue reading “Dynamic case management in the event-driven era”

Share
VS Code Language support for Apache Camel 0.0.20 release

VS Code Language support for Apache Camel 0.0.20 release

During the past months, several noticeable new features have been added to improve the developer experience of application based on Apache Camel. These updates are available in the 0.0.20 release of Visual Studio (VS) Code extension.

Before going into the list of updates in detail, I want to note that I mentioned in the title the VS Code Extension release because VS Code extension is covering the broader set of new features. Don’t worry if you are using another IDE, though, most features are also available in all other IDEs that support the Camel Language Server (Eclipse Desktop, Eclipse Che, and more).

Continue reading “VS Code Language support for Apache Camel 0.0.20 release”

Share
Decoupling microservices with Apache Camel and Debezium

Decoupling microservices with Apache Camel and Debezium

The rise of microservices-oriented architecture brought us new development paradigms and mantras about independent development and decoupling. In such a scenario, we have to deal with a situation where we aim for independence, but we still need to react to state changes in different enterprise domains.

I’ll use a simple and typical example in order to show what we’re talking about. Imagine the development of two independent microservices: Order and User. We designed them to expose a REST interface and to each use a separate database, as shown in Figure 1:

Diagram 1 - Order and User microservices

Figure 1: Order and User microservices.

Continue reading “Decoupling microservices with Apache Camel and Debezium”

Share
Autoscaling Red Hat Fuse applications with OpenShift

Autoscaling Red Hat Fuse applications with OpenShift

In this article, we demonstrate Red Hat OpenShift’s horizontal autoscaling feature with Red Hat Fuse applications. The result is a Spring Boot-based application that uses the Apache Camel component twitter-search that searches Twitter for tweets based on specific keywords. If traffic or the number of tweets increases, and this application cannot serve all requests, then the application autoscales itself by increasing the number of pods. The ability to serve all requests is monitored by tracking this application’s CPU utilization on a particular pod. Also, as soon as traffic or CPU utilization is back to normal, the number of pods is reduced to the minimum configured value.

There are two types of scaling: horizontal and vertical. Horizontal scaling is where the number of application instances or containers is increased. Vertical scaling is where system resources like CPU and memory are increased at the running application’s or container’s runtime. Horizontal scaling can be used for stateless applications, whereas vertical scaling is more suitable for stateful applications.

Continue reading “Autoscaling Red Hat Fuse applications with OpenShift”

Share
How to reduce Red Hat Fuse image size

How to reduce Red Hat Fuse image size

Red Hat Fuse is a leading integration platform, which is capable of solving any given problem with simple enterprise integration patterns (EIP).  Over time, Red Hat Fuse has evolved to cater to a wide range of infrastructure needs.

For more information on each of these, check out the Red Hat Fuse documentation. The Fuse on Red Hat OpenShift flavor uses a Fuse image that has runtime components packaged inside a Linux container image.  This article will discuss how to reduce the size of the Fuse image. The same principle can be used for other images.

Continue reading “How to reduce Red Hat Fuse image size”

Share
CDC pipeline with Red Hat AMQ Streams and Red Hat Fuse

CDC pipeline with Red Hat AMQ Streams and Red Hat Fuse

Change Data Capture (CDC) is a pattern that enables database changes to be monitored and propagated to downstream systems. It is an effective way of enabling reliable microservices integration and solving typical challenges, such as gradually extracting microservices from existing monoliths.

With the release of Red Hat AMQ Streams 1.2, Red Hat Integration now includes a developer preview of CDC features based on upstream project Debezium.

This article explains how to make use of Red Hat Integration to create a complete CDC pipeline. The idea is to enable applications to respond almost immediately whenever there is a data change. We capture the changes as they occur using Debezium and stream it using Red Hat AMQ Streams. We then filter and transform the data using Red Hat Fuse and send it to Elasticsearch, where the data can be further analyzed or used by downstream systems.

Continue reading “CDC pipeline with Red Hat AMQ Streams and Red Hat Fuse”

Share
API-first design with OpenAPI and Red Hat Fuse

API-first design with OpenAPI and Red Hat Fuse

API-first design is a commonly used approach where you define the interfaces for your application before providing an actual implementation. This approach gives you a lot of benefits. For example, you can test whether your API has the right structure before investing a lot of time implementing it, and you can share your ideas with other teams early to get valuable feedback. Later in the process, delays in the back-end development will not affect front-end developers dependent on your service so much, because it’s easy to create mock implementations of a service from the API definition.

Much has been written about the benefits of API-first design, so this article will instead focus on how to efficiently take an OpenAPI definition and bring it into code with Red Hat Fuse.

Continue reading “API-first design with OpenAPI and Red Hat Fuse”

Share
Subsecond deployment and startup of Apache Camel applications

Subsecond deployment and startup of Apache Camel applications

The integration space is in constant change. Many open source projects and closed source technologies did not withstand the tests of time and have disappeared from the middleware stacks for good. After a decade, however, Apache Camel is still here and becoming even stronger for the next decade of integration. In this article, I’ll provide some history of Camel and then describe two changes coming to Apache Camel now (and later to Red Hat Fuse) and why they are important for developers. I call these changes subsecond deployment and subsecond startup of Camel applications.

Continue reading “Subsecond deployment and startup of Apache Camel applications”

Share
Optimizing Red Hat Fuse 7 Spring Boot container images

Optimizing Red Hat Fuse 7 Spring Boot container images

Working with Red Hat Fuse 7 on Spring Boot is straightforward. In my field experience, I have seen many development (a.k.a. integrator) teams moving to Fuse 7 on Spring Boot for their new integration platforms on Red Hat OpenShift Container Platform (well aligned with agile integration).

Lately, however, I have also seen some teams worried about the size of the final images and the deployment pipeline. In most cases, they had developed a set of common libraries or frameworks to extend or to homogenize the final integration projects. All the cases have the same result:

  • Several dependencies copied in each integration project
  • Always replacing the container images with the latest fat JAR (including the same dependencies) in each build pipeline

Spring Boot is usually packaged as “fat JARS” that contain all runtime dependencies. Although this is quite convenient, because you only need a JRE and a single JAR to run the application, in a container environment such as Red Hat OpenShift, you have to build a full container image to deploy your application.

Continue reading “Optimizing Red Hat Fuse 7 Spring Boot container images”

Share