Apache Camel - department-of-veterans-affairs/abd-vro GitHub Wiki
Apache Camel 3.11
VRO uses Apache Camel 3.11.0, which uses Spring Boot 2.5.3.
Apache Camel 3.13 through 3.15 are not compatible with gov.va.starter
's current Spring Boot version (2.5.2).
Camel-related code is limited to a very small portion of the codebase but is important for routing requests through desired workflows and to microservices.
Why Apache Camel?
Apache Camel provides a well-tested and stable implementation of Enterprise Integration Patterns (EIP) so that we can focus on VRO functionality and less on "glue code".
- We use it to define and quickly update business workflows that connect VRO functionalities (a.k.a. microservices).
- Camel provides many core components and non-core components to connect to message queues, databases, email services, AWS services, etc.
- Using Camel encourages VRO functionalities to be loosely-coupled and single-responsibility with the intent of improving software agility.
CamelApp
To demonstrate how a Spring-based app uses Apache Camel to implement a microservice architecture, a sample CamelApp project is available for you to fork. Use it to:
- familiarize yourself with Java, Gradle, Spring, and Camel tools
- experiment with the code
For a description of specific uses in VRO, see Routing API requests.
Camel Concepts
Design concepts as they are applied to VRO: Camel Components, Camel Routes, and microservices
Most VRO features are implemented into Camel Components (think Lego bricks). These components are reusable and replicable, and should be idempotent and robust to failures. Camel provides many components (mostly to integrate with other tools), and we can implement our own to process claims, generate PDFs, assess health data, etc.
A processing workflow is implemented by connecting these components with Camel Routes. These routes can include actions that perform basic logic, data transformations, and filtering to map and send a payload (i.e., a JSON data object) for consumption by the next component.
When there is a client to interface with some external system (e.g., Lighthouse API), it should typically be implemented as a microservice that listens on and responds to a message queue (e.g., RabbitMQ) so that anything (e.g., Camel component or route) can use the client. These microservices should also be idempotent and robust to failures. In a Camel route, a microservice can be treated like a Camel component.