A Mule application is being designed for deployment to a single CloudHub worker. The Mule application will have a flow that connects to a SaaS system to perform some operations each time the flow is invoked.
The SaaS system connector has operations that can be configured to request a short-lived token (fifteen minutes) that can be reused for subsequent connections within the fifteen minute time window. After the token expires, a new token must be requested and stored.
What is the most performant and idiomatic (used for its intended purpose) Anypoint Platform component or service to use to support persisting and reusing tokens in the Mule application to help speed up reconnecting the Mule application to the SaaS application?
A. Nonpersistent object store
B. Persistent object store
C. Variable
D. Database
Explanation:
Reference: [Reference: https://docs.mulesoft.com/mule-runtime/4.4/reconnection-strategy-about, , ]
A large life sciences customer plans to use the Mule Tracing module with the Mapped Diagnostic Context (MDC) logging operations to enrich logging in its Mule application and to improve tracking by providing more context in the Mule application logs. The customer also wants to improve throughput and lower the message processing latency in its Mule application flows.
After installing the Mule Tracing module in the Mule application, how should logging be performed in flows in Mule applications, and what should be changed In the log4j2.xml files?
A. In the flows, add Mule Tracing module Set logging variable operations before any Core Logger components. In log4j2.xml files, change the appender's pattern layout to use %MDC and then assign the appender to a Logger or Root element.
B. In the flows, add Mule Tracing module Set logging variable operations before any Core Logger components. In log4j2.xmI files, change the appender’s pattern layout to use the %MDC placeholder and then assign the appender to an AsyncLogger element.
C. In the flows, add Mule Tracing module Set logging variable operations before any Core Logger components. In log4j2.xmI files, change the appender’'s pattern layout to use %asyncLogger placeholder and then assign the appender to an AsyncLogger element.
D. In the flows, wrap Logger components in Async scopes. In log4j2.xmI files, change the appender's pattern layout to use the %asyncLogger placeholder and then assign the appender to a Logger or Root element.
Explanation:
Mule Tracing Module and MDC:
Set Logging Variable Operations:
Configuring log4j2.xml:
Improving Throughput and Lowering Latency:
References:
MuleSoft Documentation on Mule Tracing: Mule Tracing Module
Log4j2 Documentation on MDC: Log4j2 MDC
An organization has deployed both Mule and non-Mule API implementations to integrate its customer and order management systems. All the APIs are available to REST clients on the public internet.
The organization wants to monitor these APIs by running health checks: for example, to determine if an API can properly accept and process requests. The organization does not have subscriptions to any external monitoring tools and also does not want to extend its IT footprint.
What Anypoint Platform feature provides the most idiomatic (used for its intended purpose) way to monitor the availability of both the Mule and the non-Mule API implementations?
A. API Functional Monitoring
B. Runtime Manager
C. API Manager
D. Anypoint Visualizer
Explanation:
Reference: [Reference: https://docs.mulesoft.com/visualizer/, , ]
According to MuleSoft, a synchronous invocation of a RESTful API using HTTP to get an individual customer record from a single system is an example of which system integration interaction pattern?
A. Request-Reply
B. Multicast
C. Batch
D. One-way
Explanation:
A synchronous invocation of a RESTful API using HTTP to get an individual customer record from a single system exemplifies the request-reply interaction pattern. In this pattern, a client sends a request to a service and waits for a response. The interaction is synchronous because the client expects an immediate reply and is blocked until it receives the response.
This pattern is common in scenarios where the client needs to retrieve specific data or perform an action that requires immediate feedback from the server, such as retrieving a customer record from a database.
References
MuleSoft Integration Patterns Documentation
Request-Reply Pattern Overview
An organization is creating a set of new services that are critical for their business. The project team prefers using REST for all services but is willing to use SOAP with common WS-" standards if a particular service requires it. What requirement would drive the team to use SOAP/WS-* for a particular service?
A. Must use XML payloads for the service and ensure that it adheres to a specific schema
B. Must publish and share the service specification (including data formats) with the consumers of the service
C. Must support message acknowledgement and retry as part of the protocol
D. Must secure the service, requiring all consumers to submit a valid SAML token
Explanation
Security Assertion Markup Language (SAML) is an open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP).
SAML transactions use Extensible Markup Language (XML) for standardized communications between the identity provider and service providers.
SAML is the link between the authentication of a user’s identity and the authorization to use a service.
WS-Security is the key extension that supports many authentication models including: basic username/password credentials, SAML, OAuth and more.
A common way that SOAP API’s are authenticated is via SAML Single Sign On (SSO). SAML works by facilitating the exchange of authentication and authorization credentials across applications. However, there is no specification that describes how to add SAML to REST web services.
Reference : https://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf
A Mule application is being designed to do the following:
Step 1: Read a SalesOrder message from a JMS queue, where each SalesOrder consists of a header and a list of SalesOrderLineltems.
Step 2: Insert the SalesOrder header and each SalesOrderLineltem into different tables in an RDBMS.
Step 3: Insert the SalesOrder header and the sum of the prices of all its SalesOrderLineltems into a table In a different RDBMS.
No SalesOrder message can be lost and the consistency of all SalesOrder-related information in both RDBMSs must be ensured at all times.
What design choice (including choice of transactions) and order of steps addresses these requirements?
A. 1) Read the JMS message (NOT in an XA transaction)
2) Perform BOTH DB inserts in ONE DB transaction
3) Acknowledge the JMS message
B. 1) Read the JMS message (NOT in an XA transaction)
2) Perform EACH DB insert in a SEPARATE DB transaction
3) Acknowledge the JMS message
C. 1) Read the JMS message in an XA transaction
2) In the SAME XA transaction, perform BOTH DB inserts but do NOT acknowledge the JMS message
D. 1) Read and acknowledge the JMS message (NOT in an XA transaction)
2) In a NEW XA transaction, perform BOTH DB inserts
Explanation
● Option A says "Perform EACH DB insert in a SEPARATE DB transaction". In this case if first DB insert is successful and second one fails then first insert won't be rolled back causing inconsistency. This option is ruled out.
● Option D says Perform BOTH DB inserts in ONE DB transaction.
Rule of thumb is when one or more DB connections are required we must use XA transaction as local transactions support only one resource. So this option is also ruled out.
● Option B acknowledges the before DB processing, so message is removed from the queue. In case of system failure at later point, message can't be retrieved.
● Option C is Valid: Though it says "do not ack JMS message", message will be auto acknowledged at the end of transaction. Here is how we can ensure all components are part of XA transaction: https://docs.mulesoft.com/jms-connector/1.7/jms-transactions
Additional Information about transactions:
● XA Transactions - You can use an XA transaction to group together a series of operations from multiple transactional resources, such as JMS, VM or JDBC resources, into a single, very reliable, global transaction.
● The XA (eXtended Architecture) standard is an X/Open group standard which specifies the interface between a global transaction manager and local transactional resource managers.
The XA protocol defines a 2-phase commit protocol which can be used to more reliably coordinate and sequence a series of "all or nothing" operations across multiple servers, even servers of different types
● Use JMS ack if
– Acknowledgment should occur eventually, perhaps asynchronously
– The performance of the message receipt is paramount
– The message processing is idempotent
– For the choreography portion of the SAGA pattern
● Use JMS transactions
– For all other times in the integration you want to perform an atomic unit of work
– When the unit of work comprises more than the receipt of a single message
– To simply and unify the programming model (begin/commit/rollback)
An organization’s IT team must secure all of the internal APIs within an integration solution by using an API proxy to apply required authentication and authorization policies. Which integration technology, when used for its intended purpose, should the team choose to meet these requirements if all other relevant factors are equal?
A. API Management (APIM)
B. Robotic Process Automation (RPA)
C. Electronic Data Interchange (EDI)
D. Integration Platform-as-a-service (PaaS)
Explanation:
To secure all internal APIs within an integration solution by using an API proxy to apply required authentication and authorization policies, the organization should use API Management (APIM). APIM provides a comprehensive platform to manage, secure, and analyze APIs. It allows the IT team to create API proxies, enforce security policies, control access through authentication and authorization mechanisms, and monitor API usage.
Using APIM for this purpose ensures that internal APIs are protected with standardized security policies, facilitating centralized management and governance of API traffic. This approach is specifically designed for managing APIs and their security, making it the most suitable choice among the options provided.
References
MuleSoft Documentation on API Management
Best Practices for API Security and Governance
How are the API implementation , API client, and API consumer combined to invoke and process an API ?
A. The API consumer creates an API implementation , which receives API invocations from an API such that they are processed for an API client
B. The API consumer creates an API client which sends API invocations to an API such that they are processed by an API implementation
C. An API client creates an API consumer, which receives API invocation from an API such that they are processed for an API implementation
D. The API client creates an API consumer which sends API invocations to an API such that they are processed by API implementation
Explanation
The API consumer creates an API client which sends API invocations to an API such that they are processed by an API implementation
This is based on below definitions API client • An application component • that accesses a service • by invoking an API of that service - by definition of the term API over HTTP API consumer • A business role, which is often assigned to an individual • that develops API clients, i.e., performs the activities necessary for enabling an API client to invoke APIs API implementation • An application component • that implements the functionality
An insurance company is implementing a MuleSoft API to get inventory details from the two vendors. Due to network issues, the invocations to vendor applications are getting timed-out intermittently. But the transactions are successful upon reprocessing What is the most performant way of implementing this requirement?
A. Implement a scatter-gather scope to invoke the two vendor
applications on two different route
Use the Until-Successful scope to implement the retry mechanism
for timeout errors on each route
B. Implement a Choice scope to invoke the two vendor applications on two different route
Use the try-catch scope to implement the retry mechanism for timeout errors on each route
C. Implement a For-Each scope to invoke the two vendor applications
Use until successful scope to implement the retry mechanism for the timeout errors
D. Implement Round-Robin scope to invoke the two vendor applications on two different routes
Use the Try-Catch scope to implement retry mechanism for timeout errors on each route
Explanation:
The most performant way to handle intermittent network issues with vendor applications and ensure successful transaction reprocessing is to use a combination of the Scatter-Gather scope and the Until-Successful scope. Here’s how it works:
Scatter-Gather Scope: This scope allows you to send requests to multiple endpoints (in this case, the two vendor applications) simultaneously. This ensures that both vendors are queried at the same time, reducing overall processing time.
Until-Successful Scope: This scope is used to implement a retry mechanism. By wrapping each route to the vendor applications with an Until-Successful scope, the flow can automatically retry the request if a timeout error occurs. This scope retries the request until it succeeds or until a specified number of retries is reached.
Implementation Steps:
Configure a Scatter-Gather scope in your Mule application.
Inside each route of the Scatter-Gather scope, place an Until-Successful scope.
Configure the Until-Successful scope with appropriate retry policies, such as retry count and delay between retries.
Inside the Until-Successful scope, configure the HTTP request to the vendor application.
This approach ensures that:
Both vendor applications are queried in parallel.
Each request is retried upon timeout errors, ensuring eventual success without manual
intervention.
References:
MuleSoft Documentation: Scatter-Gather
MuleSoft Documentation: Until-Successful Scope
When designing an upstream API and its implementation, the development team has been advised to not set timeouts when invoking downstream API. Because the downstream API has no SLA that can be relied upon. This is the only donwstream API dependency of that upstream API. Assume the downstream API runs uninterrupted without crashing. What is the impact of this advice?
A. The invocation of the downstream API will run to completion without timing out.
B. An SLA for the upstream API CANNOT be provided
C. A default timeout of 500 ms will automatically be applied by the Mule runtime in which the upstream API implementation executes.
D. A load-dependent timeout of less than 1000 ms will be applied by the Mule runtime in which the downstream API implementation executes.
| Page 11 out of 27 Pages |
| Previous |
Copyright © - All Rights Reserved