MCD-ASSOC Sample Questions & Answers

The Response Timeout setting dictates the maximum time (in milliseconds) the connector will wait for a response after sending the request. This directly addresses the 5-second maximum response time requirement.

The Connection Idle Timeout setting specifies the maximum time a connection can remain idle in the connection pool before being closed. This prevents connections from being held open indefinitely, satisfying the second requirement.

Subflows do not have their own error handling scope. Any error occurring in a subflow is immediately passed to the error handler of the flow that called it. Private flows, like main flows, have their own processing strategy and error handling scope. If an error occurs and is not handled within the private flow, it is then re-thrown and can be caught by the calling flow.

The most idiomatic and efficient approach in DataWeave is to first reduce the dataset using the filter function based on the condition (item.inStock == true). Then, the map function is used on the smaller, filtered array to perform the structural transformation to XML. This avoids iterating over items that will be discarded.

Setting the Scatter-Gather's timeout to 8000ms ensures the router does not wait longer than 8 seconds. Wrapping each route in a Try scope with an On Error Continue handler allows a failing route to complete 'successfully' from the Scatter-Gather's perspective, returning an error object instead of failing the entire component. This allows the aggregation phase to proceed as long as the timeout is not reached, and the developer can then inspect the results to see which routes succeeded or failed.

The scheduler's execution is not guaranteed to be perfectly timed. Factors such as worker resource availability, thread contention, and the duration of the flow's execution can cause slight delays or 'jitter'. Furthermore, if the flow execution takes longer than the scheduled interval (e.g., 12 seconds), the next scheduled run might be skipped or delayed depending on the configured scheduling strategy. Therefore, it is not guaranteed to run exactly 6 times.

APIkit automatically validates incoming requests against the defined RAML specification, including schema validation for request bodies. If the payload does not conform to the schema (e.g., is malformed or has incorrect data types), APIkit will stop processing and automatically generate an HTTP 400 Bad Request response without the request ever reaching the implementation flow.

The Mule Debugger view is the primary interface for inspecting the Mule event during a debug session. It displays the payload, attributes, and variables. By right-clicking on a variable in this view, the developer can choose to change its value, allowing them to dynamically alter the event's state and test different execution paths.

When exposing a SOAP web service from a WSDL, the APIkit for SOAP module is used. The 'APIkit SOAP Router' component acts as the message source for the flow. Internally, it uses an HTTP Listener to receive the raw HTTP request, but the router itself is the component that understands the SOAP protocol and routes the request to the correct operation flow.

By default, when a Flow Reference calls another flow, the payload of the calling flow is replaced by the payload returned from the referenced flow. Setting the target property to a variable name (e.g., myFlowResult) causes the referenced flow's return payload to be stored in vars.myFlowResult instead, leaving the original payload of the calling flow untouched.

The Client ID Enforcement policy requires any calling application to present a valid client ID and client secret. To secure the System APIs, they can be configured with this policy in API Manager. Then, a contract is created that grants access to the Process API's specific client ID. This ensures that only registered and approved applications (like the Process API) can invoke the System API, preventing direct external access.