Mule AMQP connector examples

Mule AMQP Connector Examples

Thanh Nguyen

Connection Fallback

• You can define a list of <host>:<port> or <host> brokers to try to connect to in case the main one fails to connect

Connection Fallback

• The fallbackAddresses attribute is a comma-separated list of brokers that you can specify as "host:port" or "host“

• The addresses are used along with the main one each time a connection is attempted: if the first attempt fails (main address), the next address is used to attempt connecting, and so on

Reconnection Strategy

• The first broker you specify in the list is called the main address or the master broker

• The non-master brokers are only connected to if the master broker fails

• If the master broker fails, control passes to the next broker in the list

• If that broker fails and if the master broker has returned to being online, control passes back to the master broker

Reconnection Strategy

• If the master broker is still offline, control passes to the next broker in the list that is online

• If fallback is not set and the master broker is not responding, AMQP fails

• If fallback is set and the master broker is not responding, fallback occurs, and control moves to the next broker in the list

Listening to Messages with Exchange Redeclaration and Queue Creation

Listening to Messages with Exchange Redeclaration and Private Queue Creation

Listening to Messages on a Pre-Existing Exchange

Listening to Messages on a Pre-existing Queue

Listening to Messages on a Declared But Unbound Queue

Manual Message Acknowledgment and Rejection

Manual Channel Recovery

Flow Control

Publishing Messages to a Redeclared Exchange

Publishing Messages to a Pre-Existing Exchange

Publishing Messages to a Pre-Existing Exchange

• configuring the connector to perform passive declarations:

Declaring and Binding an Outbound Queue

Message-Level Override of Exchange and Routing Key

• It’s possible to override some outbound endpoint attributes with outbound-scoped message properties: – routing-key overrides the routingKey attribute– exchange overrides the exchangeName attribute

Mandatory and Immediate Deliveries and Returned Message Handling

Mandatory and Immediate Deliveries and Returned Message Handling

• It’s also possible to define the returned message endpoint at flow level:

Request-Response Publication

Transaction Support

• Declares an AMQP inbound endpoint that starts a new transaction for each newly-received message:

Transaction Support

• The following declares a transacted AMQP bridge:

Transaction Support

• Configure a recoverStrategy attribute on the transaction element, as shown below:

Exchange and Queue Declaration Arguments

Programmatic Message Requesting

• Optional parameters in square brackets:

• a pre-existing queue named "my-queue", to be consumed with a unique AMQP connector available in the Mule configuration:

Programmatic Message Requesting

• routing key on the specified connector:

• retrieve a message from the queue using the Mule Client

SSL Connectivity

• use the AMQPS connector with the XML namespace declaration listed below

• Connect using SSLv3 (default) and use a trust manager that accepts all certificates as valid:

SSL Connectivity

• Connect using TLS and use a trust manager that accepts all certificates as valid:

• Connect using SSLv3 (default) and use a custom trust manager:

SSL Connectivity

• Connect using TLS and use a custom trust manager:

• Connect with key and trust stores:

<amqps:connector name="amqpsTlsKeyStores"> <amqps:ssl-key-store path="keycert.p12" type="PKCS12" algorithm="SunX509" keyPassword="MySecretPassword" storePassword="MySecretPassword" /> <amqps:ssl-trust-store path="trustStore.jks" type="JKS" algorithm="SunX509" storePassword="rabbitstore" /> </amqps:connector>

Question and answer