An organization has various integrations implemented as Mule applications. Some of these Mule applications are deployed to custom hosted Mule runtimes (on-premises) while others execute in the MuleSoft-hosted runtime plane (CloudHub). To perform the Integra functionality, these Mule applications connect to various backend systems, with multiple applications typically needing to access the backend systems.
How can the organization most effectively avoid creating duplicates in each Mule application of the credentials required to access the backend systems?
A. Create a Mule domain project that maintains the credentials as Mule domain-shared resources Deploy the Mule applications to the Mule domain, so the credentials are available to the Mule applications
B. Store the credentials in properties files in a shared folder within the organization's data center Have the Mule applications load properties files from this shared location at startup
C. Segregate the credentials for each backend system into environment-specific properties files Package these properties files in each Mule application, from where they are loaded at startup
D. Configure or create a credentials service that returns the credentials for each backend system, and that is accessible from customer-hosted and MuleSoft-hosted Mule runtimes Have the Mule applications toad the properties at startup by invoking that credentials service
Explanation
* "Create a Mule domain project that maintains the credentials as Mule domain-shared resources" is wrong as domain project is not supported in Cloudhub * We should Avoid Creating duplicates in each Mule application but below two options cause duplication of credentials - Store the credentials in properties files in a shared folder within the organization’s data center. Have the Mule applications load properties files from this shared location at startup - Segregate the credentials for each backend system into environment-specific properties files. Package these properties files in each Mule application, from where they are loaded at startup So these are also wrong choices * Credentials service is the best approach in this scenario. Mule domain projects are not supported on CloudHub. Also its is not recommended to have multiple copies of configuration values as this makes difficult to maintain Use the Mule Credentials Vault to encrypt data in a .properties file. (In the context of this document, we refer to the .properties file simply as the properties file.) The properties file in Mule stores data as key-value pairs which may contain information such as usernames, first and last names, and credit card numbers. A Mule application may access this data as it processes messages, for example, to acquire login credentials for an external Web service. However, though this sensitive, private data must be stored in a properties file for Mule to access, it must also be protected against unauthorized – and potentially malicious – use by anyone with access to the Mule application
A company is implementing a new Mule application that supports a set of critical functions driven by a rest API enabled, claims payment rules engine hosted on oracle ERP. As designed the mule application requires many data transformation operations as it performs its batch processing logic.
The company wants to leverage and reuse as many of its existing java-based capabilities (classes, objects, data model etc.) as possible
What approach should be considered when implementing required data mappings and transformations between Mule application and Oracle ERP in the new Mule application?
A. Create a new metadata RAML classes in Mule from the appropriate Java objects and then perform transformations via Dataweave
B. From the mule application, transform via theXSLT model
C. Transform by calling any suitable Java class from Dataweave
D. Invoke any of the appropriate Java methods directly, create metadata RAML classes and then perform required transformations via Dataweave
Which key DevOps practice and associated Anypoint Platform component should a MuteSoft integration team adopt to improve delivery quality?
A. A Continuous design with API Designer
B. Automated testing with MUnit
C. Passive monitoring with Anypoint Monitoring
D. Manual testing with Anypoint Studio
An Organization has previously provisioned its own AWS VPC hosting various servers. The organization now needs to use Cloudhub to host a Mule application that will implement a REST API once deployed to Cloudhub, this Mule application must be able to communicate securely with the customer-provisioned AWS VPC resources within the same region, without being interceptable on the public internet.
What Anypoint Platform features should be used to meet these network communication requirements between Cloudhub and the existing customer-provisioned AWS VPC?
A. Add a Mulesoft hosted Anypoint VPC configured and with VPC Peering to the AWS VPC
B. Configure an external identity provider (IDP) in Anypoint Platform with certificates from the customer provisioned AWS VPC
C. Add a default API Whitelisting policy to API Manager to automatically whitelist the customer provisioned AWS VPC IP ranges needed by the Mule applicaton
D. Use VM queues in the Mule application to allow any non-mule assets within the customer provisioned AWS VPC to subscribed to and receive messages
Explanation:
Correct answer is: Add a Mulesoft hosted Anypoint VPC configured and with VPC Peering to the AWS VPC * Connecting to your Anypoint VPC extends your corporate network and allows CloudHub workers to access resources behind your corporate firewall.
* You can connect on-premises data centers through a secured VPN tunnel, or a private AWS VPC through VPC peering, or by using AWS Direct Connect.
MuleSoft Doc Reference :
https://docs.mulesoft.com/runtime-manager/virtual-private-cloud
An organization's IT team follows an API-led connectivity approach and must use Anypoint Platform to implement a System AP\ that securely accesses customer data. The organization uses Salesforce as the system of record for all customer data, and its most important objective is to reduce the overall development time to release the System API.
The team's integration architect has identified four different approaches to access the customer data from within the implementation of the System API by using different Anypoint Connectors that all meet the technical requirements of the project.
A. Use the Anypoint Connector for Database to connect to a MySQL database to access a copy of the customer data
B. Use the Anypoint Connector for HTTP to connect to the Salesforce APIs to directly access the customer data
C. Use the Anypoint Connector for Salesforce to connect to the Salesforce APIs to directly access the customer data
D. Use the Anypoint Connector tor FTP to download a file containing a recent near-real time extract of the customer data
Explanation:
To reduce the overall development time to release the System API, the most efficient approach is to use the Anypoint Connector for Salesforce. This connector is specifically designed to interact with Salesforce APIs, providing a seamless and optimized way to access customer data directly from Salesforce. Using this connector simplifies development, reduces complexity, and leverages built-in capabilities for authentication and data retrieval, ensuring a faster and more secure implementation.
References:
Anypoint Connector for Salesforce
Connecting to Salesforce with Anypoint Platform
An organization is sizing an Anypoint VPC to extend their internal network to Cloudhub. For this sizing calculation, the organization assumes 150 Mule applications will be deployed among three(3) production environments and will use Cloudhub’s default zero-downtime feature. Each Mule application is expected to be configured with two(2) Cloudhub workers.This is expected to result in several Mule application deployments per hour.
A. 10.0.0.0/21(2048 IPs)
B. 10.0.0.0/22(1024IPs)
C. 10.0.0.0/23(512 IPs)
D. 10.0.0.0/24(256 IPs)
Explanation
* When you create an Anypoint VPC, the range of IP addresses for the network must be specified in the form of a Classless Inter-Domain Routing (CIDR) block, using CIDR notation.
* This address space is reserved for Mule workers, so it cannot overlap with any address space used in your data center if you want to peer it with your VPC.
* To calculate the proper sizing for your Anypoint VPC, you first need to understand that the number of dedicated IP addresses is not the same as the number of workers you have deployed.
* For each worker deployed to CloudHub, the following IP assignation takes place: For better fault tolerance, the VPC subnet may be divided into up to four Availability Zones.
* A few IP addresses are reserved for infrastructure. At least two IP addresses per worker to perform at zero-downtime.
* Hence in this scenario 2048 IP's are required to support the requirement.
According to MuleSoft, what is a major distinguishing characteristic of an application network in relation to the integration of systems, data, and devices?
A. It uses a well-organized monolithic approach with standards
B. It is built for change and self-service
C. It leverages well-accepted internet standards like HTTP and JSON
D. It uses CI/CD automation for real-time project delivery
Explanation:
A major distinguishing characteristic of an application network, according to MuleSoft, is that it is built for change and self-service. An application network connects applications, data, and devices with APIs, enabling self-service access and reuse of assets. This architecture allows organizations to rapidly adapt to changing business needs, fosters innovation, and reduces time to market by empowering different teams to access and integrate systems independently without waiting for centralized IT.
References:
Application Networks: The Future of Integration
MuleSoft's Approach to Building Application Networks
An auto mobile company want to share inventory updates with dealers Dl and D2 asynchronously and concurrently via queues Q1 and Q2. Dealer Dl must consume the message from the queue Q1 and dealer D2 to must consume a message from the queue Q2.
Dealer D1 has implemented a retry mechanism to reprocess the transaction in case of any errors while processing the inventers updates. Dealer D2 has not implemented any retry mechanism.
How should the dealers acknowledge the message to avoid message loss and minimize impact on the current implementation?
A. Dealer D1 must use auto acknowledgement and dealer D2 can use manual acknowledgement and acknowledge the message after successful processing
B. Dealer D1 can use auto acknowledgement and dealer D2 can use IMMEDIATE acknowledgement and acknowledge the message of successful processing
C. Dealer D1 and dealer D2 must use AUTO acknowledgement and acknowledge the message after successful processing
D. Dealer D1 can use AUTO acknowledgement and dealer D2 must use manual acknowledgement and acknowledge the message after successful processing
Explanation:
• Dealer D1 - AUTO Acknowledgment:
• Dealer D2 - Manual Acknowledgment:
• Ensuring Message Delivery:
References:
• MuleSoft Documentation on JMS Acknowledgment
• Best practices for Reliable Messaging
Page 1 out of 5 Pages |