CamelBee - Instant Apache Camel Microservices Generator

🎯 How to Use the Initializer Scene

The Initializer Scene is your starting point for creating production-ready Apache Camel microservices. Follow these steps to configure and generate your project visually in 3D.

Launch the WebGL Application Open CamelBee in your browser and click the "Initializer" button from the main menu to enter the generation scene. Try CamelBee WebGL Application
Select Your Input Interface and Define Operations Choose how your microservice will receive requests: REST API, MCP Server, Kafka consumer, WebSocket server, GraphQL endpoint, SOAP service, JMS queue consumer, AMQP consumer, File watcher, or a database poller. Supported databases include **MariaDB, PostgreSQL, MySQL, Oracle, MSSQL, and DB2**. Click on the interface type in the 3D environment to configure it.
Configure your interface by selecting it, then specify the request and response content types (such as JSON, XML, Avro, or Protobuf) of the Order and Order List data. You can also enable OAuth if security is required.
You can also select a database poller with the SQL or JPA consumers, including **MariaDB, PostgreSQL, MySQL, Oracle, MSSQL, and DB2**.
Add the required CRUD operations to your service, such as Create Order, Create Batch Orders, Get Order, List Orders, Update Order, Replace Order, and Delete Order. Each operation leverages the predefined Order schema for the interfaces and the Purchase schema for the backend implementations. After generating the microservice, you will have a fully functional end-to-end service complete with mappings, unit and integration tests, and stubbing based on these object models. Additionally, multiple operations can be defined within a single interface.
Configure Output Backends Connect your operations to one or more backends: REST APIs for external services, Kafka topics for event streaming, SQL databases for persistence, JPA entities for ORM, AMQP/JMS for messaging, SOAP services, or file outputs. Multiple backends can be connected to a single operation.
Configure your backends by selecting them, then specify the request and response content types (such as JSON, XML, Avro, or Protobuf) of the Purchase and Purchase List data.
Choose Your Runtime Select either Spring Boot or Quarkus as your runtime framework. Both options include full dependency injection, health checks, metrics, and production-ready configurations.
Configure Project Settings Set your project name, group ID, artifact ID, and package structure. Add any additional dependencies or plugins you need.
Generate & Download Click the "Generate" button to create your microservice. CamelBee will compile a complete maven project with Camel routes, tests, Docker configurations, and documentation. Download the ZIP file and import it into your favorite IDE.
Import Project into Your IDE Extract the downloaded ZIP file and open it in IntelliJ IDEA, Eclipse, or VS Code. The project includes a standard Maven structure that will be automatically recognized by your IDE.
Explore Project Structure Review the generated project structure.
Inside the src/main/resources directory, you'll find the application configuration files and OpenAPI specifications for both the exposed interface and the backend services.

The src/main/java directory contains the configurations, MapStruct mappers, global error handler, domain models, and Camel routes — in other words, your main production code.

In this demo, we selected a REST interface with "Create Order" and "List Orders" operations, along with REST and Kafka backends. As a result, the initializer generated only those routes, which are fully functional from end to end.

Note that if you select different interfaces, backends, or content types, the initializer will automatically include the corresponding specifications—such as WSDL, Protobuf, Avro, XSD, or SQL files—in the resources folder. It will also configure the necessary plugins in the pom.xml file to generate Java objects from those specifications.

While implementing your own logic, you'll need to **overwrite the provided specifications** in these YAML, WSDL, Protobuf, or Avro schema files with your **own schema definitions and package names** to match your specific service requirements.

Since this example uses a REST interface and REST backend, the initializer adjusts the pom.xml plugins to generate Java DTO objects directly from the OpenAPI specifications for both the interface and the backend.
Review the Generated Camel Routes Open the Camel route classes under the package com.mycompany.routes to explore the consumer and producer routes automatically generated based on your selected interfaces and backend systems. Each route includes appropriate error handling, logging, and transformation logic aligned with your configuration.

Consumer Routes: The external interface routes of your microservice, located in the package com.mycompany.routes.consumer. These routes define the global error handler configuration, ensuring that any exceptions raised within the consumer, central, or producer routes are processed consistently through the same global error handling logic.
```
/**
 * Configure.
 *
 * @throws Exception the exception
 */
@Override
public void configure() throws Exception {
    camelBeeRouteConfigurer.configureRoute(this);
    errorHandler(genericExceptionHandler.appErrorHandler());
}
          
```
Central Routes: The core business logic and orchestration flows routes, also found under the package com.mycompany.routes.consumer. Since the global error handler is configured in the consumer routes, any errors occurring within these central routes are also managed by the same error handling mechanism, ensuring consistent behavior across all route layers.

Producer Routes: These routes connect to the backend systems of your microservice, located in the package com.mycompany.routes.producer. Errors in producer routes are likewise captured and handled globally through the error handler defined in the consumer route configuration.

These pre-generated Camel routes serve as the foundation for your own implementation, using your custom object model and business logic. You can either rename and modify the existing routes to fit your needs, or create new Camel routes from scratch using the generated ones as examples—then remove the originals once your custom routes are in place.
Review the MapStruct Mapper The mapping between API models, Domain models, and Infra models is managed using MapStruct. The generated mapping classes can be found under the package com.mycompany.mapper.*.

Since the mappings between the API Order and Domain Order, as well as between the Domain Order and Infra Purchase, are mostly one-to-one, the mappers generated by the initializer can serve as useful references when creating or customizing your own mappings.

Note that not all layers (API, Domain, and Infra) are always required. At this stage, you should determine which model layers are necessary for your specific use case.

How Apache Camel uses these mappers
Apache Camel can automatically apply MapStruct mappers when using the convertBodyTo processor. It selects a mapper that converts from the current body type to the target type:
```
from("direct:createOrder")
    ...
    .convertBodyTo(com.mycompany.model.domain.Order.class)
    ...
```
Spring Boot: How Mapstruct Mappers are injected in the Camel Context
Shared configuration is defined in SharedMapperConfig:
```
package com.mycompany.config;

import org.mapstruct.InjectionStrategy;
import org.mapstruct.MapperConfig;

@MapperConfig(componentModel = "spring", injectionStrategy = InjectionStrategy.CONSTRUCTOR)
public interface SharedMapperConfig {}
```
Camel discovers mappers via the property in application.yaml:
```
camel:
  mapstruct:
    mapper-package-name=my.company.mapper
```
Quarkus: How Mapstruct Mappers are injected in the Camel Context
Shared configuration is defined in SharedMapperConfig:
```
package com.mycompany.config;

import org.mapstruct.MapperConfig;
import org.mapstruct.NullValuePropertyMappingStrategy;

@MapperConfig(componentModel = "cdi", nullValuePropertyMappingStrategy = NullValuePropertyMappingStrategy.IGNORE)
public interface SharedMapperConfig {}
```
No additional package configuration is needed — Quarkus automatically discovers all CDI mappers at build time.
Check Dependencies (pom.xml) Review the pom.xml (Maven) file to see all the dependencies automatically included based on your selected interfaces and backends—such as camel-kafka, camel-rest, camel-jpa, TestContainers, WireMock, and more.
Explore the Unit Test Structure Navigate to src/test/java to find unit tests for MapStruct mappers, Central Routes and also test data creation utility classes under com.mycompany.utils.testdata package. All tests are ready to run.

Run the tests and verify that they all pass successfully! Later, you can use these existing test implementations as a foundation for creating new unit tests to cover your own schemas and custom logic. You may rename or modify the provided test methods, or create new test classes using the existing ones as examples. Once your own tests are in place, you can remove the pre-generated ones.
Explore the Integration Test Structure Navigate to src/integration-test/java to review the integration test setup. You'll find both sunny-day and rainy-day test scenarios covering all interfaces and selected operations. These integration tests use TestContainers to spin up real databases and message brokers, while WireMock simulates external REST and SOAP services.
All tests are preconfigured and ready to run.

Pre-created test data for all scenarios and supported content types is located under src/integration-test/resources/data/inttest/. This data is generated using the utility class com.mycompany.utils.testdata.MultiFormatTestDataGenerator.

If your project uses only JSON or XML content types, you may not need this dynamic test data generator and can simply create your test data manually. However, it's recommended to maintain a dynamic data generator class like this one for better flexibility and consistency across tests. For Protobuf and Avro formats, this utility is essential to produce properly serialized test data. When implementing your own logic, you can reuse this class as a base or rename and customize it to suit your project's specific test data requirements.

The TestContainers setup is defined in the com.mycompany.itest.TestContainerConfiguration class, which uses the src/integration-test/resources/compose-docker.yaml file to initialize the backend containers required by the microservice during integration testing.

Run the tests and confirm that they all pass successfully! Later, you can use these existing test implementations as a foundation for developing new unit and integration tests for your custom schemas and business logic. You may rename or update the existing test methods, or create new test classes using them as references. Once your custom tests are complete, you can safely remove the pre-generated examples.
Implement Your Business Logic You now have a complete, fully functional microservice foundation with all dependencies, routes, mappers, unit tests, and integration tests already configured for the selected interfaces, operations, and backends. The generated example focuses on the Order and Purchase schemas and demonstrates simple one-to-one mappings between the interface and backend services. In your own implementation, you'll need to update or rewrite the generated code to reflect your specific data model and business logic.

What's important is that CamelBee Initializer provides you with a fully working codebase — complete with unit and integration tests, pre-created test data, and a test data generation utility class. From this point forward, you can build upon this foundation by renaming and extending the generated components or by creating your own classes, using the existing ones as working examples.

If you prefer, you can also duplicate the generated microservice created by the initializer — keeping one as a clean, working reference and using the other as your development version. In your development copy, you can freely modify, rename, or remove the generated Java classes as you implement your custom logic. Whenever you encounter compilation issues or failing tests, you can compare your changes with the untouched reference version to quickly identify and resolve problems.

Once your implementation is complete, you can safely remove the pre-generated examples.

Try CamelBee WebGL Application

💡 Tip: Experiment with different configurations in the 3D scene before generating. You can always go back and modify settings without losing your work.

🔍 How to Use the Debugger Scene

The Debugger Scene lets you visualize message flows through your Camel routes in real-time 3D. Connect your running microservice and watch integration patterns come to life.

Start Your Microservice
Begin by building your project:
```
mvn clean compile
```
Next, start the required backend services using Docker Compose:
```
cd src/integration-test/resources
```
```
docker compose -f compose-backends.yml up -d
```
Then, launch your microservice:
Quarkus:
```
mvn quarkus:dev
```
Spring Boot:
```
mvn spring-boot:run
```
You can also start the Quarkus application directly from your IDE using the Quarkus plugin:
Connect to the Debugger Scene
In the WebGL application, click the "Debugger" button. Enter your microservice's URL (default: http://localhost:8080) and click "Debugger" to connect. Try CamelBee WebGL Application
View Your Route Topology
After connecting, your Camel routes will be displayed as a 3D graph, showing all endpoints and their interconnections. Use your mouse to navigate and explore the topology in 3D space.
Start Capturing Messages
Enable the "Start Capturing Messages" toggle. CamelBee Notifiers will begin collecting and displaying messages within the Debugger Scene.
Trigger Your Microservice with Postman
Use Postman to send requests to your microservice.
Visualize Message Flow Between Routes and Endpoints
Observe how messages move between routes and endpoints. Click any point along the connections to view detailed request and response data.
Scroll Through the Timeline
Use the timeline to scroll backward or forward in time, exploring message interactions and flow history for a deeper understanding of your routes.
Why Use the Debugger Scene?
The Debugger Scene brings your microservice architecture to life. It visually maps out all interfaces, routes, backends, and their connections in a stunning 3D topology — making complex systems instantly understandable at a glance.

This powerful visualization isn't just for developers. Testers, architects, and designers can all use it during system or user acceptance testing to clearly see how everything fits and interacts — no deep technical knowledge required.

For developers, the Debugger Scene is a game changer. It allows you to trace the exact flow of messages through your microservice, making it easier than ever to verify implementations, troubleshoot issues, and ensure your logic is secure and efficient. Even junior developers can confidently explore and understand the system's behavior with ease.

Try CamelBee WebGL Application

💡 Tip: Use the Debugger Scene to understand complex routing logic, verify transformations, and identify bottlenecks in your integration flows.

📊 How to Use the Metrics Scene

The Metrics Scene provides real-time performance monitoring of your Camel microservices with interactive 3D dashboards. Track throughput, latency, errors, and resource usage at a glance.

Connect Your Running Service Click the "Metrics" button in the WebGL application. Connect to your microservice's metrics endpoint (default: http://localhost:8080) to start receiving real-time performance data. Try CamelBee WebGL Application
View the Metrics Dashboard Track memory and CPU utilization, total thread counts, and garbage collection (minor and major) times across all routes. Detect bottlenecks and enhance your microservice performance using dynamic 3D metrics dashboards. Each route and endpoint has its own metrics node so you can see how many times the routes, endpoints or the error route are being called.
Time-based charts for Memory, CPU, Total Threads, and GC Visualize key performance metrics over time to monitor trends, detect anomalies, and optimize system behavior with ease.
Full Metrics Reports Also you can see the full metrics reports available from the underlying framework springboot/quarkus and you can easily filter the ones you want to see
Why Use the Metrics Scene?
The Metrics Scene gives you a real-time, 3D visualization of your microservice performance. It transforms raw metrics into an interactive environment where memory, CPU usage, threads, and garbage collection activity come to life across your entire service topology.

Instead of combing through endless logs or static dashboards, you can instantly identify bottlenecks, performance spikes, and route-specific inefficiencies — all within a visually intuitive scene that updates live as your services run.

The Metrics Scene empowers developers, architects, and DevOps engineers to monitor, analyze, and optimize distributed systems effortlessly. Whether you're fine-tuning performance, verifying deployments, or demonstrating system health to stakeholders, it provides the clarity and insight needed to keep your microservices running smoothly.

Try CamelBee WebGL Application

💡 Tip: Use the Metrics Scene during load testing to identify performance bottlenecks and optimize your Camel routes before production deployment.

🚀 Generate and Monitor Camel Microservices Instantly

Generate, Debug, and Monitor—All in Your Browser

🎯 Initializer Scene

🔍 Debugger Scene

📊 Metrics Scene

🎯 How to Use the Initializer Scene

🔍 How to Use the Debugger Scene

📊 How to Use the Metrics Scene

✨ Key Features

⚙️ Contract-First Camel Routes

🛰️ Real-Time WebGL Monitoring

🧠 AI Assistant (Coming Soon)

✅ Complete Test Coverage

🧪 Testing & DevOps Ready

Interfaces & Backends

📝 Articles & Tutorials

🚀 Building an MCP Server with Streamable HTTP Protocol

🔌 Already Have Camel Microservices?

📦 Spring Boot Core

⚡ Quarkus Core