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”
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”
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”
In Part 6 of this series, we looked into details that determine how your integration becomes the key to transforming your customer experience. It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint.
Having completed our discussions on the blueprint details, it’s time to look at a few specific examples. This article walks you through an example integration scenario showing how expanding the previously discussed details provides blueprints for your own integration scenarios.
Continue reading “Integration blueprint example for process automation (part 7)”
Continue reading “Getting started with the updated VS Code Yeoman extension for Camel projects”
APIs are the cornerstone of so many recent breakthroughs: from mobile applications, to the Internet of Things, to cloud computing. All those technologies expose, consume, and are built on APIs. And those APIs are a key driver for generating new revenue. Salesforce generates 50% of its revenue through APIs, Expedia generates 90% of its, and eBay generates 60% of its. With APIs becoming so central, it becomes essential to deal with full API lifecycle management. The success of your digital transformation project depends on it!
This article describes a set of full API lifecycle management activities that can guide you from an idea to the realization, from the inception of an API program up to management at scale throughout your whole company.
Continue reading “Full API lifecycle management: A primer”
This article is the second in a series of three articles about Red Hat Integration. The first article described how the new Red Hat Integration bundle allows citizen integrators to quickly provide an API through tools that make creating an API in five simple steps effortless, and we implemented a demo showing the full API lifecycle on Red Hat Integration. The demo was about providing wine labeling and ranking info via APIs.
In this article, I am going to take you further by implementing a real business transaction with Salesforce. We will create an event-driven integration solution with no code on Red Hat Integration.
The idea of this demo is to receive an order from the client web application through a gated, secured API that will then process the order and forward the needed data to the corresponding Salesforce modules. From there, Salesforce will take care of the order content.
Continue reading “Full integration to Salesforce with Red Hat Integration (Part 2)”
Nowadays, API development with proper lifecycle management often takes days if not weeks to get a simple API service up and running. One of the main reasons behind this is there are always way too many parties involved in the process. Plus there are hours of development and configuration.
First, the system analysts negotiate the API interface with the API consumer; then the developer writes the actual API to implement the interface. They then pass the API on to the DevOps team that is in charge of deploying the API. And it is not done yet; then the deployment info needs to be passed to the operations team that is in charge of setting up the API endpoints in the management system and also applying the access policies.
The speed of providing managed API services can be one of the major factors in the success of a company’s business.
This article, which is the first in a series of three articles, describes how the new Red Hat Integration bundle allows citizen integrators to quickly provide an API through tools that make creating an API in five simple steps effortless.
Continue reading “Effortless API creation with full API lifecycle using Red Hat Integration (Part 1)”
Developing Apache Camel and Red Hat Fuse applications inside VS Code is improving! In my previous articles, I’ve mentioned that Camel URI completion is available in VS Code for XML and Java DSL. By leveraging several VS Code extensions, it is now possible to have an end-to-end development experience. The Camel tooling currently available in VS Code is primarily targeting Spring Boot– based Camel applications. The tooling covers the development process from creating a Camel project, testing, and debugging it locally, to automatically-rebuilding and redeploying it on your local OpenShift/Kubernetes instance when you make changes.
There are several ways to leverage the VS Code tooling. I will show the process which I believe is the easiest one to get started with.
Continue reading “Using VS Code to develop Spring Boot-based Camel and Red Hat Fuse projects”
For some integration projects it is helpful to persist application logs in a relational database instead of a plain log file. In this article, I show how to configure a JDBC appender for Red Hat Fuse 7 running in an Apache Karaf environment. There are instructions that describe how to persist messagess with PostgreSQL. Instead, I will show how to setup a JDBC appender for Oracle Database 11g.
I have tested this procedure with Oracle Database 11g Express Edition. A major difference I found is with the table syntax and the fact that the Oracle Database 11g sequence and trigger were required to auto-generate the primary key. Hence, users of Oracle Database 11g should find this article useful.
Continue reading “How to configure a JDBC Appender for Red Hat Fuse 7 with Karaf”