Event Message

Camel supports the Event Message from the EIP patterns .

How can messaging be used to transmit events from one application to another?

image

Use an Event Message for reliable, asynchronous event notification between applications.

Camel supports Event Message by the Exchange Pattern on a Message which can be set to InOnly to indicate a oneway event message. Camel Components then implement this pattern using the underlying transport or protocols.

The default behaviour of many Components is InOnly such as for JMS , File or SEDA .

Some components support both InOnly and InOut and act accordingly. For example, the JMS can send messages as one-way ( InOnly ) or use request/reply messaging ( InOut ).

See the related Request Reply message.

Using endpoint URI

If you are using a component which defaults to InOut you can override the Exchange Pattern for a consumer endpoint using the pattern property. 

foo:bar?exchangePattern=InOnly
This is only possible on endpoints used by consumers (i.e., in <from> ).

In the example below the message will be forced as an event message as the consumer is in InOnly mode.

  • Java

  • XML

  • YAML 

from("mq:someQueue?exchangePattern=InOnly")
  .to("activemq:queue:one-way");
<route>
    <from uri="mq:someQueue?exchangePattern=InOnly"/>
    <to uri="activemq:queue:one-way"/>
</route>
- route:
    from:
      uri: mq:someQueue
      parameters:
        exchangePattern: InOnly
      steps:
        - to:
            uri: activemq:queue:one-way

How It Works

The InOnly exchange pattern is a contract between the route and the component endpoint. It tells the producer component that the caller does not expect a reply (fire-and-forget).

The exchange pattern does not affect how EIPs and processors work within the route. Processors such as setBody , transform , process , and bean always operate on the current message regardless of the exchange pattern. The pattern only matters when the exchange reaches a producer endpoint that acts on it.

Whether a component acts on the pattern depends on the component. Components that support both modes, such as JMS , SEDA , and AMQP , use InOnly to dispatch the message without waiting for a reply (fire-and-forget). Synchronous components such as Direct always process in the same thread and call stack, so the pattern has no practical effect on the dispatch behavior — the caller still waits for the called route to complete.

Using setExchangePattern EIP

You can specify the Exchange Pattern using setExchangePattern in the DSL.

  • Java

  • XML

  • YAML 

from("mq:someQueue")
  .setExchangePattern(ExchangePattern.InOnly)
  .to("activemq:queue:one-way");
<route>
    <from uri="mq:someQueue"/>
    <setExchangePattern pattern="InOnly"/>
    <to uri="activemq:queue:one-way"/>
</route>
- route:
    from:
      uri: mq:someQueue
      steps:
        - setExchangePattern:
            pattern: InOnly
        - to:
            uri: activemq:queue:one-way

When using setExchangePattern then the Exchange Pattern on the Exchange is changed from this point onwards in the route.

This means you can change the pattern back again at a later point:

  • Java

  • XML

  • YAML 

from("mq:someQueue")
  .setExchangePattern(ExchangePattern.InOnly)
  .to("activemq:queue:one-way")
  .setExchangePattern(ExchangePattern.InOut)
  .to("activemq:queue:in-and-out")
  .log("InOut MEP received ${body}");
<route>
    <from uri="mq:someQueue"/>
    <setExchangePattern pattern="InOnly"/>
    <to uri="activemq:queue:one-way"/>
    <setExchangePattern pattern="InOut"/>
    <to uri="activemq:queue:in-and-out"/>
    <log message="InOut MEP received ${body}"/>
</route>
- route:
    from:
      uri: mq:someQueue
      steps:
        - setExchangePattern:
            pattern: InOnly
        - to:
            uri: activemq:queue:one-way
        - setExchangePattern:
            pattern: InOut
        - to:
            uri: activemq:queue:in-and-out
        - log:
            message: "InOut MEP received ${body}"
Using setExchangePattern to change the Exchange Pattern is often only used in special use-cases where you must force to be using either InOnly or InOut mode when using components that support both modes (such as messaging components like ActiveMQ, JMS, RabbitMQ etc.)

JMS component and InOnly vs. InOut

When consuming messages from JMS a Request Reply is indicated by the presence of the JMSReplyTo header. This means the JMS component automatic detects whether to use InOnly or InOut in the consumer.

Likewise, the JMS producer will check the current Exchange Pattern on the Exchange to know whether to use InOnly or InOut mode (i.e., one-way vs. request/reply messaging)

Other Implementation Details

There are concrete classes that implement the Message interface for each Camel-supported communications technology. For example, the JmsMessage class provides a JMS-specific implementation of the Message interface. The public API of the Message interface provides getters and setters methods to access the message id , body and individual header fields of a message.