MuleSoft MCD - Level 1 Practice Test - Questions Answers, Page 21

Below are the Key performance indicators (KPIs), to measure and track the and success of the C4E and its activities, as well as the growth and health of the application network. Most of the metrics can be extracted automatically, through REST APIs, from Anypoint Platform.

* # of assets published to Anypoint Exchange

* # of interactions with Anypoint Exchange assets

* # of APIs managed by Anypoint Platform

* # of System APIs managed by Anypoint Platform

* # of API clients registered for access to APIs

* # of API implementations deployed to Anypoint Platform

* # of API invocations

* # or fraction of lines of code covered by automated tests in CI/CD pipeline

* Ratio of info/warning/critical alerts to number of API invocations

Sequence can be described as follows.

* When web client sends the request , it sends payload as Blue (mentioned in question)

* In first iteration this will go to default choice , which sets payload to Red

* Via default route , flow will call itself with payload as Red

* In second iteration , as payload is Red , it will go to first route in choice router which will set payload to Blk and second iteration will end returning back payload as Blk to first iteration.

* This Blk will be again set to payload and first iteration will end returning back response as Blk

Setting Breakpoints

To set breakpoints, right-click a building block, then select Toggle Breakpoint.

Studio applies a red dot to the building block's icon on the canvas.

When you run your application in Debug mode, Studio stops the flow execution at the breakpoint you have set, allowing you to check the Mule Event content in the Mule Debugger View.

Mule Ref Doc :Setting Breakpoints | MuleSoft Documentation

Correct answer is as below.On complete phase only has access to batch job result statistics and payload is not available.

Total Records Processed: 3

Successful Records: 3

Failed Records: 0

On Complete

During this phase, you can optionally configure the runtime to create a report or summary of the records it processed for the particular batch job instance. This phase exists to give system administrators and developers some insight into which records failed to address any issues that might exist with the input data.

Sample output is as below

Mule Ref Doc :https://docs.mulesoft.com/mule-runtime/4.3/batch-processing-concept#on-complete

Correct answer is vars.'customer'.'firstName'

Please note that you can also access firstName using this syntax vars.customer.firstName.

Mule Ref Doc :Variables in Mule Apps | MuleSoft Documentation

Correct answer is an operation. For each method of the RAML specification , REST connect module provide an operation.

Please refer to the below screenshot.

This question validates you knowledge on Batch Processing. Before we analyze the question , lets revise a bit about batch filters.

Batch Filters

You can apply one or more filters as attributes to any number of batch steps.

Imagine a batch job whose first batch step checks if a Salesforce contact exists for a record, and a second batch step that updates each existing Salesforce contact with new information. You can apply a filter to the second batch step to ensure it only processes records that didn't fail during the first batch step.

By having batch steps accept only some records for processing, you streamline the batch job so the Mule runtime engine can focus only on the relevant data for a particular batch step.

A batch step uses two attributes to filter records:

acceptExpression

acceptPolicy

Each batch step can accept oneacceptExpressionand oneacceptPolicyattributes to filter records.

Use theacceptExpressionattribute to process only records that evaluate to true; if the record evaluates to false, the batch step skips the record and sends it to the next one. In other words, the records with an accept expression that resolves to false are the ones that Mule filtersout.

The example below filters out all records where the age is less than 21; the batch step does not process those records.

<batch:job jobName='batchJob'>

<batch:process-records >

<batch:step name='adultsOnlyStep' acceptExpression='#[payload.age > 21]'>

...

</batch:step>

</batch:process-records>

</batch:job>

Mule Ref Doc :Refining Batch Steps Processing | MuleSoft Documentation

As we are clear with above concepts , now lets understand this solution step by step.

1) Batch Step (Less than 50)

Accept expression for this batch step is less than 50. Hence elements which will go in this batch step are amount value 40 and 2. Hence output of logger in first batch step is

{amount=140}

{amount=102}

2) Batch Step (Greater than 20)

Accept condition for this batch step is greater than 20. Note that input amount values for this batch step are 100 , 140 and 102 (last two values have been updated in batch step less than 50)

As all values satisfy this condition out put of second logger is

{step2amount=100}

{step2amount=140}

{step2amount=102}

Hence correct answer to this question is

{amount=140}

{amount=102}

{step2amount=100}

{step2amount=140}

{step2amount=102}

2) Batch Step (Greater than 20)

Accept condition for this batch step is greater than 20. Note that input amount values for this batch step are 100 , 140 and 102 (last two values have been updated in batch step less than 50)

As all values satisfy this condition out put of second logger is

{step2amount=100}

{step2amount=140}

{step2amount=102}

Hence correct answer to this question is

{amount=140}

{amount=102}

{step2amount=100}

{step2amount=140}

{step2amount=102}

Correct syntax to use where clause isWHERE city = :city AND state = :state

This question validates knowledge on using dynamic queries in DBselect operation.

Configure Dynamic Queries in the Select Operation

When you need to parameterize not only theWHEREclause but also parts of the query itself (for example, queries that compare tables that depend on a condition, or complex queries for which the project table columns need to vary), you can configure dynamic queries.

In the following example, you configure a dynamic query by using a full expression with a string in which the table depends on a variable$(vars.table). Although some of the query text is dynamic ('SELECT * FROM $(vars.table)), theWHEREclause still defines theWHEREcondition using input parameters: in this case,WHERE name = :name.

In your Studio flow, select theSelectoperation.

In the operation configuration screen, set theSQL Query Textfield toSELECT * FROM $(vars.table) WHERE name = :name.

Set theInput Parametersfield to{'name' : payload}.

The following screenshot shows the configuration in Studio:

Figure 3. Dynamic query configuration

In the XML editor, the<db:sql>configuration looks like this:

<set-variable variableName='table' value='PLANET'/>

<db:select config-ref='dbConfig'>

<db:sql>#['SELECT * FROM $(vars.table) WHERE name = :name']</db:sql>

<db:input-parameters>

#[{'name' : payload}]

</db:input-parameters>

</db:select>

You can apply input parameters only to parameters in aWHEREclause. To modify any other part of the query, use the DataWeave interpolation operator.

Mule Ref Doc:Query a Database Examples - Mule 4 | MuleSoft Documentation

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 thebaseUrideclaration. The added lines represent the resources/foos/{id}and/foos/name/{name}.

Query Parameters

Now we'll define a way to query thefooscollection 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 definesstoreidas uri parameter anddepartmentas query parameter.

/{storeId}:

get:

queryParameter:

department: