Which plugin or dependency is required to unit test modules created with XML SDK?
A.
XMLUnit
B.
Junit
C.
MUnit Extensions Maven plugin
D.
MUnit Maven plugin
MUnit Extensions Maven plugin
Explanation:
To unit test modules created with XML SDK, the developer needs to use the MUnit Extensions Maven plugin. This plugin allows testing XML SDK modules using MUnit by adding a dependency to the module under test and using a custom processor tag to invoke it.
References:
https://docs.mulesoft.com/mule-sdk/1.1/xml-sdk#testing
When implementing a synchronous API where the event source is an HTTP Listener, a developer needs to return the same correlation ID back to the caller in the HTTP response header. How can this be achieved?
A.
Enable the auto-generate CorrelationID option when scaffolding the flow
B.
Enable the CorrelationID checkbox in the HTTP Listener configuration
C.
Configure a custom correlation policy
D.
NO action is needed as the correlation ID is returned to the caller in the response header by default
NO action is needed as the correlation ID is returned to the caller in the response header by default
Explanation:
When implementing a synchronous API where the event source is an HTTP Listener, Mule automatically propagates some message attributes between flows via outbound and inbound properties. One of these attributes is correlation ID, which is returned to the caller in the response header by default as MULE_CORRELATION_ID.
References:
https://docs.mulesoft.com/mule-runtime/4.3/about-mule-message#message-attributes
Which properties are mandatory on the HTTP Connector configuration in order to use the OAuth 2.0 Authorization Code grant type for authentication?
A.
External callback URL, access token URL, client ID response access token
B.
Token URL, authorization URL, client ID, client secret local callback URL
C.
External callback URL, access token URL, client ID, response refresh token
D.
External callback URL, access token URL, local authorization URL, authorization URL, client ID, client secret
Token URL, authorization URL, client ID, client secret local callback URL
Explanation
To use the OAuth 2.0 Authorization Code grant type for authentication, the HTTP Connector configuration requires the following properties: token URL, authorization URL, client ID, client secret, and local callback URL. The token URL is the endpoint of the authorization server that provides access tokens. The authorization URL is the endpoint of the authorization server that initiates the user consent flow. The client ID and client secret are the credentials of the Mule application registered with the authorization server. The local callback URL is the endpoint of the Mule application that receives the authorization code from the authorization server.
References: https://docs.mulesoft.com/http-connector/1.6/http-authentication#oauth-2-0
A developer has created the first version of an API designed for business partners to work commodity prices. What should developer do to allow more than one major version of the same API to be exposed by the implementation?
A.
In Design Center, open the RAML and modify each operation to include the major version number
B.
In Anypoint Studio, generate scaffolding from the RAML, and the modify the <http:listerner> in the generated flows to include a parameter to replace the version number
C.
In Design Center, open the RAML and modify baseUn to include a variable that indicates the version number
D.
In Anypoint Studio, generate scaffolding from the RAML, and then modify the flow names generated by APIKit to include a variable with the major version number
In Design Center, open the RAML and modify baseUn to include a variable that indicates the version number
Explanation:
To allow more than one major version of the same API to be exposed by the implementation, the developer should modify the baseUri property in the RAML file to include a variable that indicates the version number. The baseUri property defines the base URL of the API and can include variables that are replaced with actual values when mocking or deploying the API. By using a variable for the version number, the developer can expose different versions of the API using different base URLs and avoid conflicts or confusion.
References:
https://docs.mulesoft.com/api-designer/design-modify-raml-specs#baseuri
https://docs.mulesoft.com/api-manager/2.x/api-versioning
Mule application A is deployed to CloudHub and is using Object Store v2. Mute application B is also deployed to CloudHub.
Which approach can Mule application B use to remove values from Mule application A’S Object Store?
A.
Object Store v2 REST API
B.
CloudHub Connector
C.
Object Store Connector
D.
CloudHub REST API
Object Store v2 REST API
Explanation
To remove values from Mule application A’s Object Store v2, Mule application B can use Object Store v2 REST API. This API allows performing operations on Object Store v2 resources using HTTP methods, such as GET, POST, PUT, and DELETE. Mule application B can use the DELETE method to remove values from Mule application A’s Object Store v2 by specifying the object store ID and the key of the value to delete.
References: https://docs.mulesoft.com/object-store/osv2-apis
In a Mule project, Flow-1 contains a flow-ref to Flow-2 depends on data from Flow-1 to execute successfully. Which action ensures the test suites and test cases written for Flow-1 and Flow-2 will execute successfully?
A.
Chain together the test suites and test cases for Flow-1 and Flow-2
B.
Use ‘’Set Event to pass the input that is needed, and keep the test cases for Flow-1 and Flow-2 Independent
C.
Use ‘’Before Test Case’’ To collect data from Flow-1 test cases before running Flow-2 test cases
D.
Use ‘After Test Case’ to produce the data needed from Flow-1 test cases to pass to Flow-2 test cases
Use ‘’Set Event to pass the input that is needed, and keep the test cases for Flow-1 and Flow-2 Independent
Explanation
To ensure the test suites and test cases written for Flow-1 and Flow-2 will execute successfully, the developer should use a Set Event processor to pass the input that is needed by Flow-2, and keep the test cases for Flow-1 and Flow-2 independent. This way, the developer can isolate the testing of each flow and avoid coupling them together.
References:
https://docs.mulesoft.com/munit/2.3/munit-test-flow
An order processing system is composed of multiple Mule application responsible for warehouse, sales and shipping. Each application communication usingAnypoint MQ. Each message must be correlated against the original order ID for observability and tracing. How should a developer propagate the order ID as the correlation ID across each message?
A. Use the underlying HTTP request of Anypoint MQ to set the‘X-CORRELATION_ID’ header to the orderID
B. Set a custom Anypoint MQ user propertyto propagate the order ID and set the correlation ID in the receiving applications.
C. Use the default correlation ID, Anypoint MQ will sutomatically propagate it.
D. Wrap all Anypoint MQ Publish operations within a With CorrelationID scope from the Tracing module, setting the correlation ID to the order ID
A scatter-gather router is configured with four routes:Route A, B, C and D.
Route C false.
A.
Error,errorMesage.payload.results [‘2’]
B.
Payload failures[‘2’]
C.
Error,errorMessage,payload.failures[‘2’]
D.
Payload [‘2’]
Error,errorMessage,payload.failures[‘2’]
Explanation:
The result of accessing route C failure is Error,errorMessage,payload.failures[‘2’]. This is because a scatter-gather router returns an aggregated message that contains an array of results from each route and an array of failures from each route. The failures array contains error objects with information about each failed route execution. To access route C failure, which is the third route (index 2), the developer needs to use Error.errorMessage.payload.failures[‘2’] expression.
References:
https://docs.mulesoft.com/mule-runtime/4.3/scatter-gather-reference#scatter-gather-output
| Page 1 out of 6 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved