MuleSoft Certified Architect MCIA-Level-1 Release Date

Page: 7 / 20

Question 28

As an enterprise architect, what are the two reasons for which you would use a canonical data model in the new integration project using Mulesoft Anypoint platform ( choose two answers )

Options:

To have consistent data structure aligned in processes

To isolate areas within a bounded context

To incorporate industry standard data formats

There are multiple canonical definitions of each data type

Because the model isolates the back and systems and support mule applications from change

Question 29

Which key DevOps practice and associated Anypoint Platform component should a MuteSoft integration team adopt to improve delivery quality?

Options:

A Continuous design with API Designer

Automated testing with MUnit

Passive monitoring with Anypoint Monitoring

Manual testing with Anypoint Studio

Question 30

Refer to the exhibit.

This Mule application is deployed to multiple Cloudhub workers with persistent queue enabled. The retrievefile flow event source reads a CSV file from a remote SFTP server and then publishes each record in the CSV file to a VM queue. The processCustomerRecords flow’s VM Listner receives messages from the same VM queue and then processes each message separately.

How are messages routed to the cloudhub workers as messages are received by the VM Listener?

Options:

Each message is routed to ONE of the Cloudhub workers in a DETERMINSTIC round robin fashion thereby EXACTLY BALANCING messages among the cloudhub workers

Each messages routes to ONE of the available Clouhub workers in a NON- DETERMINSTIC non round-robin fashion thereby APPROXIMATELY BALANCING messages among the cloudhub workers

Each message is routed to the SAME Cloudhub worker that retrieved the file, thereby BINDING ALL messages to ONLY that ONE Cloudhub worker

Each message is duplicated to ALL of the Cloudhub workers, thereby SHARING EACH message with ALL the Cloudhub workers.

Question 31

A company is designing an integration Mule application to process orders by submitting them to a back-end system for offline processing. Each order will be received by the Mule application through an HTTP5 POST and must be acknowledged immediately.

Once acknowledged the order will be submitted to a back-end system. Orders that cannot be successfully submitted due to the rejections from the back-end system will need to be processed manually (outside the banking system).

The mule application will be deployed to a customer hosted runtime and will be able to use an existing ActiveMQ broker if needed. The ActiveMQ broker is located inside the organization's firewall. The back-end system has a track record of unreliability due to both minor network connectivity issues and longer outages.

Which combination of Mule application components and ActiveMQ queues are required to ensure automatic submission of orders to the back-end system while supporting but minimizing manual order processing?

Options:

One or more On Error scopes to assist calling the back-end system An Untill successful scope containing VM components for long retries A persistent dead-letter VM queue configure in Cloud hub

An Until Successful scope to call the back-end system One or more ActiveMQ long-retry queues One or more ActiveMQ dead-letter queues for manual processing

One or more on-Error scopes to assist calling the back-end system one or more ActiveMQ long-retry queues A persistent dead-letter Object store configuration in the CloudHub object store service

A batch job scope to call the back in system An Untill successful scope containing Object Store components for long retries. A dead-letter object store configured in the Mule application

Answer:

Explanation:

To design an integration Mule application that processes orders and ensures reliability even with an unreliable back-end system, the following components and ActiveMQ queues should be used:

Until Successful Scope: This scope ensures that the Mule application will continue trying to submit the order to the back-end system until it succeeds or reaches a specified retry limit. This helps in handling transient network issues or minor outages of the back-end system.
ActiveMQ Long-Retry Queues: By placing the orders in long-retry queues, the application can manage retries over an extended period. This is particularly useful when the back-end system experiences longer outages. The ActiveMQ broker, located within the organization’s firewall, can reliably handle these queues.
ActiveMQ Dead-Letter Queues: Orders that cannot be successfully submitted after all retry attempts should be moved to dead-letter queues. This allows for manual processing of these orders. The dead-letter queue ensures that no orders are lost and provides a clear mechanism for handling failed submissions.

Implementation Steps:

HTTP Listener: Set up an HTTP listener to receive incoming orders.
Immediate Acknowledgment: Immediately acknowledge the receipt of the order to the client.
Until Successful Scope: Use the Until Successful scope to attempt submitting the order to the back-end system. Configure retry intervals and limits.
Long-Retry Queues: Configure ActiveMQ long-retry queues to manage retries.
Dead-Letter Queues: Set up ActiveMQ dead-letter queues for orders that fail after maximum retry attempts, allowing for manual intervention.

This approach ensures that the system can handle temporary and prolonged back-end outages while minimizing manual processing.

References:

MuleSoft Documentation on Until Successful Scope: https://docs.mulesoft.com/mule-runtime/4.3/until-successful-scope
ActiveMQ Documentation: https://activemq.apache.org/

Page: 7 / 20