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)”
This is the finale of a series on whether Kubernetes is the new Application Server. In this part I discuss the choice between Kubernetes, a traditional application server, and alternatives. Such alternatives can be referred to as “Just enough Application Server”, like Thorntail. There are several articles on Thorntail (previously known as Wildfly Swarm) on the Red Hat Developer blog. A good introduction to Thorntail is in the 2.2 product announcement.
Continue reading Curse you choices! Kubernetes or Application Servers? (Part 3)
This is the second half of my series covering how to use Red Hat CodeReady Workspaces to develop a Java Enterprise Edition (now Jakarta EE) application using Red Hat JBoss Enterprise Application Platform (JBoss EAP) in the cloud on Red Hat OpenShift/Kubernetes. In the first part, we saw how to:
- Bring your own tools by extending Red Hat’s provided stacks
- Register your own stack within Red Hat CodeReady Workspaces
- Create your workspace using your stack and embedding your JEE project located on a Git repository
For this second part, we’ll start configuring the workspace by adding some helpful settings and commands for building and running a JBoss EAP project. We’ll then see how to use the local JBoss EAP instance for deploying and debugging our application. Finally, we’ll create a factory so that we’ll be able to share our work and propose an on-demand configured development environment for anyone that needs to collaborate on our project.
Continue reading “Streamline your JBoss EAP dev environment with Red Hat CodeReady Workspaces: Part 2”
Recently the Eclipse Che community has been working to make Eclipse Theia the default web IDE for Eclipse Che 7. We’ve added a plugin model to Eclipse Theia that is compatible with Visual Studio Code (VS Code) extensions. Che 7 users will eventually be able to take advantage of extensions that have been written for VS Code in their cloud-based developer workspaces. It’s worth pointing out the popularity of VS Code extensions. Red Hat has contributed extensions covering Java, XML, YAML, OpenShift, and dependency analytics. The Java extension provided by Red Hat has been downloaded over 10 million times!
If you aren’t familiar with Eclipse Theia, Che 6 and earlier used a GWT-based IDE. While it is possible to develop and use plugins in that environment, it is cumbersome. Coming from tools like VS Code, developers expect to be able to customize and extend their workspaces at runtime. Eclipse Theia is an extensible open-source framework to develop multi-language IDEs using state-of-the-art web technologies. Moving to Theia as the default IDE for Che 7 provides a foundation to enrich the developer workspaces in Che. See the series of articles by Stevan LeMeur for more information about what’s coming in Che 7.
This article explains why we decided to add the new plugin model to Eclipse Theia and the benefits for Eclipse Che 7 developer workspaces. I also cover how the new plugin model differs from the existing Theia extension model.
Continue reading “Extending Eclipse Che 7 to use VS Code extensions”
It has been just one month since the announcement of the release of Red Hat CodeReady Workspaces 1.0.0 Beta. Because the cloud/browser-based IDE may be full of promises, developers are usually suspicious, considering them as toys for occasional coders but not suitable for software craftsmen. But you’ll quickly see that Red Hat’s offering can be a good companion for building tailor-made environments.
The goal of this two-part series is to give a walk-through of using Red Hat CodeReady Workspaces to develop a Java EE (now Jakarta EE) application using Red Hat JBoss Enterprise Application Platform (JBoss EAP). I’ll give you details on how to bring your own tools, configure your workspace with helpful commands for JBoss EAP, and share everything so you can easily onboard new developers.
Continue reading “Streamline your JBoss EAP dev environment with Red Hat CodeReady Workspaces: Part 1”
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.
Continue reading “Integration of storage services (part 6)”
Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.
In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.
This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.
Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”
This is the third of a series of three articles based on a session I held at Red Hat Tech Exchange EMEA. In the first article, I presented the rationale and approach for leveraging Red Hat OpenShift or Kubernetes for automated performance testing, and I gave an overview of the setup. In the second article, we looked at building an observability stack. In this third part, we will see how the execution of the performance tests can be automated and related metrics gathered.
An example of what is described in this article is available in my GitHub repository.
Continue reading “Automating tests and metrics gathering for Kubernetes and OpenShift (part 3)”
Nowadays technology companies are adopting the API as one of the most valuable pieces of their business.
What does it mean when we talk about API-first development? We already know the benefits of using an API-first approach:
- Reduced interdependencies
- Earlier validation
- Early feedback with the freedom to change
- Improved efficiency
This article describes what it means to use the API-first design approach. It also walks through an example of using this approach with the OpenAPI Specification and with oas-tools as the Node.js back-end application, which enables you to care only about the business logic. All the validation of incoming requests are done by the
oas-tools library (based on the OpenAPI Specification file provided).
Continue reading “Building a Node.js service using the API-first approach”