An organization uses CloudHub to deploy all of its applications. How can a common-global-handler flow be configured so that it can be reused across all of the organization’s deployed applications?
A.
Create a Mule plugin project
Create a common-global-error-handler flow inside the plugin project.
Use this plugin as a dependency in all Mute applications.
Import that configuration file in Mute applications.
B.
Create a common-global-error-handler flow in all Mule Applications Refer to it flow-ref wherever needed.
C.
Create a Mule Plugin project
Create a common-global-error-handler flow inside the plugin project.
Use this plugin as a dependency in all Mule applications
D.
Create a Mule daman project.
Create a common-global-error-handler flow inside the domain project.
Use this domain project as a dependency.
Create a Mule Plugin project
Create a common-global-error-handler flow inside the plugin project.
Use this plugin as a dependency in all Mule applications
Explanation:
To configure a common-global-handler flow that can be reused across all of the organization’s deployed applications, the developer should create a Mule Plugin project, create a common-global-error-handler flow inside the plugin project, and use this plugin as a dependency in all Mule applications. This way, the developer can import the common-global-error-handler flow in any application that needs it and avoid duplicating the error handling logic.
References:
https://docs.mulesoft.com/mule-runtime/4.3/error-handling#global-error-handler
A mule application exposes and API for creating payments. An Operations team wants to ensure that the Payment API is up and running at all times in production. Which approach should be used to test that the payment API is working in production?
A.
Create a health check endpoint that listens on a separate port and uses a separate HTTP Listener configuration from the API
B.
Configure the application to send health data to an external system
C.
Create a health check endpoint that reuses the same port number and HTTP Listener configuration as the API itself
D.
Monitor the Payment API directly sending real customer payment data
Create a health check endpoint that listens on a separate port and uses a separate HTTP Listener configuration from the API
Explanation:
To test that the payment API is working in production, the developer should create a health check endpoint that listens on a separate port and uses a separate HTTP Listener configuration from the API. This way, the developer can isolate the health check endpoint from the API traffic and avoid affecting the performance or availability of the API. The health check endpoint should return a simple response that indicates the status of the API, such as OK or ERROR.
References:
https://docs.mulesoft.com/api-functional-monitoring/afm-create-monitor#create-a-monitor
An API has been developed and deployed to CloudHub Among the policies applied to this API is an allowlist of IP addresses. A developer wants to run a test in Anypoint Studio and does not want any policies applied because their workstation is not included in the allowlist. What must the developer do in order to run this test locally without the policies applied?
A.
Create a properties file specifically for local development and set the API instance ID to a value that is not used in API Manager
B.
Pass in the runtime parameter ‘’-Danpow.platform.gatekeeper=disabled’’
C.
Deactivate the API in API Manager so the Autodiscovery element will not find the application when it runs in Studio
D.
Run the test as-s, with no changes because the Studio runtime will not attempt to connect to API Manager
Create a properties file specifically for local development and set the API instance ID to a value that is not used in API Manager
To run a test locally without the policies applied, the developer should create a properties file specifically for local development and set the API instance ID to a value that is not used in API Manager. This way, the developer can use different configuration properties for different environments and avoid triggering API autodiscovery when running tests locally. API autodiscovery is a mechanism that associates an API implementation with its corresponding API specification and policies in API Manager based on its API instance ID. By setting this ID to a value that does not exist in API Manager, the developer can prevent API autodiscovery from finding and applying any policies to the local test.
References:
https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept#configuring-api-autodiscovery
https://docs.mulesoft.com/mule-runtime/4.3/configuring-properties
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
A Flight Management System publishes gate change notification events whenever a flight’s arrival gate changes. Other systems, including Baggage Handler System. Inflight Catering System and Passenger Notifications System, must each asynchronously receive the same gate change notification to process the event according. Which configuration is required in Anypoint MQ to achieve this publish/subscribe model?
A.
Publish each client subscribe directly to the exchange.
Have each client subscribe directly to the queue.
B.
Publish the gate change notification to an Anypoint MC queue
Have each client subscribe directly to the queue
C.
Publish the gate change notification to an Anypoint MQ queue.
Create different anypoint MQ exchange meant for each of the other subscribing systems
Bind the queue with each of the exchanges
D.
Publish the gate change notification to an Anypoint MQ exchanhe.
Create different Anypoint MQ queues meant for each of the other subscribing systems.
Bind the exchange with each of the queues.
Publish the gate change notification to an Anypoint MQ exchanhe.
Create different Anypoint MQ queues meant for each of the other subscribing systems.
Bind the exchange with each of the queues.
Explanation:
To achieve a publish/subscribe model using Anypoint MQ, where each system receives the same gate change notification event, the developer should publish the gate change notification to an Anypoint MQ exchange, create different Anypoint MQ queues meant for each of the other subscribing systems, and bind the exchange with each of the queues. An exchange is a message routing agent that can send messages to different queues based on predefined criteria. By binding an exchange with multiple queues, each queue receives a copy of every message sent to that exchange. Therefore, each system can subscribe to its own queue and receive every gate change notification event.
References:
https://docs.mulesoft.com/anypoint-mq/3.x/anypoint-mq-exchanges
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
Which type of cache invalidation does the Cache scope support without having to write any additional code?
A.
Write-through invalidation
B.
White-behind invalidation
C.
Time to live
D.
Notification-based invalidation
Time to live
The Cache scope supports time to live (TTL) as a cache invalidation strategy without having to write any additional code. TTL specifies how long the cached response is valid before it expires and needs to be refreshed. The Cache scope also supports custom invalidation strategies using MEL or DataWeave expressions.
References: https://docs.mulesoft.com/mule-runtime/4.3/cache-scope#cache_invalidation
A new Mule project has been created in Anypoint Studio with the default settings.
Which file inside the Mule project must be modified before using Maven to successfully deploy the application?
A.
Settings.xml
B.
Config.yaml
C.
Pom.xml
D.
Mule.artificact.json
Pom.xml
Explanation
To use Maven to successfully deploy the application, the developer needs to modify the pom.xml file inside the Mule project. The pom.xml file contains the configuration and dependencies of the Mule application, as well as the deployment information such as the CloudHub region, environment, and worker size. The developer needs to specify these properties in the pom.xml file before using Maven to deploy the application.
References:
https://docs.mulesoft.com/mule-runtime/4.3/mmp-concept#application-deployment-descriptor
| Page 1 out of 6 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved