Since Camel 4, users are able to apply data types to their individual Camel routes in order to transform the processed message content in a declarative way. The data type functionality has been added on top of the well-known Transformer EIP that is a part of Apache Camel since the beginning. This post gives a short introduction to the concept of data types and continues with several examples that show how to use those data types in Camel for instance as a form of Camel route contracts.
Apache Camel 4 was released a few months back. This blog post is a general guideline for Camel users that are seeking information how to migrate from Camel 2 or 3. We plan to launch a series of blog posts in the near future with more specific details on migrating, such as migrating from Camel Karaf to Camel 4 on Spring Boot or Quarkus. Apache Camel 4.0 is a fork of Camel 3.
In this blog post we’ll be talking about GitOps and we’ll provide some approach that we hope can help you understand better how you can do such kind of operations togheter with Camel K. As we’re talking about processes, all the discussion we’re going to provide can be different in each company, environment and according the set of tools you’re using. The idea of the blog is to show the possibilities offered by Camel K in order to help you understand better how you can adapt your own tools and process to Camel K deployment model.
One of the main effort we’re putting in Camel K version 2 is to have a enterprise grade building system. Not that Camel K version 1 has not this capability, but some of the key features are not very explicit. So I thought that, while waiting for Camel K version 2 release, where we’re making all this configuration explicit, I can share some tip on how to improve the capacity to build and have a production enterprise ready environment also in Camel K 1.
This post describes the steps to test a Camel K integration with YAKS both locally and on the Kubernetes platform. What is YAKS? YAKS is an Open Source test automation platform that leverages Behavior Driven Development concepts for running tests locally and on Cloud infrastructure (e.g. Kubernetes or OpenShift). This means that the testing tool is able to run your tests both as local tests and natively on Kubernetes. The framework is specifically designed to verify Serverless and Microservice applications and aims for integration testing with the application under test up and running in a production-like environment.
Testing is probably one of those operations we use to repeat most of the time while building any application. Applications in Camel world are no difference. With the advent of Camel JBang, we have a unified place that can be used to perform our testing/fine tuning locally before moving to a higher environment. During the last years of development, we have noticed that testing or fine tuning an integration directly connected to a Cloud Native environment can result a bit cumbersome.
In Camel K version 10, we’ve released the CLI `promote feature that provides Camel K an opinionated way of promoting an Integration through the stages of software development. This feature unlock the possibility to combine Camel K with external tooling and let the user develop according to any automated release process. We always ear about CI/CD (Continuous Integration/Continuous Delivery and/or Deployment), and in this blog we’re going to see how to make it for any Camel K integration.
Announcing Author-led Training on Camel I’m happy to announce the release of a new course on Apache Camel at Pluralsight. The course, “Fundamentals of Integration with Apache Camel”, by Michael Hoffman, is intended to help you learn the foundations of Camel as well as how to apply it at an enterprise scale. Demonstrations are provided for implementing ETL, Event-Driven Architecture with RabbitMQ and Kafka, and finally, serverless with Camel-K. Please note, Pluralsight is a paid subscription service.
Karavan Serverless What’s new in Karavan preview release 0.0.8? In addition to VSCode extension and Standalone application, Karavan could be deployed in Serverless mode alongside Camel-K on Kubernetes. Karavan Serverless gets and applies Integration Custom Resources directly from/to Kubernetes. Try Karavan Serverless mode on Minikube Install Minikube Install Camel-K Install Karavan serverless git clone --depth 1 https://github.com/apache/camel-karavan cd camel-karavan/karavan-demo/serverless kubectl apply -k karavan -n default Get Karavan URL
Even implementing a simple stateless micro-service, one could face situations where testing becomes hard. A lot of tools and techniques could help, but having something at hand quickly is very handy. In this post, I’m introducing a Quarkus feature that plays nice with Camel in order to mock beans for test purpose. Camel and Quarkus together for mocking beans It’s long known that Camel offers great support for Java beans. Every time a developer needs custom code, this feature comes to the rescue.
Camel and Camel Quarkus are typically used to create integration applications that run as long living processes, a.k.a. daemons or services. In this blog post, we are going to explain a slightly different use case: using Camel Quarkus in programs that exit by themselves after performing some desired tasks. Where can this be useful? The enterprise is full of scheduled batch processing. Say, some system exports some sort of reports daily at 4 a.