Smile CDR v2024.08.PRE
On this page:

44.0.1Camel Module Overview


44.0.2Apache Camel Introduction


Apache Camel is an Open Source framework that provides robust support for integrating systems.

In Apache Camel, data travelling between systems is represented by a Message, which consists of a body, headers, messageId, and timestamp. Messages participate in a Message Exchange, which is used to represent the request-response pattern.

As a Message travels from system to system, the format of the Message body can vary (i.e. File, JSON, XML, etc.) and Apache Camel provides Type Converters to convert from one data format to another. All data formats available in the Camel Module are listed in the Apache Camel Data Formats section and the Smile Data Formats section.

While a Message is used to represent the data itself, a Route is used to define a series of processing steps a Message should take as it travels from a source to a destination. In Smile, users can define routes using YAML DSL or XML DSL

Processors are another important concept in Apache Camel. Processors can be used to perform logic at any point along a Route. They could be used to translate a message, add headers, perform validation logic, or call a service. Processors are extremely versatile and can be used to perform virtually any logic that can be represented by Java code.

Sometimes it is useful to package related Processors and services together. In Apache Camel, this is called a Component. Components provide access to systems and services that are categorized under a URI scheme. These systems and services can be leveraged as a Message travels along a Route.

For example, the Kafka Component can be used to define the beginning of a Route by consuming Messages from a Kafka topic. It can also be used to produce a Message to a Kafka topic at any point along a Route. All components available in the Camel Module are listed in the Apache Camel Components section and the Smile Component section.

44.0.3Apache Camel Data Formats


Smile supports all Apache Camel Data Formats.

44.0.4Smile Data Formats


Smile supports the following custom Data Formats:

  • IBaseResource

44.0.5Apache Camel Components Components

Smile supports all Core Components. Components

Smile supports the following Non-Core Components:

Note: Jetty component is currently not provided due to version conflicts with the application jetty library version. Netty-http is provided as a replacement, however, make sure to familiarize with netty stream Note

44.0.6Smile Component


The Smile Component is a custom Component with the URI scheme below:


Which can be broken down into:

  • smile: - URI scheme
  • [moduleId] - ID of a Smile module
  • [processorName] - Name of a Smile module processor followed by optional parameters

See Camel Processors for a list of Smile Processors.

See Camel Converters for a list of Converters provided by Smile for automatic conversion between processors.

44.0.7The Spring Context Config Class


This is a Spring Framework AnnotationConfigApplicationContext class. It is characterized by having the @Configuration annotation on the class itself, as well as having one or more non-static factory methods annotated with @Bean, which create instances of your custom Processors or beans that can be used in your YAML DSL or XML DSL Routes.

The following example shows a Spring Context Config class that registers a custom Processor:

public class TestCustomAppCtx {
   public TestCustomProcessor testCustomProcessor() {
      return new TestCustomProcessor();

public class TestCustomProcessor implements Processor {
   private static final Logger log = LoggerFactory.getLogger(TestCustomProcessor.class);

   public void process(Exchange exchange) throws Exception {

      // get incoming Message
      Message message = exchange.getIn();

      // log incoming Message body"Message body: {}", message.getBody(String.class));

      // log incoming Message headers"Message headers: {}", message.getHeaders());

      // Modify Message body
      message.setBody("Hello World!");

      // Add Message header
      message.setHeader("some-header-name", "some-header-value");

      // log new Message body"Message body: {}", message.getBody(String.class));

      // log new Message headers"Message headers: {}", message.getHeaders());
Instead of creating new HapiContext and FhirContext beans, you can @Autowire them from the Smile Application Context. This will help to avoid conflicts during application start up.

44.0.8Packaging Your Camel Module Custom Classes


The Spring Context Config class and all the classes used to create custom Processors and beans must be packaged into a Java JAR file. If you are using Apache Maven as your build system, this just means you should use a normal project with a packaging of jar.

44.0.9Deploying Your Camel Module Custom Classes


Once you have created a JAR with all your custom classes, it should be placed in the customerlib/ directory of the Smile CDR installation, and Smile CDR should be restarted. You can then follow the steps below to create a new Camel module:

  1. Log into the Web Admin Console.
  2. Navigate to the Module Config section (Configuration > Module Config).
  3. Create a new module of type Camel.
  4. Give the module a sensible ID.
  5. Specify your YAML DSL or or XML DSL Routes either by adding text to the Camel Routes (Text) field or by adding a file path to a .yaml or .xml file to the Camel Routes (File) field.
  6. Under the Spring Context Config Class(es) field, enter the fully qualified class name of your Spring Context Config Class. If you have multiple Configuration classes, list them separated by a space or a comma. For example, in the Example Project below, the fully qualified class name would be com.example.camel.TestCustomAppCtx.

44.0.10Example Project


A sample Camel project is available at the following links: Route Using Example Project

Description - Uses the Timer Component to create a Message every second with an empty body. This Message is then passed to the TestCustomProcessor which calls the process(Exchange) method. This method simply logs the incoming Message body and headers, modifies them, and then logs them again.

   <from uri="timer:test"/>
   <to uri="bean:testCustomProcessor"/>

here is the same route in YAML DSL:

   - from:
      uri: "timer:test"
        - to:
            uri: "bean:testCustomProcessor"