Exam MCIA - Level 1 All QuestionsBrowse all questions from this exam
Go to Exam
Question 32

Refer to the exhibit. A Mule application is deployed to a multi-node Mule runtime cluster. The Mule application uses the competing consumer pattern among its cluster replicas to receive JMS messages from a JMS queue. To process each received JMS message, the following steps are performed in a flow:

Step 1: The JMS Correlation ID header is read from the received JMS message.

Step 2: The Mule application invokes an idempotent SOAP webservice over HTTPS, passing the JMS Correlation ID as one parameter in the SOAP request.

Step 3: The response from the SOAP webservice also returns the same JMS Correlation ID.

Step 4: The JMS Correlation ID received from the SOAP webservice is validated to be identical to the JMS Correlation ID received in Step 1.

Step 5: The Mule application creates a response JMS message, setting the JMS Correlation ID message header to the validated JMS Correlation ID and publishes that message to a response JMS queue.

Where should the Mule application store the JMS Correlation ID values received in Step 1 and Step 3 so that the validation in Step 4 can be performed, while also making the overall Mule application highly available, fault-tolerant, performant, and maintainable?

    Correct Answer: C

    In this Mule application scenario, both Correlation ID values should be stored as Mule event variables/attributes. This approach ensures that the values are kept within the same thread and flow context, which is crucial for maintaining the accuracy and consistency of the data throughout the flow execution. Storing the Correlation IDs as Mule event variables/attributes avoids potential issues related to sharing or overriding the values among different nodes in the cluster. Additionally, this solution maintains the application's high availability, fault tolerance, performance, and maintainability, as it leverages the JMS message redelivery mechanism in case of a failure, ensuring the message will be reprocessed correctly.

Discussion
bob_d_builderOption: C

Scenario says that app is deployed in multi-node Runtime. If you save the Correlation ID in persistent object store, wouldn't it be read by apps running on other nodes and defeat the whole purpose? Only sensible answer is C. If the application crashes, no acknowledgement is sent to JMS and the message will re-queue and processed by another node.

Outdoor25Option: B

B is correct. You need Persistent OS. SOAP is over HTTP. Calls to HTTP within mule flow will rest all variables and attributes. Cannot be D, because its non Persistent OS. You need persistent for better reliability.

majda091983

call http will rest only attributes not variables

sanni27Option: C

It should be C as its multi node cluster and competence consumer pattern so multiple consumer will consume the message and in this case multiple correlation id comparison will happens. Better to keep the ids in same thread rather shared resource.

gilofernandesOption: C

There's no need to store the correlation id from any step in a persistent OS. If a message is not successfully processed is not deleted from the JMS and in the next subscription the same message with the same correlation Id header value is processed. In step 1 is necessary to store the correlation id in a variable because it is extracted from the payload, and the original payload is lost after the SOAP request. In step 3 the correlation id received from the WS response must be stored in a var to be compared with the original one. C is the correct answer.

mamorOption: B

fault-tolerant, performant, and maintainable.

jarit75Option: A

was in practise exam C was not correct in that..

rodriguescontOption: B

Should be B Although persistent OS is not performant, it’s the only way to guarantee fault tolerance HTTP request will reset the variables/attributes Customer-hosted and RTF just share OS via REST API, which implies that the OS be persistent for HA

rodriguescont

Let me correct myself… In clusters the non persistent OS is shared among all nodes So, as long as at least one remains active, D is the most performant and reliable

Pavan_NagineniOption: B

Why do you need to go for Persistent OS, when you are dealing with the state across your flows/apps. Here everything happens in same thread pretty much you cna manage with mule event/variables

AlandtOption: C

Made the practice exam from Mulesoft and correct answer was C

adnankhanOption: B

Correct ans is B 1 Persistent object store cant be shared between rtf cluster nodes because it is in the files not in memory (if the obj store is not persistent then it gets shared between the nodes) 2 in step 2 they are calling an idempotent SOAP service, it cant be called again with the same request, we need to store its response or request in our case its corrId 3 In time of crash we don't need to call soap service again because its an idempotent SOAP service and we already have our correlation id with us so its is easy to compare

gilofernandesOption: C

There's no need to persist any coorrelation id. In case of any failure, message is not acknowledge and next time the same message will be read again from the JMS queue and all the flow processed again.

lwong1Option: C

Object Store is a shared key value store. So if it's saved as "correlationId=123"; other nodes will override the value. Also it doesn't support XA transactions. To be high available, fault tolerant, performant and maintainable it should rely more on JMS as it can be load balance and should deliver an acknowledge only after the flow was processed (AUTO mode). For this I believe that the answer is C.

_d4d_Option: B

Answer is B.

majda091983Option: C

I dont understand why we should store in object store since we are in the same flow same application

madgeezerOption: C

C. Both Correlation ID values should be stored as Mule event variables/attributes