Download - 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