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?
A. Both Correlation ID values should be stored in a persistent object store
B. The Correlation ID value in Step 1 should be stored in a persistent object storeThe Correlation ID value in Step 3 should be stored as a Mule event variable/attribute
C. Both Correlation ID values should be stored as Mule event variables/attributes
D. Both Correlation ID values should be stored in a non-persistent object store
|
Download Printable PDF. VALID exam to help you PASS. |
 |
I’m going with B.
Idempotent message filter inherently uses object store to verify that the message is not a duplicate and that is used right before Step 1. Step 3 does not need persistent storage so the ID can be stored in a variable.
The answer lies in the answer of this question – “If node1 fails before receiving the soap service response, does mule cluster still receives the response from soap service and ask node2 to continue processing?”
If yes, in that case using persistent object store make sense. But as per my understanding, the node that invoked soap service will only the one that is going to receive the response. So if we go with that option C is the right answer.
The scenario says that the app is deployed in multi-node Runtime. If you save the Correlation ID in the persistent object store, wouldn’t it be read by apps running on other nodes and defeat the whole purpose?
The only sensible answer is C.
If the application crashes, no acknowledgment is sent to JMS and the message will be re-queue and be processed by another node.
Answer is C and the question is very nice. It is tricky and tests the following
1. First – One instance of this flow ( ie., upon receiving one message) will not be run by multiple nodes even in a cluster. Whoever got a chance to run the flow ( always one as the nodes are aware of each other in cluster) . So the point to note here is there is no need to store anything in persistent or non persitent object store for another node to access.
2. Yes attributes are lost when transport boundary ( here its SOAP) occurs BUT closely observe step 3 – the same correlation id that SOAP service received is being set back. So though the attributes are lost inside SOAP service , its being reset to the same value. So back in the main flow it will stay in the same attribute ( again this because its manually set). On the other hand variables will remain alive till the end of the flow with in its flow.
So clearly its C.
C is correct for Mule 4.
Previous version (Mule3) will only work for B, because flowVars does not survive the transportation barrier.
Choice B will work both for Mule 3 and 4.
This question should tell us which version of mule runtime.
To be save choose B.
C
There is no need for persistence as long as JMS queue item is not acknowledged until the message is stored in the output queue. Even if you do store it in a persistent object store, the data cannot be reprocessed without another message queue trigger.
C is the most performant solution with not drawback
I think the answer is C as it says variable/attributes means that you can use Mule Event Variable to store the CORRELATION ID before making a callout. We are not achieving anything by storing the correlation id.
C is not valid, if you store CId on the ATTRIBUTE … that CId will be lost when the SOAP call is made.
I’ll go with B since is more performant than A.
This is conflicting scenario of achieving both HA and Performance with an extra Maintainable.
A: may not be Performant even though HA.
B : Is neither FaultTolerant nor Performant (persistent object store)
C: Storing in a variable is highly performant and HA guarantee is implict in Cluster.
D: An object store is Not Performant irrespective of Persistent or Non when compared with storing in a variable.
I will go with C. Since Multinode Cluster is anyway Ha and FaultTolerant and Performant is only storing in a Variable.
This is a hard one ….
HA: Comes with the cluster
Maintainability: I think it is not affected by the exposed use case,
Performant: B over A
Fault-tolerant: ?
I think the question is: How does persistence storage enhance fault-tolerancy in that flow? …I think it does not enhance that feature.
I will go with B, Not sure.
None of these things make it fault tolerant. If we store the correlation Id in the object store and the flow fails when calling the SOAP service then what happens? The message is lost and the correlation id is sitting out there in the object store of no value to anyone. What’s needed is a handler that puts a message to a DLQ in the event of a failure. Since the handler will have access to event attributes and variables we don’t need to use the object store.
Correlation ID is available in the header/attributes section. This can be stored into the Object store for later retrieval. In Step 2 SOAP request is made. Once the response comes back the original header/attributes are reset to new attributes of SOAP response. So answer should be B
vars will survive transportation barrier since Mule 4. It is true for mule 3 the flowVars will be lost
C seems correct
Looks like B is not correct , D may be the right one
B is the correct answer.
shouldnt the answer be A
A should be the right answer.
Logic of choosing B is not right. We already save step 1 into object store why leaving step 3 result in memory?
Hint is in the question “Mule application highly available, fault-tolerant, performant, and maintainable”.
If choose B, when app fails at step 3, the second correlation id will be lost.