Apache Camel Workflows
Four approaches to create your integrations
Developers are often more attached to the developer tools they are using than the software they are actually developing. Sometimes it’s nice to do some pair programming or install new tools to learn about new workflows.
In this blog, we draw some flowcharts to learn all about workflows for creating Apache Camel integrations.
We discuss the following types of workflows:
- Command line
- Traditional
- Hybrid
- Web
Don’t take these workflows too seriously, they are just examples. The idea is to you give an idea on the many ways to work with Camel. At the end, you need to decide for yourself which for workflow works for you and your organization.
Camel Workflows
1. Command Line Workflows
For the keyboard ninjas, let’s start with CLI workflow using Camel with only command line tools. In this workflow, the developer never leaves the console. Using only one text interface makes this workflow both challenging as powerful.
First the developer creates a file on the command line with a text editor like Nano, VIM or if you really want to go hardcore with Emacs. The code is then compiled and build from the command line. In this example, the Camel integrations run with “Camel main”. This is a very minimalistic approach that can be used for standalone integrations.
The benefit of this approach is that you need very few tools and dependencies, and everything is just text. The downside is that you need to learn a lot off the top of your head, and you are not helped with more advanced graphical tools.
If you want to work in a very easy way on the command line, then there is also JBang for Camel as an option:
JBang lets you create and run self-contained Camel integrations in a very simple way with fast feedback (REPL).
2. Traditional Workflows
Traditional, but still highly popular, are workflows that use an IDE to develop and manage the Camel projects. In the following chart, three examples are given:
The first workflow uses IntelliJ to write the code, then builds it with Gradle and runs the integration with Spring Boot. The second workflow which is a bit more traditional uses Eclipse for coding, Maven for building and WildFly for running. Another traditional workflow uses NetBeans, Ant for building and Karaf (OSGi) for running. The last one is really old skool.
Of course any combination of IDE, build tools and runtimes are possible. The bonus you get is that most EDI’s have plugins to work with Camel. For example, Fuse tools for Eclipse:
Or the Camel plugin for IntelliJ:
When build locally or by a CI/CD pipeline, the target software can run as war, jar, or XML on one of the runtimes.
3. Hybrid Workflows
Integrations are perfect to design graphically. It let you easily see how the data will flow through the integration. The idea of the hybrid workflow is that you design the integrations locally and then push them (mostly as YAML files) to the cloud. It’s a three-step process:
- Open Visual Studio Code or a standalone designer tool
- Design the integration graphically
- Push the result YAML file to the cloud
Here are some examples:
If you want to stay relatively close to the Camel concepts, Karavan is a good option. It comes both as a standalone tool and as a Visual Studio Code plugin:
Another Visual Code plugin is the Camel Designer, which focuses on the flow and mapping (through AtlasMap):
A more low code approach is used by Kaoto. Like Karavan it comes both standalone and as Visual Studio Code. It doesn’t focus on the integration patterns, but more as visual flow abstraction on the various text based Camel DSL’s (Domain Specific Languages) that are available.
Interesting is that most of the graphical tools also have support to push the code to a Kubernetes environment to run the generated code. The developer workflow is therefore relatively short. How short, shows the following video:
Do you want to try the graphical tools out without using Visual Studio Code, then you can just open the designer from the links below in a new browser tab:
4. Web workflows
Designing the integration with a graphical tool already makes developing a bit more low-code. There are of course more actions in the workflow to consider, like deploying, managing and monitoring the integration. Also, there are other actions like the documentation of an integration or mapping of your data.
A web-based workflow combines all these actions online by using an iPaaS (integration Platform as a Service). Basically, it means you never leave the browser for any task. There are many providers on the market, but here we discuss only Camel based one.
Some (fully managed) cloud integration platforms are:
- Syndesis / Fuse Online
- Integration Made Easy (by Dovetail)
- Talisman Cloud
Examples workflow are:
The basic workflow is that you create your integration online with a web-based designer. Then you run them in the cloud and monitor and manage those with the same interface. It’s both possible to run them in your own preferred cloud or let them manage by the iPaaS provider. Let’s now discuss the above solutions in more detail.
Syndysis is an open source cloud integration platform.
It abstracts away of Camel and uses a model-driven (low-code) approach towards generating Camel integrations. You can design and monitor for example directly integrations in the browser while they run on OpenShift.
Red Hat offers a fully managed Syndesis version as Fuse Online.
Another cloud-based integration platform is Dovetail (better known as Integration Made Easy):
This platform uses Camel, ActiveMQ, Elastic, MongoDB and other open source technologies through the Assimbly project. It tries to make the workflow to design and run as simple as possible, while still give access to Camel’s more powerful features like integration patterns and languages (Simple, XSLT, Groovy etc.).
There is also a fully-managed version of Karavan through Talisman Cloud
This service enhances the graphical designer with hosting, deploying and monitoring of Camel applications.
These cloud platforms make it very easy to have uniform workflow, but you need of course a subscription and there are limits to the low-code approaches.
Conclusion
The conclusion is that there are million of ways to develop and run Camel integrations. From command-line to writing code, from configuring to designing, and from doing-it-yourself to fully-managed workflows.
They're of course also mixed workflows possible. For example, using a graphical editor to create routes, write code to create custom components and use the command line for building and deploying. Or use a combination of manual written integrations (flexible) and an iPaaS (speed).
Hopefully this blog gave a bit of insight of the possibilities you can try.
