Pass the MuleSoft Certified Developer MCD-Level-1 Questions and answers with ValidTests

URL parameters are always accessed using { } like => {customerID}

As can be seen in error message , SOAP service findFlights expects the SOAP paylaod. This can be set using transform message processor which forms SOAP payload before the Consume operation that contains the destination query parameter

Logs would look like:

INFO 2021-06-09 19:14:56,039 [[MuleRuntime].uber.06: [validationtest].batch-job-validationtestBatch_Job-work-manager @6de10f3e] [processor: validationtestFlow/processors/1/route/0/route/0/aggregator/processors/0; event: bfb751e1-9939-11eb-9f69-02053763653a] org.mule.runtime.core.internal.processor.LoggerMessageProcessor:

[

“\”A\””,

“\”C\””,

“\”D\””

]

—-

INFO 2021-06-09 19:15:02,486 [[MuleRuntime].uber.06: [validationtest].batch-job-validationtestBatch_Job-work-manager @6de10f3e] [processor: validationtestFlow/processors/1/route/0/route/0/aggregator/processors/0; event: bfb751e1-9939-11eb-9f69-02053763653a] org.mule.runtime.core.internal.processor.LoggerMessageProcessor: [

“\”E\””

]

Batch aggregator value is 3. Hence in first time it will print [“A”, “C”, “D”] and in next iteration it will print [ “E” ]

--------------------------------------------------------------------------------------------------------------------------------------------------

Correct answer is [ “E” ]

MuleSoft Documentation Reference : https://docs.mulesoft.com/db-connector/1.9/database-connector-select

Error in validation component will get processed by Processer level On Error Propagate block and then error will be rethrown which will get processed by flow level error handler which will set payload to "Error- main flow". Hence correct answer is Error - main flow

1) Request is received by HTTP listener

2) Try scope gets executed

3) The validator component in the Try scope creates an Error Object because the payload is not null.

4) The On Error Propagate handles the error. The payload is set to “Error – Try scope”

6) “Error – Try scope” is returned to the 'On Error Continue' block. Main flow execution stops. Payload is set to "Error - main flow"

7) “Error - main flow” is returned to the requestor in the body of the HTTP request. HTTP Status Code: 200

------------------------------------------------------------------------------------------------------------------------------------------

Reference Diagram though not exactly same, conditions are similar. They will help you answer any new question on error handling in real exam:

Timeline Description automatically generated

https://docs.mulesoft.com/mule-runtime/4.3/on-error-scope-concept#on-error-continue

Scatter-Gather Router

The Scatter-Gather component is a routing event processor that processes a Mule event through different parallel processing routes that contain different event processors. Each route receives a reference to the Mule event and executes a sequence of one or more event processors. Each of these routes uses a separate thread to execute the event processors, and the resulting Mule event can be either the same Mule event without modifications or a new Mule event with its own payload, attributes, and variables. The Scatter-Gather component then combines the Mule events returned by each processing route into a new Mule event that is passed to the next event processor only after every route completes successfully.

The Scatter-Gather component executes each route in parallel, not sequentially. Parallel execution of routes can greatly increase the efficiency of your Mule application and may provide more information than sequential processing.

Mule Ref Doc : https://docs.mulesoft.com/mule-runtime/4.3/scatter-gather-concept

Lets revise few concepts RAML which can help us to find the answer of this question.

URI Parameters

Lets have a look at below example.

/foos:

/{id}:

/name/{name}:

Here, the braces { } around property names define URI parameters. They represent placeholders in each URI and do not reference root-level RAML file properties as we saw above in the baseUri declaration. The added lines represent the resources /foos/{id} and /foos/name/{name}.

Query Parameters

Now we'll define a way to query the foos collection using query parameters. Note that query parameters are defined using the same syntax that we used above for data types:

/foos:

get:

description: List all Foos matching query criteria, if provided;

otherwise list all Foos

queryParameters:

name?: string

ownerName?: string

Based on the above information , below is the only option which defines storeid as uri parameter and department as query parameter.

/{storeId}:

get:

queryParameter:

department:

As can be seen in RAML, POST expects input in application/json format which eliminates two of the options as two options are in xml format.

Now out of the two remaining options, one has id field in request which is only mentioned for get response and not for POST request. Hence id field is not expected in POST request.

Hence correct answer is

{

"name": "GoerdiLa Forge",

"address": "1 Westland CA",

"customer_since": "2014-01-04",

"balance": "4829.29",

"bank_agend_id": "12556"

}