Mumbai MuleSoft Meetup #20

30 Apr, 2022
Mumbai MuleSoft Meetup Group
Anypoint Monitoring and MQ Integrations

Guidelines for Mumbai MuleSoft Meetup #17
[Virtual]
● Welcome to Mumbai MuleSoft Meetup! We will start our introduction session at
11am IST.
● Once you join write down your registered name in chat section so that we can
provide you audio/video access in Bevy.
● Please keep yourself muted unless you have any question.
● We encourage keeping your video on for making our meetup interactive.
● You'll can also write down your questions in chat section.
● We appreciate your valuable feedback. Thanks.
2

3
●About the organizer:
○ Manish Yadav
○ Akshata Sawant
○ Parth Rawat
●About the sponsor:
○ MuleSoft
Introductions
A SHOW OF HANDS:
Who is new to this Meetup?

Annoucement
● TDX22 Event: A Salesforce biggest event successfully completed
● Anypoint Studio 7.12 with Mule Runtime 4.4
● Anypoint Flex Gateway: API Gateway for APIs running anywhere

Speakers
6
Manpreet Singh, Integration Specialist at Katzion Technology
Solutions Pty. Ltd., Melbourne, Australia.
Certified Mulesoft Platform Architect and Developer with 10+
years of total experience & 4+ years of working on Mulesoft.
Worked on various integration projects to implement SOA as
an Architect and a Developer.

7
● Introductions
● MQ Integrations
● Basics of Anypoint MQ
● Error handling
● Circuit breaker capabilities
● Quiz Time
● Wrap-up and Networking time
Agenda

9
● Anypoint MQ is a multi-tenant, cloud messaging service that enables customers to
perform advanced asynchronous messaging scenarios between their applications.
● Anypoint MQ is fully integrated with Anypoint Platform, offering role-based access
control, client management, and connectors.
What is Anypoint MQ

10
• Queues and Message Exchanges
• Management console
• Anypoint MQ connector
• Usage information
• REST API
• Environments and role-based access control
• Client management
• Large payloads - Anypoint MQ supports payloads up to 10 MB.
• Disaster recovery
• Delayed delivery for messages
• Encrypted queues - The payloads are encrypted with the AES-256 GCM algorithm on the
server side.
Features of Anypoint MQ

11
• Horizontal scalability
• By putting a message on a queue, the work to process that message can be distributed over multiple
subscribers.
• Reliability
• Queues ensure that messages are always processed,
even in the case of failure.
• Decoupling
• A queue can be used as a communication mechanism between different applications and devices, allowing
them to have different development life cycles or maintenance windows, without affecting other applications.
• Aggregation
• Multiple message producers can publish to a single queue, which enables easy consumption by consumers.
Queue

12
• Message TTL
• Each queue has a message time-to-live (TTL).
• Default Acknowledgement Timeout
• How long a message remains unacknowledged before being returned to the queue.
• Unlimited messages in a queue
• There is no limit on the number of messages in a queue. Each message in a queue is limited
to 10 MB.
• Billing and charging
• Billing is based on the number of messages delivered to subscribers from queues, not the
number of queues or message exchanges you create.
Queue

13
• FIFO queues are most suitable for single-consumer scenarios.
• When one consumer is accessing a message, all other consumers are blocked until the first
batch is processed.
• No messages are delivered until all in-flight messages are acknowledged or not
acknowledged.
FIFO Queue

14
● With message exchanges you can distribute a single message to multiple consumers.
● FIFO does not support the use of a message exchange. Similarly, FIFO queues cannot be
bound to a message exchange.
Message Exchanges

15
● Anypoint MQ enables you to ensure that messages that aren’t delivered are sent to a queue known
as the dead-letter queue (DLQ).
● You can then analyze the messages sent to the DLQ to determine why those messages were not
delivered.
● A DLQ is essentially the same as any other queue except that it receives only undelivered
messages. You can specify the time-to-live (TTL) value, encryption, and delivery delay when you
create the queue.
● You must have at least two queues for one of them to be assigned as a DLQ. Both queues must be:
• The same type (standard or FIFO)
• In the same geographical region
• In the same environment and owned by the same Anypoint Platform account.
Dead Letter Queue

17
Executes an acknowledgment indicating that the message is consumed correctly and deletes the
message from In Flight status.
Acknowledgment Modes
The Anypoint MQ connector provides three acknowledgment modes:
● Immediate: Use Immediate when you want to acknowledge messages as your app consumes them,
before processing them.
● Automatic: Use Automatic to acknowledge a received message automatically only if the flow
execution finishes successfully.
● Manual: Use Manual if you want the app logic to control message acknowledgment.
AMQ Operation - Ack

18
● Not acknowledging (Nack) a message informs the broker that the message was not
processed successfully and commands the broker to return the message to the queue
for redelivery to any available consumer.
● Nack executes a not acknowledgement and changes the status of the message from In
Flight to In Queue for subscriber consumption.
AMQ Operation - Nack

19
● The consume operation in the Anypoint MQ connector enables the app consume a
single message at any time of the flow, from any destination, using the
acknowledgement strategy that supports your use case.
AMQ Operation - Consume

20
● The Publish operation enables you to create a new Anypoint MQ message and send it to
the specified destination: queue, FIFO queue, or message exchange.
● With it, you can configure both the content of the message and all the headers and
properties you need.
AMQ Operation - Publish

21
● The Subscriber source in the Anypoint MQ connector enables the app to listen for new
messages and consume them as they arrive at the destination.
● You can configure different listening strategies that enable you to tune the consumption
for performance, predictability, and schedules.
AMQ Operation - Subscribe

22
● Let’s consider an architecture wherein the experience API (eAPI) is subscribed to a queue & passing on the request to the system
API (sAPI) which is invoking an end system.
● The experience API will fetch the messages from the queue.
● eAPI will then check a user property called ‘count’ which will determine the number of tries for that particular message.
● As long as the count is less than 3, the message will be sent to sAPI for further process.
● sAPI will then attempt to process & publish the message to the end system:
○ Upon success, sAPI will send the successful response to eAPI.
○ Upon receiving a business/data error from the end system, sAPI will send the error response to eAPI which will then publish the
message to the error queue with a delay of 2000 ms enriched with the error message for manual intervention & retry.
○ Upon receiving any other error like HTTP or Salesforce connectivity, the message will be enriched with the error details &
incrementing the value of the user property ‘count’ by +1, before it is published to the source queue.
■ eAPI will then again pull the message, check the value of count & repeat the process.
■ If the error is repetitive & count >= 3, the message will be published to the dead letter queue with a delay of 2000 ms with
the error message for manual intervention & retry.
Error Handling

24
The Subscriber source provides circuit breaking capability, which enables you to control how the
connector handles errors that occur while processing a consumed message.
● Circuit Breaker Processes
○ The circuit breaker capability that the Subscriber source provides is bound to the error handling
mechanism provided by Mule.
○ It uses the error notification mechanism to count errors related to an external service, which is
known as a circuit failure. You can bind any error to a circuit failure.
Circuit Breaker Capability

25
The circuit breaker has three states: Closed, Open, and Half Open.
• Closed
• The starting state where the Subscriber source retrieves messages normally from MQ
based on its configuration, effectively working as if the circuit breaker is not present.
● Closed-Open Transition
○ When the number of failures occurs in succession during message processing, without successes, and
reaches the errorsThreshold value, the circuit breaker trips and the circuit breaker transitions to an Open
state.
○ Messages that were already dispatched to the flow then finish processing, regardless of whether the result is
success or failure.
○ Messages kept locally that are in-flight for the broker but haven’t been dispatched yet are not acknowledged
and returned to the queue for redelivery to another consumer.
Circuit Breaker States

26
• Open
• The Subscriber source doesn’t attempt to retrieve messages and skips the iterations silently until tripTimeout
is reached.
● Half Open
○ After tripTimeout elapses, the Subscriber source goes to a Half Open state. In the next poll for messages, the
Subscriber source retrieves a single message from the service and uses that message to check if the system
has recovered before going back to the normal Closed state.
○ When the Subscriber source successfully fetches a single message, dispatches it to the flow, and processing
finishes successfully, the Subscriber source returns to normal and immediately attempts to fetch more
messages.
○ If Mule flow processing fails with one of the expected onErrorTypes, the circuit goes back to an Open state
and resets the tripTimeout timer.
Circuit Breaker States

28
References
● https://docs.mulesoft.com/anypoint-mq-connector/3.x/
● https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack
● https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-listener#circuit-breaker-
capability
● https://docs.mulesoft.com/mq/mq-apis
● https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker

Question 1
Which of the following is not an operation of the MQ connector?
A. Publish
B. Subscriber
C. Publish consume
D. Ack
E. Nack

Question 2
The payloads are encrypted with which algorithm on the server side in the
Anypoint MQ?
A. AES-256 GCM
B. Blowfish
C. RSA
D. DES

Question 3
What type of MQ should we use when the order of processing the messages
in the queue is critical?
A. Exchange
B. FIFO Queue
C. Circular Queue
D. Double-ended Queue

33
Nominate yourself for the next meetup
speaker and suggest a topic as well.
Take a stand!

34
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Invite your network to join: https://meetups.mulesoft.com/mumbai/
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
○ Contact your organizers Manish Yadav,Akshata Sawant and Parth Rawat to suggest
topics
○ Tweet your organizers at, @ManishYadav0719, @sawantakshata02,
@ParthRawat@561d1102f4154f8
○ Follow us on Instagram (mumbai_mulesoftofficialpage)
○ Telegram: https://t.me/joinchat/Q6y-MgriEqyDicfZV9PIAg
What’s next?

Introduce yourself to your neighbor
Networking time

Mumbai MuleSoft Meetup #20

Recommandé

Recommandé

Contenu connexe

Similaire à Mumbai MuleSoft Meetup #20

Similaire à Mumbai MuleSoft Meetup #20 (20)

Plus de Akshata Sawant

Plus de Akshata Sawant (20)

Dernier

Dernier (20)

Mumbai MuleSoft Meetup #20