Chapter 3. Camel Quarkus extensions reference

The Camel AMQP component supports message mapping between jakarta.jms.Message and org.apache.camel.Message. When wanting to convert a Camel message body type of org.w3c.dom.Node, you must ensure that the camel-quarkus-xml-jaxp extension is present on the classpath.

When sending JMS message payloads as jakarta.jms.ObjectMessage, you must annotate the relevant classes to be registered for serialization with @RegisterForReflection(serialization = true). Note that this extension automatically sets quarkus.camel.native.reflection.serialization-enabled = true for you. Refer to the native mode user guide for more information.

You can use the quarkus-pooled-jms extension to get pooling support for the connections. Refer to the quarkus-pooled-jms extension documentation for more information.

Just add the following dependency to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.messaginghub</groupId>
    <artifactId>quarkus-pooled-jms</artifactId>
</dependency>

To enable the pooling support, you need to add the following configuration to your application.properties:

quarkus.qpid-jms.wrap=true

If desired, it is possible to use the Quarkus Amazon DynamoDB extension in conjunction with Camel Quarkus AWS 2 DynamoDB. Note that this is fully optional and not mandatory at all. Please follow the Quarkus documentation but beware of the following caveats:

Quarkus-amazon-lambda extension allows you to use Quarkus to build your AWS Lambdas, whereas Camel component manages (deploy, undeploy, …​) existing functions. Therefore, it is not possible to use quarkus-amazon-lambda as a client for Camel aws2-lambda extension.

If desired, it is possible to use the Quarkus Amazon S3 extension in conjunction with Camel Quarkus AWS 2 S3 Storage Service. Note that this is fully optional and not mandatory at all. Please follow the Quarkus documentation but beware of the following caveats:

If desired, it is possible to use the Quarkus Amazon SNS extension in conjunction with Camel Quarkus AWS 2 Simple Notification System (SNS). Note that this is fully optional and not mandatory at all. Please follow the Quarkus documentation but beware of the following caveats:

If desired, it is possible to use the Quarkus Amazon SQS extension in conjunction with Camel Quarkus AWS 2 Simple Queue Service (SQS). Note that this is fully optional and not mandatory at all. Please follow the Quarkus documentation but beware of the following caveats:

If you wish to enable the collection of Micrometer metrics for the Reactor Netty transports, then you should declare a dependency on quarkus-micrometer to ensure that they are available via the Quarkus metrics HTTP endpoint.

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-micrometer</artifactId>
</dependency>

If you wish to enable the collection of Micrometer metrics for the Reactor Netty transports, then you should declare a dependency on quarkus-micrometer to ensure that they are available via the Quarkus metrics HTTP endpoint.

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-micrometer</artifactId>
</dependency>

Implementation of this extension leverages the Quarkus Hibernate Validator extension.

Therefore it is not possible to configure the ValidatorFactory by Camel’s properties (constraintValidatorFactory, messageInterpolator, traversableResolver, validationProviderResolver and validatorFactory).

You can configure the ValidatorFactory by the creation of beans which will be injected into the default ValidatorFactory (created by Quarkus). See the Quarkus CDI documentation for more information.

When using custom validation groups in native mode, all the interfaces need to be registered for reflection (see the documentation).

Example:

@RegisterForReflection
public interface OptionalChecks {
}

In order to use Cassandra aggregation repositories like CassandraAggregationRepository in native mode, you must enable native serialization support.

In addition, if your exchange bodies are custom types, then they must be registered for serialization by annotating their class declaration with @RegisterForReflection(serialization = true).

When using the stats command endpoint, the camel-quarkus-management extension must be added as a project dependency to enable JMX. Maven users will have to add the following to their pom.xml:

<dependency>
    <groupId>org.apache.camel.quarkus</groupId>
    <artifactId>camel-quarkus-management</artifactId>
</dependency>

The following languages are supported for use in the Control Bus extension in Red Hat build of Apache Camel for Quarkus:

<dependency>
    <groupId>org.apache.camel.quarkus</groupId>
    <artifactId>camel-quarkus-bean</artifactId>
</dependency>

template.sendBody(
    "controlbus:language:simple",
    "${camelContext.getRouteController().stopRoute('foo')}"
);

quarkus.camel.native.reflection.include-patterns = org.apache.camel.spi.RouteController

The stats action is not available in native mode as JMX is not supported on GraalVM. Therefore, attempting to build a native image with the camel-quarkus-management extension on the classpath will result in a build failure.

This feature is not supported in Red Hat build of Apache Camel for Quarkus.

camel-quarkus-cxf-soap uses extensions from the CXF Extensions for Quarkus project - quarkus-cxf.

This means the set of supported use cases and WS specifications is largely given by quarkus-cxf.

Red Hat build of Apache Camel for Quarkus manages the CXF and quarkus-cxf versions. You do not need to select compatible versions for those projects.

With camel-quarkus-cxf-soap (no additional dependencies required), you can use CXF clients as producers in Camel routes:

import org.apache.camel.builder.RouteBuilder;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.context.SessionScoped;
import jakarta.enterprise.inject.Produces;
import jakarta.inject.Named;

@ApplicationScoped
public class CxfSoapClientRoutes extends RouteBuilder {

    @Override
    public void configure() {

        /* You can either configure the client inline */
        from("direct:cxfUriParamsClient")
                .to("cxf://http://localhost:8082/calculator-ws?wsdlURL=wsdl/CalculatorService.wsdl&dataFormat=POJO&serviceClass=org.foo.CalculatorService");

        /* Or you can use a named bean produced below by beanClient() method */
        from("direct:cxfBeanClient")
                .to("cxf:bean:beanClient?dataFormat=POJO");

    }

    @Produces
    @SessionScoped
    @Named
    CxfEndpoint beanClient() {
        final CxfEndpoint result = new CxfEndpoint();
        result.setServiceClass(CalculatorService.class);
        result.setAddress("http://localhost:8082/calculator-ws");
        result.setWsdlURL("wsdl/CalculatorService.wsdl"); // a resource in the class path
        return result;
    }
}

The CalculatorService may look like the following:

import jakarta.jws.WebMethod;
import jakarta.jws.WebService;

@WebService(targetNamespace = CalculatorService.TARGET_NS) 1
public interface CalculatorService {

    public static final String TARGET_NS = "http://acme.org/wscalculator/Calculator";

    @WebMethod 2
    public int add(int intA, int intB);

    @WebMethod 3
    public int subtract(int intA, int intB);

    @WebMethod 4
    public int divide(int intA, int intB);

    @WebMethod 5
    public int multiply(int intA, int intB);
}

$ docker run -p 8082:8080 quay.io/l2x6/calculator-ws:1.2

With camel-quarkus-cxf-soap, you can expose SOAP endpoints as consumers in Camel routes. No additional dependencies are required for this use case.

import org.apache.camel.builder.RouteBuilder;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.inject.Produces;
import jakarta.inject.Named;

@ApplicationScoped
public class CxfSoapRoutes extends RouteBuilder {

    @Override
    public void configure() {
        /* A CXF Service configured through a CDI bean */
        from("cxf:bean:helloBeanEndpoint")
                .setBody().simple("Hello ${body} from CXF service");

        /* A CXF Service configured through Camel URI parameters */
        from("cxf:///hello-inline?wsdlURL=wsdl/HelloService.wsdl&serviceClass=org.foo.HelloService")
                        .setBody().simple("Hello ${body} from CXF service");
    }

    @Produces
    @ApplicationScoped
    @Named
    CxfEndpoint helloBeanEndpoint() {
        final CxfEndpoint result = new CxfEndpoint();
        result.setServiceClass(HelloService.class);
        result.setAddress("/hello-bean");
        result.setWsdlURL("wsdl/HelloService.wsdl");
        return result;
    }
}

The path under which these two services will be served depends on the value of quarkus.cxf.pathconfiguration property which can for example be set in application.properties:

quarkus.cxf.path = /soap-services

With this configuration in place, our two services can be reached under http://localhost:8080/soap-services/hello-bean and http://localhost:8080/soap-services/hello-inline respectively.

The WSDL can be accessed by adding ?wsdl to the above URLs.

You can enable verbose logging of SOAP messages for both clients and servers with org.apache.cxf.ext.logging.LoggingFeature:

import org.apache.camel.builder.RouteBuilder;
import org.apache.cxf.ext.logging.LoggingFeature;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.context.SessionScoped;
import jakarta.enterprise.inject.Produces;
import jakarta.inject.Named;

@ApplicationScoped
public class MyBeans {

    @Produces
    @ApplicationScoped
    @Named("prettyLoggingFeature")
    public LoggingFeature prettyLoggingFeature() {
        final LoggingFeature result = new LoggingFeature();
        result.setPrettyLogging(true);
        return result;
    }

    @Inject
    @Named("prettyLoggingFeature")
    LoggingFeature prettyLoggingFeature;

    @Produces
    @SessionScoped
    @Named
    CxfEndpoint cxfBeanClient() {
        final CxfEndpoint result = new CxfEndpoint();
        result.setServiceClass(CalculatorService.class);
        result.setAddress("https://acme.org/calculator");
        result.setWsdlURL("wsdl/CalculatorService.wsdl");
        result.getFeatures().add(prettyLoggingFeature);
        return result;
    }

    @Produces
    @ApplicationScoped
    @Named
    CxfEndpoint helloBeanEndpoint() {
        final CxfEndpoint result = new CxfEndpoint();
        result.setServiceClass(HelloService.class);
        result.setAddress("/hello-bean");
        result.setWsdlURL("wsdl/HelloService.wsdl");
        result.getFeatures().add(prettyLoggingFeature);
        return result;
    }
}

The extent of supported WS specifications is given by the Quarkus CXF project.

camel-quarkus-cxf-soap covers only the following specifications via the io.quarkiverse.cxf:quarkus-cxf extension:

If your application requires some other WS specification, such as WS-Security or WS-Trust, you must add an additional Quarkus CXF dependency covering it. Refer to Quarkus CXF Reference page to see which WS specifications are covered by which Quarkus CXF extensions.

quarkus-cxf wraps the following two CXF tools:

quarkus.cxf.codegen.wsdl2java.additional-params = -validate

If your CXF clients are using java.net.http.HttpClient as the underlying HTTP client, then due to CXF issue, the application may crash if many clients are created, as their threads do not terminated.

The problem occurs with java.net.http.HttpClient when CXF clients is created repeatedly, for example per request. If you keep the clients throughout the whole lifespan of the application, this issue does not occur.

Since Apache Camel for Quarkus 3.2.0 and Quarkus CXF 2.2.3, the selection of the HTTP client implementation for some specific CXF client is controlled via quarkus.cxf.client.yourClient.http-conduit-factory property. By default, the CXF clients created by Quarkus CXF use java.net.HttpURLConnection as an HTTP client and thus, this issue does not occur by default. This issue may occur if you set quarkus.cxf.client.yourClient.http-conduit-factory=HttpClientHTTPConduitFactory.

When the same route is deployed on multiple JVMs, it could be interesting to use this extension in conjunction with the Master one. In such a setup, a single consumer will be active at a time across the whole camel master namespace.

For instance, having the route below deployed on multiple JVMs:

from("master:ns:timer:test?period=100").log("Timer invoked on a single JVM at a time");

It’s possible to enable the file cluster service with a property like below:

quarkus.camel.cluster.file.enabled = true
quarkus.camel.cluster.file-root = target/cluster-folder-where-lock-file-will-be-held

As a result, a single consumer will be active across the ns camel master namespace. It means that, at a given time, only a single timer will generate exchanges across all JVMs. In other words, messages will be logged every 100ms on a single JVM at a time.

The file cluster service could further be tuned by tweaking quarkus.camel.cluster.file.* properties.

Configuration property fixed at build time. All other configuration properties are overridable at runtime.

Camel Quarkus gRPC can generate gRPC service stubs for .proto files. When using Maven, ensure that you have enabled the generate-code goals of the quarkus-maven-plugin in your project build.

<build>
    <plugins>
        <plugin>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-maven-plugin</artifactId>
            <version>${quarkus.platform.version}</version>
            <extensions>true</extensions>
            <executions>
                <execution>
                    <goals>
                        <goal>build</goal>
                        <goal>generate-code</goal>
                        <goal>generate-code-tests</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

With this configuration, you can put your service and message definitions into the src/main/proto directory and the quarkus-maven-plugin will generate code from your .proto files.

quarkus.camel.grpc.codegen.scan-for-proto=org.my.groupId1:my-artifact-id-1,org.my.groupId2:my-artifact-id-2

quarkus.camel.grpc.codegen.scan-for-proto-includes."<groupId>\:<artifactId>"=foo/**,bar/**,baz/a-proto.proto
quarkus.camel.grpc.codegen.scan-for-proto-excludes."<groupId>\:<artifactId>"=foo/private/**,baz/another-proto.proto

The gRPC component has various options where resources are resolved from the classpath:

When using these options in native mode, you must ensure that any such resources are included in the native image.

This can be accomplished by adding the configuration property quarkus.native.resources.includes to application.properties. For example, to include SSL / TLS keys and certificates.

quarkus.native.resources.includes = certs/*.pem,certs.*.key

At present there is no support for integrating Camel Quarkus gRPC with Quarkus gRPC. If you have both the camel-quarkus-grpc and quarkus-grpc extension dependency on the classpath, you are likely to encounter problems at build time when compiling your application.

When marshaling/unmarshaling objects in native mode, all the serialized classes need to be registered for reflection. As such, when using GsonDataFormat.setUnmarshalType(…​), GsonDataFormat.setUnmarshalTypeName(…​) and even GsonDataFormat.setUnmarshalGenericType(…​), the unmarshal type as well as sub field types should be registered for reflection. See a working example in this integration test.

You can either configure the Infinispan client via the relevant Camel Infinispan component & endpoint options, or you may use the Quarkus Infinispan extension configuration properties.

Note that if you choose to use Quarkus Infinispan configuration properties, you must add an injection point for the RemoteCacheManager in order for it to be discoverable by the Camel Infinispan component. For example:

public class Routes extends RouteBuilder {
    // Injects the default unnamed RemoteCacheManager
    @Inject
    RemoteCacheManager cacheManager;

    // If configured, injects an optional named RemoteCacheManager
    @Inject
    @InfinispanClientName("myNamedClient")
    RemoteCacheManager namedCacheManager;

    @Override
    public void configure() {
        // Route configuration here...
    }
}

If you chose to use the InfinispanRemoteAggregationRepository in native mode, then you must enable native serialization support.

There are a few ways of configuring the ObjectMapper that the JacksonDataFormat uses. These are outlined below.

import com.fasterxml.jackson.databind.ObjectMapper;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.jackson.JacksonDataFormat;

public class Routes extends RouteBuilder {
    public void configure() {
        ObjectMapper mapper = new ObjectMapper();
        JacksonDataFormat dataFormat = new JacksonDataFormat();
        dataFormat.setObjectMapper(mapper);
        // Use the dataFormat instance in a route definition
        from("direct:my-direct").marshal(dataFormat)
    }
}

import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.jackson.JacksonDataFormat;

public class Routes extends RouteBuilder {
    public void configure() {
        JacksonDataFormat dataFormat = new JacksonDataFormat();
        // Make JacksonDataFormat discover the Quarkus Jackson `ObjectMapper` from the Camel registry
        dataFormat.setAutoDiscoverObjectMapper(true);
        // Use the dataFormat instance in a route definition
        from("direct:my-direct").marshal(dataFormat)
    }
}

import org.apache.camel.builder.RouteBuilder;

@ApplicationScoped
public class Routes extends RouteBuilder {
    public void configure() {
        restConfiguration().dataFormatProperty("autoDiscoverObjectMapper", "true");
        // REST definition follows...
    }
}

import com.fasterxml.jackson.databind.ObjectMapper;
import io.quarkus.jackson.ObjectMapperCustomizer;

@Singleton
public class RegisterCustomModuleCustomizer implements ObjectMapperCustomizer {
    public void customize(ObjectMapper mapper) {
        mapper.registerModule(new CustomModule());
    }
}

import com.fasterxml.jackson.databind.ObjectMapper;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.component.jackson.JacksonDataFormat;

@ApplicationScoped
public class Routes extends RouteBuilder {
    @Inject
    ObjectMapper mapper;

    public void configure() {
        JacksonDataFormat dataFormat = new JacksonDataFormat();
        dataFormat.setObjectMapper(mapper);
        // Use the dataFormat instance in a route definition
        from("direct:my-direct").marshal(dataFormat)
    }
}

You can use the @ConfigProperty annotation to inject encrypted configuration into your Camel routes or CDI beans.

@ApplicationScoped
public class MySecureRoute extends RouteBuilder {
    @ConfigInject("my.secret")
    String mySecret;

    @Override
    public void configure() {
        from("timer:tick?period=5s")
            .to(mySecret);
    }
}

package org.acme;

import org.apache.camel.quarkus.component.jasypt.JasyptConfigurationCustomizer;
import org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig;
import org.jasypt.iv.RandomIvGenerator;
import org.jasypt.salt.RandomSaltGenerator;

public class JasyptConfigurationCustomizer implements JasyptConfigurationCustomizer {
    public void customize(EnvironmentStringPBEConfig config) {
        // Custom algorithms
        config.setAlgorithm("PBEWithHmacSHA256AndAES_256");
        config.setSaltGenerator(new RandomSaltGenerator("PKCS11"));
        config.setIvGenerator(new RandomIvGenerator("PKCS11"));
        // Additional customizations...
    }
}

quarkus.camel.jasypt.configuration-customizer-class-name = org.acme.MyJasyptEncryptorCustomizer

import org.apache.camel.CamelContext;
import org.apache.camel.component.jasypt.JasyptPropertiesParser;
import org.apache.camel.component.properties.PropertiesComponent;

public class MySecureRoute extends RouteBuilder {
    @Override
    public void configure() {
        JasyptPropertiesParser jasypt = new JasyptPropertiesParser();
        jasypt.setPassword("secret");

        PropertiesComponent component = (PropertiesComponent) getContext().getPropertiesComponent();
        jasypt.setPropertiesComponent(component);
        component.setPropertiesParser(jasypt);

        from("timer:tick?period=5s")
            .to("{{my.secret}}");
    }
}

When performing JAXB marshal operations with a custom ObjectFactory to instantiate POJO classes that do not have JAXB annotations, you must register those POJO classes for reflection in order for them to be instantiated in native mode. E.g via the @RegisterForReflection annotation or configuration property quarkus.camel.native.reflection.include-patterns.

Refer to the Native mode user guide for more information.

This extension leverages Quarkus Agroal for DataSource support. Setting up a DataSource can be achieved via configuration properties. It is recommended that you explicitly name the datasource so that it can be referenced in the JDBC endpoint URI. E.g like to("jdbc:camel").

quarkus.datasource.camel.db-kind=postgresql
quarkus.datasource.camel.username=your-username
quarkus.datasource.camel.password=your-password
quarkus.datasource.camel.jdbc.url=jdbc:postgresql://localhost:5432/your-database
quarkus.datasource.camel.jdbc.max-size=16

If you choose to not name the datasource, you can resolve the default DataSource by defining your endpoint like to("jdbc:default").

The Camel JMS component supports message mapping between jakarta.jms.Message and org.apache.camel.Message. When wanting to convert a Camel message body type of org.w3c.dom.Node, you must ensure that the camel-quarkus-xml-jaxp extension is present on the classpath.

When sending JMS message payloads as jakarta.jms.ObjectMessage, you must annotate the relevant classes to be registered for serialization with @RegisterForReflection(serialization = true).

quarkus.pooled-jms.max-connections = 8

You can use the quarkus-pooled-jms extension to get pooling and XA support for JMS connections. Refer to the quarkus-pooled-jms extension documentation for more information. Currently, it can work with quarkus-artemis-jms, quarkus-qpid-jms and ibmmq-client. Just add the dependency to your pom.xml:

<dependency>
    <groupId>io.quarkiverse.messaginghub</groupId>
    <artifactId>quarkus-pooled-jms</artifactId>
</dependency>

Pooling is enabled by default.

To enable XA, you need to add quarkus-narayana-jta extension:

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-narayana-jta</artifactId>
</dependency>

and add the following configuration to your application.properties:

quarkus.pooled-jms.transaction=xa
quarkus.transaction-manager.enable-recovery=true

XA support is only available with quarkus-artemis-jms and ibmmq-client.

We strongly recommend that you enable transaction recovery.

Since there currently exists no quarkus extension for ibmmq-client, you need to create a custom ConnectionFactory and wrap it yourself.

Here is an example:

@Produces
public ConnectionFactory createXAConnectionFactory(PooledJmsWrapper wrapper) {
    MQXAConnectionFactory mq = new MQXAConnectionFactory();
    try {
        mq.setHostName(ConfigProvider.getConfig().getValue("ibm.mq.host", String.class));
        mq.setPort(ConfigProvider.getConfig().getValue("ibm.mq.port", Integer.class));
        mq.setChannel(ConfigProvider.getConfig().getValue("ibm.mq.channel", String.class));
        mq.setQueueManager(ConfigProvider.getConfig().getValue("ibm.mq.queueManagerName", String.class));
        mq.setTransportType(WMQConstants.WMQ_CM_CLIENT);
        mq.setStringProperty(WMQConstants.USERID,
            ConfigProvider.getConfig().getValue("ibm.mq.user", String.class));
        mq.setStringProperty(WMQConstants.PASSWORD,
            ConfigProvider.getConfig().getValue("ibm.mq.password", String.class));
    } catch (Exception e) {
        throw new RuntimeException("Unable to create new IBM MQ connection factory", e);
    }
    return wrapper.wrapConnectionFactory(mq);
}

@Inject
TransactionManager transactionManager;

@Override
public void configure() throws Exception {
    from("jms:queue:DEV.QUEUE.XA?transactionManager=#jtaTransactionManager");
}

@Named("jtaTransactionManager")
public PlatformTransactionManager getTransactionManager() {
    return new JtaTransactionManager(transactionManager);
}

WARN  [com.arj.ats.jta] (executor-thread-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=35, bqual_length=36, tx_uid=0:ffffc0a86510:aed3:650915d7:16, node_name=quarkus, branch_uid=0:ffffc0a86510:aed3:650915d7:1f, subordinatenodename=null, eis_name=0 > (com.ibm.mq.jmqi.JmqiXAResource@79786dde) failed with exception code XAException.XAER_NOTA: javax.transaction.xa.XAException: The method 'xa_rollback' has failed with errorCode '-4'.

It needs to use EntityManagerFactory and TransactionStrategy from the CDI container to configure the JpaMessageIdRepository:

@Inject
EntityManagerFactory entityManagerFactory;

@Inject
TransactionStrategy transactionStrategy;

from("direct:idempotent")
    .idempotentConsumer(
        header("messageId"),
        new JpaMessageIdRepository(entityManagerFactory, transactionStrategy, "idempotentProcessor"));

This component typically loads the templates from classpath. To make it work also in native mode, you need to explicitly embed the templates files in the native executable by using the quarkus.native.resources.includes property.

For instance, the route below would load the JSLT schema from a classpath resource named transformation.json:

from("direct:start").to("jslt:transformation.json");

To include this (an possibly other templates stored in .json files) in the native image, you would have to add something like the following to your application.properties file:

quarkus.native.resources.includes = *.json

When using JSLT functions from camel-quarkus in native mode, the classes hosting the functions would need to be registered for reflection. When registering the target function is not possible, one may end up writing a stub as below.

@RegisterForReflection
public class MathFunctionStub {
    public static double pow(double a, double b) {
        return java.lang.Math.pow(a, b);
    }
}

The target function Math.pow(…​) is now accessible through the MathFunctionStub class that could be registered in the component as below:

@Named
JsltComponent jsltWithFunction() throws ClassNotFoundException {
    JsltComponent component = new JsltComponent();
    component.setFunctions(singleton(wrapStaticMethod("power", "org.apache.cq.example.MathFunctionStub", "pow")));
    return component;
}

Camel Quarkus Kafka can take advantage of Quarkus Kafka Dev services to simplify development and testing with a local containerized Kafka broker.

Kafka Dev Services is enabled by default in dev & test mode. The Camel Kafka component is automatically configured so that the brokers component option is set to point at the local containerized Kafka broker. Meaning that there’s no need to configure this option yourself.

This functionality can be disabled with the configuration property quarkus.kafka.devservices.enabled=false.

This extension allows to pre-load a set of Kamelets at build time using the quarkus.camel.kamelet.identifiers property.

A set of pre-made Kamelets can be found on the /camel-kamelets/latest[Kamelet Catalog]. To use the Kamelet from the catalog you need to copy their yaml definition (that you can find in the camel-kamelet repo) on your project in the classpath. Alternatively you can add the camel-kamelets-catalog artifact to your pom.xml:

<dependency>
    <groupId>org.apache.camel.kamelets</groupId>
    <artifactId>camel-kamelets-catalog</artifactId>
</dependency>

This artifact add all the kamelets available in the catalog to your Camel Quarkus application for build time processing. If you include it with the scope provided the artifact should not be part of the runtime classpath, but at build time, all the kamelets listed via quarkus.camel.kamelet.identifiers property should be preloaded.

The extension automatically registers a Kubernetes Client bean named kubernetesClient. You can reference the bean in your routes like this:

from("direct:pods")
    .to("kubernetes-pods:///?kubernetesClient=#kubernetesClient&operation=listPods")

By default the client is configured from the local kubeconfig file. You can customize the client configuration via properties within application.properties:

quarkus.kubernetes-client.master-url=https://my.k8s.host
quarkus.kubernetes-client.namespace=my-namespace

The full set of configuration options are documented in the Quarkus Kubernetes Client guide.

When the same route is deployed on multiple pods, it could be interesting to use this extension in conjunction with the Master one. In such a setup, a single consumer will be active at a time across the whole camel master namespace.

For instance, having the route below deployed on multiple pods:

from("master:ns:timer:test?period=100").log("Timer invoked on a single pod at a time");

It’s possible to enable the kubernetes cluster service with a property like below:

quarkus.camel.cluster.kubernetes.enabled = true

As a result, a single consumer will be active across the ns camel master namespace. It means that, at a given time, only a single timer will generate exchanges across the whole cluster. In other words, messages will be logged every 100ms on a single pod at a time.

The kubernetes cluster service could further be tuned by tweaking quarkus.camel.cluster.kubernetes.* properties.

Configuration property fixed at build time. All other configuration properties are overridable at runtime.

The Language extension only handles the passing of an Exchange to a script for execution. The extension implementing the language must be added as a dependency. The following list of languages are implemented in Core:

To use any other language, you must add the corresponding dependency. Consult the Languages Guide for details.

When loading scripts from the classpath in native mode, the path to the script file must be specified in the quarkus.native.resources.includes property of the application.properties file. For example:

quarkus.native.resources.includes=script.txt

When using a custom SSLSocketFactory in native mode, such as the one in the Configuring SSL section, you need to register the class for reflection otherwise the class will not be made available on the classpath. Add the @RegisterForReflection annotation above the class definition, as follows:

@RegisterForReflection
public class CustomSSLSocketFactory extends SSLSocketFactory {
    // The class definition is the same as in the above link.
}

JMX can be enabled or disabled in Camel-Quarkus by any of the following methods:

Experimental JMX support was added for native executables in GraalVM for JDK 17/20 / Mandrel 23.0. You can enable this feature by adding the following configuration property to application.properties.

quarkus.native.monitoring=jmxserver

If you want the native application to be discoverable by tools such as JConsole and VisualVM, append the jvmstat option to the above mentioned configuration.

For more information, refer to the Quarkus native guide.

To use MapStruct, you must configure your build to use an annotation processor.

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
            <annotationProcessorPaths>
                <path>
                    <groupId>org.mapstruct</groupId>
                    <artifactId>mapstruct-processor</artifactId>
                    <version>{mapstruct-version}</version>
                </path>
            </annotationProcessorPaths>
        </configuration>
    </plugin>
</plugins>

dependencies {
    annotationProcessor 'org.mapstruct:mapstruct-processor:{mapstruct-version}'
    testAnnotationProcessor 'org.mapstruct:mapstruct-processor:{mapstruct-version}'
}

By default, Red Hat build of Apache Camel for Quarkus will automatically discover the package paths of your @Mapper annotated interfaces or abstract classes and pass them to the Camel MapStruct component.

If you want finer control over the specific packages that are scanned, then you can set a configuration property in application.properties.

camel.component.mapstruct.mapper-package-name = com.first.package,org.second.package

Exposing Micrometer statistics in JMX is not available in native mode as quarkus-micrometer-registry-jmx does not have native support at present.

Prometheus backend ignores negative values during increment of Counter metrics.

In Red Hat build of Apache Camel for Quarkus, registering a JmxMeterRegistry is simplified. Add a dependency for io.quarkiverse.micrometer.registry:quarkus-micrometer-registry-jmx and a JmxMeterRegistry will automatically get created for you.

Some checks are automatically registered for your application.

Quarkus OpenTelemetry defaults to the standard OTLP exporter defined in OpenTelemetry. Additional exporters will be available in the Quarkiverse quarkus-opentelemetry-exporter project.

When instrumenting the execution of CDI bean methods from Camel routes, you should annotate such methods with io.opentelemetry.extension.annotations.WithSpan. Methods annotated with @WithSpan will create a new Span and establish any required relationships with the current Trace context.

For example, to instrument a CDI bean from a Camel route, first ensure the appropriate methods are annotated with @WithTrace.

@ApplicationScoped
@Named("myBean")
public class MyBean {
    @WithSpan
    public String greet() {
        return "Hello World!";
    }
}

Next, use the bean in your Camel route.

public class MyRoutes extends RouteBuilder {
    @Override
    public void configure() throws Exception {
        from("direct:executeBean")
                .to("bean:myBean?method=greet");
    }
}

There is more information about CDI instrumentation in the Quarkus OpenTelemetry guide.

Serve all HTTP methods on the /hello endpoint:

from("platform-http:/hello").setBody(simple("Hello ${header.name}"));

Serve only GET requests on the /hello endpoint:

from("platform-http:/hello?httpMethodRestrict=GET").setBody(simple("Hello ${header.name}"));

To be able to use Camel REST DSL with the platform-http component, add camel-quarkus-rest to your pom.xml:

<dependency>
    <groupId>org.apache.camel.quarkus</groupId>
    <artifactId>camel-quarkus-rest</artifactId>
</dependency>

Then you can use the Camel REST DSL:

rest()
    .get("/my-get-endpoint")
        .to("direct:handleGetRequest");

    .post("/my-post-endpoint")
        .to("direct:handlePostRequest");

You can restrict the uploads to certain file extensions by white listing them:

from("platform-http:/upload/multipart?fileNameExtWhitelist=html,txt&httpMethodRestrict=POST")
    .to("log:multipart")
    .process(e -> {
        final AttachmentMessage am = e.getMessage(AttachmentMessage.class);
        if (am.hasAttachments()) {
            am.getAttachments().forEach((fileName, dataHandler) -> {
                try (InputStream in = dataHandler.getInputStream()) {
                    // do something with the input stream
                } catch (IOException ioe) {
                    throw new RuntimeException(ioe);
                }
            });
        }
    });

Quarkus provides a variety of security and authentication mechanisms which can be used to secure platform-http endpoints. Refer to the Quarkus Security documentation for further details.

Within a route, it is possible to obtain the authenticated user and its associated SecurityIdentity and Principal:

from("platform-http:/secure")
    .process(e -> {
        Message message = e.getMessage();
        QuarkusHttpUser user = message.getHeader(VertxPlatformHttpConstants.AUTHENTICATED_USER, QuarkusHttpUser.class);
        SecurityIdentity securityIdentity = user.getSecurityIdentity();
        Principal principal = securityIdentity.getPrincipal();
        // Do something useful with SecurityIdentity / Principal. E.g check user roles etc.
    });

Also check the quarkus.http.body.* configuration options in Quarkus documentation, esp. quarkus.http.body.handle-file-uploads, quarkus.http.body.uploads-directory and quarkus.http.body.delete-uploaded-files-on-end.

Platform HTTP component can act as a reverse proxy, in that case Exchange.HTTP_URI, Exchange.HTTP_HOST headers are populated from the absolute URL received on the request line of the HTTP request.

Here’s an example of a HTTP proxy that simply redirects the Exchange to the origin server.

from("platform-http:proxy")
    .toD("http://"
        + "${headers." + Exchange.HTTP_HOST + "}");

Configuration of the platform HTTP server is managed by Quarkus. Refer to the Quarkus HTTP configuration guide for the full list of configuration options.

To configure SSL for the Platform HTTP server, follow the secure connections with SSL guide. Note that configuring the server for SSL with SSLContextParameters is not currently supported.

Check the Character encodings section of the Native mode guide if you expect your application to send or receive requests using non-default encodings.

Support for Quartz clustering is provided by the Quarkus Quartz extension. The following steps outline how to configure Quarkus Quartz for use with Camel.

Further customization of the Quartz scheduler can be done via various configuration properties. Refer to to the Quarkus Quartz Configuration guide for more information.

A RestProducerFactory implementation must be available when using the rest-openapi extension. The currently known extensions are:

Maven users will need to add one of these dependencies to their pom.xml, for example:

<dependency>
    <groupId>org.apache.camel.quarkus</groupId>
    <artifactId>camel-quarkus-http</artifactId>
</dependency>

Depending on which mechanism is used to load the OpenApi specification, additional dependencies may be required. When using the file resource locator, the org.apache.camel.quarkus:camel-quarkus-file extension must be added as a project dependency. When using ref or bean to load the specification, not only must the org.apache.camel.quarkus:camel-quarkus-bean dependency be added, but the bean itself must be annotated with @RegisterForReflection.

When using the classpath resource locator with native code, the path to the OpenAPI specification must be specified in the quarkus.native.resources.includes property of the application.properties file. For example:

quarkus.native.resources.includes=openapi.json

When using the platform-http REST transport, some characters are not allowed within path parameter names. This includes the '-' and '$' characters.

In order to make the below example REST /dashed/param route work correctly, a system property is required io.vertx.web.route.param.extended-pattern=true.

import org.apache.camel.builder.RouteBuilder;

public class CamelRoute extends RouteBuilder {

    @Override
    public void configure() {
        rest("/api")
            // Dash '-' is not allowed by default
            .get("/dashed/param/{my-param}")
            .to("direct:greet")

            // The non-dashed path parameter works by default
            .get("/undashed/param/{myParam}")
            .to("direct:greet");

            from("direct:greet")
                .setBody(constant("Hello World"));
    }
}

There is some more background to this in the Vert.x Web documentation.

To use another REST transport provider, such as netty-http or servlet, you need to add the respective extension as a dependency to your project and set the provider in your RouteBuilder. E.g. for servlet, you’d have to add the org.apache.camel.quarkus:camel-quarkus-servlet dependency and the set the provider as follows:

import org.apache.camel.builder.RouteBuilder;

public class CamelRoute extends RouteBuilder {

    @Override
    public void configure() {
        restConfiguration()
                .component("servlet");
        ...
    }
}

Test content.

To generate Salesforce DTOs for your project, use the salesforce-maven-plugin. The example code snippet below creates a single DTO for the Account object.

<plugin>
    <groupId>org.apache.camel.maven</groupId>
    <artifactId>camel-salesforce-maven-plugin</artifactId>
    <version>{camel-version}</version>
    <executions>
        <execution>
            <goals>
                <goal>generate</goal>
            </goals>
            <configuration>
                <clientId>${env.SALESFORCE_CLIENTID}</clientId>
                <clientSecret>${env.SALESFORCE_CLIENTSECRET}</clientSecret>
                <userName>${env.SALESFORCE_USERNAME}</userName>
                <password>${env.SALESFORCE_PASSWORD}</password>
                <loginUrl>https://login.salesforce.com</loginUrl>
                <packageName>org.apache.camel.quarkus.component.salesforce.generated</packageName>
                <outputDirectory>src/main/java</outputDirectory>
                <includes>
                    <include>Account</include>
                </includes>
            </configuration>
        </execution>
    </executions>
</plugin>

When using the Camel Salesforce Pub / Sub API and pubSubDeserializeType is configured as POJO, you must register any classes configured on the pubSubPojoClass option for reflection.

For example, given the following route.

from("salesforce:pubSubSubscribe:/event/TestEvent__e?pubSubDeserializeType=POJO&pubSubPojoClass=org.foo.TestEvent")
    .log("Received Salesforce POJO topic message: ${body}");

Class org.foo.TestEvent would need to be registered for reflection.

package org.foo;

import io.quarkus.runtime.annotations.RegisterForReflection;

@RegisterForReflection
public class TestEvent {
    // Getters / setters etc
}

Refer to the Native mode user guide for more information.

The SAP extension does not support the packaging type uber-jar, which causes the application to throw a runtime exception similar to this:

Caused by: java.lang.ExceptionInInitializerError: JCo initialization failed with java.lang.ExceptionInInitializerError: Illegal JCo archive "sap-1.0.0-SNAPSHOT-runner.jar". It is not allowed to rename or repackage the original archive "sapjco3.jar".

Because the SAP component depends on the third-party JCo 3 and IDoc 3 libraries, it can only be installed on the platforms that these libraries support.

A prerequisite for using the SAP component is that the SAP Java Connector (SAP JCo) libraries and the SAP IDoc library are installed into the lib/ directory of the Java runtime. You must make sure that you download the appropriate set of SAP libraries for your target operating system from the SAP Service Marketplace.

The names of the library files vary depending on the target operating system, as shown below.

<dependency>
        <groupId>com.sap.conn.jco</groupId>
        <artifactId>sapjco3</artifactId>
        <version>3.1.4</version>
        <scope>system</scope>
        <systemPath>${basedir}/lib/sapjco3.jar</systemPath>
    </dependency>
    <dependency>
        <groupId>com.sap.conn.idoc</groupId>
        <artifactId>sapidoc3</artifactId>
        <version>3.1.1</version>
        <scope>system</scope>
        <systemPath>${basedir}/lib/sapidoc3.jar</systemPath>
    </dependency>

The RFC destination endpoints (sap-srfc-destination, sap-trfc-destination, and sap-qrfc-destination) support the following URI options:

The SAP RFC server endpoints (sap-srfc-server and sap-trfc-server) support the following URI options:

The SAP IDoc List Server endpoint (sap-idoclist-server) supports the following URI options:

The SAP component package provides the following RFC and IDoc endpoints:

An RFC destination endpoint supports outbound communication to SAP, which enable these endpoints to make RFC calls out to ABAP function modules in SAP. An RFC destination endpoint is configured to make an RFC call to a specific ABAP function over a specific connection to an SAP instance. An RFC destination is a logical designation for an outbound connection and has a unique name. An RFC destination is specified by a set of connection parameters called destination data.

An RFC destination endpoint will extract an RFC request from the input message of the IN-OUT exchanges it receives and dispatch that request in a function call to SAP. The response from the function call will be returned in the output message of the exchange. Since SAP RFC destination endpoints only support outbound communication, an RFC destination endpoint only supports the creation of producers.

An RFC server endpoint supports inbound communication from SAP, which enables ABAP applications in SAP to make RFC calls into server endpoints. An ABAP application interacts with an RFC server endpoint as if it were a remote function module. An RFC server endpoint is configured to receive an RFC call to a specific RFC function over a specific connection from an SAP instance. An RFC server is a logical designation for an inbound connection and has a unique name. An RFC server is specified by a set of connection parameters called server data.

An RFC server endpoint will handle an incoming RFC request and dispatch it as the input message of an IN-OUT exchange. The output message of the exchange will be returned as the response of the RFC call. Since SAP RFC server endpoints only support inbound communication, an RFC server endpoint only supports the creation of consumers.

An IDoc destination endpoint supports outbound communication to SAP, which can then perform further processing on the IDoc message. An IDoc document represents a business transaction, which can easily be exchanged with non-SAP systems. An IDoc destination is specified by a set of connection parameters called destination data.

An IDoc list destination endpoint is similar to an IDoc destination endpoint, except that the messages it handles consist of a list of IDoc documents.

An IDoc list server endpoint supports inbound communication from SAP, enabling a Camel route to receive a list of IDoc documents from an SAP system. An IDoc list server is specified by a set of connection parameters called server data.

A metadata repository is used to store the following kinds of metadata:

SAP destination and server endpoints thus require access to a repository, in order to send and receive RFC calls and in order to send and receive IDoc documents. For RFC calls, the metadata for all function modules invoked and handled by the endpoints must reside within the repository; and for IDoc endpoints, the metadata for all IDoc types and IDoc type extensions handled by the endpoints must reside within the repository. The location of the repository used by a destination and server endpoint is specified in the destination data and the server data of their respective connections.

In the case of an SAP destination endpoint, the repository it uses typically resides in an SAP system, and it defaults to the SAP system it is connected to. This default requires no explicit configuration in the destination data. Furthermore, the metadata for the remote function call that a destination endpoint makes will already exist in a repository for any existing function module that it calls. The metadata for calls made by destination endpoints thus require no configuration in the SAP component.

On the other hand, the metadata for function calls handled by server endpoints do not typically reside in the repository of an SAP system and must instead be provided by a repository residing in the SAP component. The SAP component maintains a map of named metadata repositories. The name of a repository corresponds to the name of the server to which it provides metadata.

The SAP component maintains three maps to store destination data, server data, and repository data. The component’s property, destinationDataStore, stores destination data keyed by destination name, the property, serverDataStore, stores server data keyed by server name and the property, repositoryDataStore, stores repository data keyed by repository name. These configurations must be passed to the component during its initialization.

public class SAPRouteBuilder extends RouteBuilder {
	@BindToRegistry("sap-configuration")
	public SapConnectionConfiguration sapConfiguration() {
		SapConnectionConfiguration configuration = new SapConnectionConfiguration();
		configuration.setDestinationDataStore(destinationData());
		configuration.setServerDataStore(serverData());
		return configuration;
	}

	/**
	 * Configures an Inbound SAP Connection
	 * Please enter the connection property values for your environment
	 */
	private Map<String, ServerData> serverData() {
		ServerData data = new ServerDataImpl();
		data.setGwhost("example.com");
		data.setGwserv("3300");
		data.setProgid("QUICKSTART");
		data.setRepositoryDestination("quickstartDest");
		data.setConnectionCount("2");
		return Map.of("quickstartServer", data);
	}

	/**
	 * Configures an Outbound SAP Connection
	 * Please enter the connection property values for your environment
	 */
	private Map<String, DestinationData> destinationData() {
		DestinationData data = new DestinationDataImpl();
		data.setAshost("example.com");
		data.setSysnr("00");
		data.setClient("000");
		data.setUser("username");
		data.setPasswd("password");
		data.setLang("en");
		return Map.of("quickstartDest", data);
	}

	@Override
	public void configure() throws Exception {
		// Routes definitions
	}
}

The configurations for destinations are maintained in the destinationDataStore property of the SAP component. Each entry in this map configures a distinct outbound connection to an SAP instance. The key for each entry is the name of the outbound connection and is used in the destinationName component of a destination endpoint URI as described in the URI format section.

The value for each entry is a destination data configuration object - org.fusesource.camel.component.sap.model.rfc.impl.DestinationDataImpl - that specifies the configuration of an outbound SAP connection.

    @BindToRegistry("sap-configuration")
    public SapConnectionConfiguration sapConfiguration() {
        SapConnectionConfiguration configuration = new SapConnectionConfiguration();
        configuration.setDestinationDataStore(destinationData());
        return configuration;
    }

    private Map<String, DestinationData> destinationData() {
        DestinationData data = new DestinationDataImpl();
        data.setAshost("example.com");
        data.setSysnr("00");
        data.setClient("000");
        data.setUser("username");
        data.setPasswd("password");
        data.setLang("en");
        return Map.of("quickstartDest", data);
    }

    @Override
    public void configure() throws Exception {
        ((DefaultCamelContext) getCamelContext()).addInterceptStrategy(new CurrentProcessorDefinitionInterceptStrategy());
        // Routes definitions
    }

After configuring the destination as shown above, you can invoke the BAPI_FLCUST_GETLIST remote function call on the quickstartDest destination with the following URI:

sap-srfc-destination:quickstartDest:BAPI_FLCUST_GETLIST

The configurations for servers are maintained in the serverDataStore property of the SAP component. Each entry in this map configures a distinct inbound connection from an SAP instance. The key for each entry is the name of the outbound connection and is used in the serverName component of a server endpoint URI as described in the URI format section.

The value for each entry is a server data configuration object, org.fusesource.camel.component.sap.model.rfc.impl.ServerDataImpl, which defines the configuration of an inbound SAP connection.

@BindToRegistry("sap-configuration")
	public SapConnectionConfiguration sapConfiguration() {
		SapConnectionConfiguration configuration = new SapConnectionConfiguration();
		configuration.setDestinationDataStore(destinationData());
		configuration.setServerDataStore(serverData());
		return configuration;
	}

	/**
	 * Configures an Inbound SAP Connection
	 * Please enter the connection property values for your environment
	 */
	private Map<String, ServerData> serverData() {
		ServerData data = new ServerDataImpl();
		data.setGwhost("example.com");
		data.setGwserv("3300");
		data.setProgid("QUICKSTART");
		data.setRepositoryDestination("quickstartDest");
		data.setConnectionCount("2");
		return Map.of("quickstartServer", data);
	}

	/**
	 * Configures an Outbound SAP Connection
	 * Please enter the connection property values for your environment
	 */
	private Map<String, DestinationData> destinationData() {
		DestinationData data = new DestinationDataImpl();
		data.setAshost("example.com");
		data.setSysnr("00");
		data.setClient("000");
		data.setUser("username");
		data.setPasswd("password");
		data.setLang("en");
		return Map.of("quickstartDest", data);
	}

After configuring the destination as shown above, you can handle the BAPI_FLCUST_GETLIST remote function call on the quickstartDest remote function call from an invoking client, using the following URI:

sap-srfc-server:quickstartServer:BAPI_FLCUST_GETLIST

The configurations for repositories are maintained in the repositoryDataStore property of the SAP Component. Each entry in this map configures a distinct repository. The key for each entry is the name of the repository and this key also corresponds to the name of the server to which this repository is attached.

The value of each entry is a repository data configuration object, org.fusesource.camel.component.sap.model.rfc.impl.RepositoryDataImpl, that defines the contents of a metadata repository. A repository data object is a map of function template configuration objects, org.fuesource.camel.component.sap.model.rfc.impl.FunctionTemplateImpl. Each entry in this map specifies the interface of a function module and the key for each entry is the name of the function module specified.

    @BindToRegistry("sap-configuration")
    public SapConnectionConfiguration sapConfiguration() {
        SapConnectionConfiguration configuration = new SapConnectionConfiguration();
        configuration.setRepositoryDataStore(repositoryData());
        return configuration;
    }

    private Map<String, RepositoryData> repositoryData() {
        RepositoryData data = new RepositoryDataImpl();
        FunctionTemplate bookFlightFunctionTemplate = new FunctionTemplateImpl();
        data.setFunctionTemplates(Map.of("BOOK_FLIGHT", bookFlightFunctionTemplate));
        return Map.of("nplServer", data);
    }

    FunctionTemplate bookFlightFunctionTemplate = new FunctionTemplateImpl();

    List<ListFieldMetaData> metaDataList = new ArrayList<>();
    ListFieldMetaData metaData = new ListFieldMetaDataImpl();

    // configure values
    metaData.setName("example");
    metaDataList.add(metaData);
    bookFlightFunctionTemplate.setImportParameterList(metaDataList);

    // in the same way you can configure other parameters
    bookFlightFunctionTemplate.setExportParameterList(...);
    bookFlightFunctionTemplate.setChangingParameterList(...);
    bookFlightFunctionTemplate.setExceptionList(...);
    bookFlightFunctionTemplate.setTableParameterList(...);

    ListFieldMetaData metaData = new ListFieldMetaDataImpl();
    metaData.setName("TICKET_PRICE");
    metaData.setType(DataType.BCD);
    metaData.setByteLength(12);
    metaData.setUnicodeByteLength(24);
    metaData.setDecimals(2);
    metaData.setOptional(true);

    ListFieldMetaData metaData = new ListFieldMetaDataImpl();
    metaData.setName("CONNINFO");
    metaData.setType(DataType.TABLE);
    RecordMetaData connectionInfo = new RecordMetaDataImpl();
    metaData.setRecordMetaData(connectionInfo);

    RecordMetaData connectionInfo = new RecordMetaDataImpl();
    connectionInfo.setName("CONNECTION_INFO");
    connectionInfo.setRecordFieldMetaData(...);

    FieldMetaData fieldMetaData = new FieldMetaDataImpl();
    fieldMetaData.setName("FLTINFO");
    fieldMetaData.setType(DataType.STRUCTURE);
    fieldMetaData.setByteOffset(0);
    fieldMetaData.setUnicodeByteOffset(0);
    RecordMetaData flightInfo = new RecordMetaDataImpl();
    fieldMetaData.setRecordMetaData(flightInfo);

    FieldMetaData fieldMetaData = new FieldMetaDataImpl();
    fieldMetaData.setName("FLTINFO");
    fieldMetaData.setType(DataType.STRUCTURE);
    fieldMetaData.setByteOffset(0);
    fieldMetaData.setUnicodeByteOffset(0);
    RecordMetaData flightInfo = new RecordMetaDataImpl();
    fieldMetaData.setRecordMetaData(flightInfo);

An SAP endpoint expects to receive a message with a message body containing an SAP request object and will return a message with a message body containing an SAP response object. SAP requests and responses are fixed map data structures containing named fields with each field having a predefined data type.

Note that the named fields in an SAP request and response are specific to an SAP endpoint, with each endpoint defining the parameters in the SAP request and response it will accept. An SAP endpoint provides factory methods to create the request and response objects that are specific to it.

public class SAPEndpoint ... {
    ...
    public Structure getRequest() throws Exception;

    public Structure getResponse() throws Exception;
    ...
}

Both SAP request and response objects are represented in Java as a structure object which supports the org.fusesource.camel.component.sap.model.rfc.Structure interface. This interface extends both the java.util.Map and org.eclipse.emf.ecore.EObject interfaces.

public interface Structure extends org.eclipse.emf.ecore.EObject,
                                        java.util.Map<String, Object> {

    <T> T get(Object key, Class<T> type);

}

The field values in a structure object are accessed through the field’s getter methods in the map interface. In addition, the structure interface provides a type-restricted method to retrieve field values.

Structure objects are implemented in the component runtime using the Eclipse Modeling Framework (EMF) and support that framework’s EObject interface. Instances of a structure object have attached metadata which define and restrict the structure and contents of the map of fields it provides. This metadata can be accessed and introspected using the standard methods provided by EMF. Refer to the EMF documentation for further details.

As discussed in the following sections, structure objects can contain fields that contain values of the complex field types, STRUCTURE, and TABLE.

The fields that reside within the structure object of an SAP request or response may be either elementary or complex. An elementary field contains a single scalar value, whereas a complex field will contain one or more fields of either an elementary or complex type.