Example - 6.3

Talend ESB Mediation Developer Guide

EnrichVersion
6.3
EnrichProdName
Talend Data Fabric
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Open Studio for ESB
Talend Real-Time Big Data Platform
task
Design and Development
EnrichPlatform
Talend ESB

In this example we'll create a black box context, then we'll use it from another CamelContext.

Defining the context component

First you need to create a CamelContext, add some routes in it, start it and then register the CamelContext into the Registry (JNDI, Spring, Guice or OSGi etc).

This can be done in the usual Camel way from this test case (see the createRegistry() method); this example shows Java and JNDI being used:

// let's create our black box as a Camel context and a set of routes
DefaultCamelContext blackBox = new DefaultCamelContext(registry);
blackBox.setName("blackBox");
blackBox.addRoutes(new RouteBuilder() {
   @Override
   public void configure() throws Exception {
      // receive purchase orders, let's process it in some way then send
      // an invoice to our invoice endpoint
      from("direct:purchaseOrder")
         .setHeader("received")
         .constant("true")
         .to("direct:invoice");
   }
});
blackBox.start();

registry.bind("accounts", blackBox);

Notice in the above route we are using pure local endpoints ( direct and seda ). Also note we expose this CamelContext using the accounts ID. We can do the same thing in Spring via:

<camelContext id="accounts" xmlns="http://camel.apache.org/schema/spring">
   <route> 
      <from uri="direct:purchaseOrder"/>
      ...
      <to uri="direct:invoice"/>
   </route>
</camelContext>

Using the context component

Then in another CamelContext we can then refer to this "accounts black box" by just sending to accounts:purchaseOrder and consuming from accounts:invoice .

If you prefer to be more verbose and explicit you could use context:accounts:purchaseOrder or even context:accounts:direct://purchaseOrder if you prefer. But using logical endpoint URIs is preferred as it hides the implementation detail and provides a simple logical naming scheme.

For example, if we wish to subsequently expose this accounts black box on some middleware (outside of the black box) we can do things like:

<camelContext xmlns="http://camel.apache.org/schema/spring">
   <route> 
      <!-- consume from an ActiveMQ into the black box -->
      <from uri="activemq:Accounts.PurchaseOrders"/>
      <to uri="accounts:purchaseOrders"/>
   </route>
   <route>   
      <!-- let's send invoices from the black box -->
      <!-- to a different ActiveMQ Queue -->
      <from uri="accounts:invoice"/>
      <to uri="activemq:UK.Accounts.Invoices"/>
   </route>
</camelContext>

Naming endpoints

A context component instance can have many public input and output endpoints that can be accessed from outside its CamelContext. When there are many it is recommended that you use logical names for them to hide the middleware as shown above.

However when there is only one input, output or error/dead letter endpoint in a component we recommend using the common posix shell names in, out and err