Blog Articles

Integration

The rise of microservices architectures drastically changed the software development landscape. In the past few years, we have seen a shift from centralized monoliths to distributed computing that benefits from cloud infrastructure. With distributed deployments, the adoption of microservices, and system scaling to cloud levels, new problems emerged, as well as new components that tried to solve the problems.

By now, you most likely have heard that the service mesh or Istio is here to save the day. However, you might be wondering how it fits with your current enterprise integration investments and API management initiatives. That is what I discuss in this article.

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.

This is not an article about service-oriented architecture (SOA); neither is it a business process management (BPM) article. This article is about how business automation can change the way you create software.

At a first, developers and architects tend to associate the use of BPM suites (or business-oriented architecture) with SOA. This behavior immediately leads to an incorrect bias about the subject.

C-suite executives understand: Transform—or be suppressed by new, disruptive, technology-driven startups. In 2019, business automation is a key transformation that executives will seek in order to improve business performance and lower costs. However, some technology teams are not very open to it. Why?

In the past, BPM suites have been used as big centralized orchestrators for services, external systems, and human tasks. JBoss SOA Platform, released in 2008, is an example of such an integration platform. Unfortunately, this kind of application does not fit new cloud- and microservices-oriented architectures. The good news is that business automation evolved and can help teams to reach the next step in DevOps: BizDevOps.

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.

Microservices architecture is taking over software development discussions everywhere. More and more companies are adapting to develop microservices as the core of their new systems. However, when going beyond the “microservices 101” googled tutorial, required services communications become more and more complex. Scalable, distributed systems, container-native microservices, and serverless functions benefit from decoupled communications to access other dependent services. Asynchronous (non-blocking) direct or brokered interaction is usually referred to as messaging.

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.

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.

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.

In Part 5 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. Now it’s time to cover various blueprint details.

This article covers the final elements in the blueprint, storage services, which are fundamental to the generic architectural overview.

The Red Hat Fuse Tooling team recently broadened its focus from a cross-platform, single-IDE (Eclipse) approach to a cross-platform, cross-IDE approach (Eclipse, VS Code, Che), starting several concerted efforts to provide tools that work across platforms and development environments. Supporting VS Code has become a priority that led us to explore using the Yeoman framework for project and file generation to provide developers a way to jump start their Fuse/Camel development efforts.

This article describes the Yeoman framework and the new Yeoman-based Camel-Project generator the Fuse Tooling team created, and it shows how to install and run the generator.