A mule application is being designed to perform product orchestration. The Mule application needs to join together the responses from an inventory API and a Product Sales History API with the least latency.
To minimize the overall latency. What is the most idiomatic (used for its intended purpose) design to call each API request in the Mule application?

• A.Call each API request in a separate lookup call from Dataweave reduce operator
• B.Call each API request in a separate route of a Scatter-Gather
• C.Call each API request in a separate route of a Parallel For Each scope
• D.Call each API request in a separate Async scope

Comment: *

Name: *

Email: *

Verification: *

An Order microservice and a Fulfillment microservice are being designed to communicate with their dients through message-based integration (and NOT through API invocations).
The Order microservice publishes an Order message (a kind of command message) containing the details of an order to be fulfilled. The intention is that Order messages are only consumed by one Mute application, the Fulfillment microservice.
The Fulfilment microservice consumes Order messages, fulfills the order described therein, and then publishes an OrderFulfilted message (a kind of event message). Each OrderFulfilted message can be consumed by any interested Mule application, and the Order microservice is one such Mute application.
What is the most appropriate choice of message broker(s) and message destination(s) in this scenario?

• A.Order messages are sent to an Anypoint MQ exchange OrderFulfilled messages are sent to an Anypoint MQ queue Both microservices interact with Anypoint MQ as the message broker, which must therefore scale to support the load of both microservices
• B.Order messages are sent to a JMS queue. OrderFulfilled messages are sent to a JMS topic Both microservices interact with the same JMS provider (message broker) instance, which must therefore scale to support the load of both microservices
• C.Order messages are sent directly to the Fulfillment microservices. OrderFulfilled messages are sent directly to the Order microservice The Order microservice interacts with one AMQP-compatible message broker and the Fulfillment microservice interacts with a different AMQP-compatible message broker, so that both message brokers can be chosen and scaled to best support the load of each microservice
• D.Order messages are sent to a JMS queue. OrderFulfilled messages are sent to a JMS topic The Order microservice interacts with one JMS provider (message broker) and the Fulfillment microservice interacts with a different JMS provider, so that both message brokers can be chosen and scaled to best support the load of each microservice

Correct Answer: B

* If you need to scale a JMS provider/ message broker, - add nodes to scale it horizontally or - add memory to scale it vertically * Cons of adding another JMS provider/ message broker: - adds cost. - adds complexity to use two JMS brokers - adds Operational overhead if we use two brokers, say, ActiveMQ and IBM MQ * So Two options that mention to use two brokers are not best choice. * It's mentioned that "The Fulfillment microservice consumes Order messages, fulfills the order described therein, and then publishes an OrderFulfilled message. Each OrderFulfilled message can be consumed by any interested Mule application." - When you publish a message on a topic, it goes to all the subscribers who are interested - so zero to many subscribers will receive a copy of the message. - When you send a message on a queue, it will be received by exactly one consumer. * As we need multiple consumers to consume the message below option is not valid choice: "Order messages are sent to an Anypoint MQ exchange. OrderFulfilled messages are sent to an Anypoint MQ queue. Both microservices interact with Anypoint MQ as the message broker, which must therefore scale to support the load of both microservices" * Order messages are only consumed by one Mule application, the Fulfillment microservice, so we will publish it on queue and OrderFulfilled message can be consumed by any interested Mule application so it need to be published on Topic using same broker. * answer: Best choice in this scenario is: "Order messages are sent to a JMS queue. OrderFulfilled messages are sent to a JMS topic. Both microservices interact with the same JMS provider (message broker) instance, which must therefore scale to support the load of both microservices" Tried to depict scenario in diagram:
Diagram Description automatically generated

Comment: *

Name: *

Email: *

Verification: *

According to MuleSoft, a synchronous invocation of a RESTful API using HTTP to get an individual customer record from a single system is an example of which system integration interaction pattern?

• A.Request-Reply
• B.Multicast
• C.Batch
• D.One-way

Comment: *

Name: *

Email: *

Verification: *

An XA transaction Is being configured that involves a JMS connector listening for Incoming JMS messages.
What is the meaning of the timeout attribute of the XA transaction, and what happens after the timeout expires?

• A.The time that is allowed to pass between committing the transaction and the completion of the Mule flow After the timeout, flow processing triggers an error
• B.The time that Is allowed to pass between receiving JMS messages on the same JMS connection After the timeout, a new JMS connection Is established
• C.The time that Is allowed to pass without the transaction being ended explicitly After the timeout, the transaction Is forcefully rolled-back
• D.The time that Is allowed to pass for state JMS consumer threads to be destroyed After the timeout, a new JMS consumer thread is created

Correct Answer: C

* Setting a transaction timeout for the Bitronix transaction manager
# Set the transaction timeout either
- In wrapper.conf
- In CloudHub in the Properties tab of the Mule application deployment
# The default is 60 secs. It is defined as
mule.bitronix.transactiontimeout = 120
* This property defines the timeout for each transaction created for this manager.
If the transaction has not terminated before the timeout expires it will be automatically rolled back.
--------------------------------------------------------------------------------------------------------------------- Additional Info around Transaction Management:
Bitronix is available as the XA transaction manager for Mule applications
# To use Bitronix, declare it as a global configuration element in the Mule application
<bti:transaction-manager />
# Each Mule runtime can have only one instance of a Bitronix transaction manager, which is shared by all Mule applications
# For customer-hosted deployments, define the XA transaction manager in a Mule domain
- Then share this global element among all Mule applications in the Mule runtime Graphical user interface, table Description automatically generated with medium confidence

Comment: *

Name: *

Email: *

Verification: *

A retail company is implementing a MuleSoft API to get inventory details from two vendors by Invoking each vendor's online applications. Due to network issues, the invocations to the vendor applications are timing out intermittently, but the requests are successful after re-invoking each What is the most performant way of implementing the API to invoke each vendor application and to retry invocations that generate timeout errors?

• A.Use a Scatter-Gather scope to invoke each vendor application on a separate route.
  Use an Until-Successful scope in each route to retry requests that raise timeout errors.
• B.Use a Choice scope to Invoke each vendor application on a separate route.
  Place the Choice scope inside an Until-Successful scope to retry requests that raise timeout errors.
• C.Use a For-Each scope to invoke the two vendor applications in series, one after the other.
  Place the For-Each scope inside an Until-Successful scope to retry requests that raise timeout errors.
• D.Use a Round-Robin scope to invoke each vendor application on a separate route.
  Use a Try-Catch scope in each route to retry requests that raise timeout errors.

Comment: *

Name: *

Email: *

Verification: *