A company wants to move its Mule API implementations into production as quickly as
possible. To protect access to all Mule application data and metadata, the company
requires that all Mule applications be deployed to the company's customer-hosted
infrastructure within the corporate firewall. What combination of runtime plane and control
plane options meets these project lifecycle goals?
A.
Manually provisioned customer-hosted runtime plane and customer-hosted control plane
B.
MuleSoft-hosted runtime plane and customer-hosted control plane
C.
Manually provisioned customer-hosted runtime plane and MuleSoft-hosted control plane
D.
iPaaS provisioned customer-hosted runtime plane and MuleSoft-hosted control plane
Manually provisioned customer-hosted runtime plane and customer-hosted control plane
Explanation:
Explanation
Correct Answer: Manually provisioned customer-hosted runtime plane and customerhosted
control plane
*****************************************
There are two key factors that are to be taken into consideration from the scenario given in
the question.
>> Company requires both data and metadata to be resided within the corporate firewall
>> Company would like to go with customer-hosted infrastructure.
Any deployment model that is to deal with the cloud directly or indirectly (Mulesoft-hosted
or Customer's own cloud like Azure, AWS) will have to share atleast the metadata.
Application data can be controlled inside firewall by having Mule Runtimes on customer
hosted runtime plane. But if we go with Mulsoft-hosted/ Cloud-based control plane, the
control plane required atleast some minimum level of metadata to be sent outside the
corporate firewall.
As the customer requirement is pretty clear about the data and metadata both to be within
the corporate firewall, even though customer wants to move to production as quickly as
possible, unfortunately due to the nature of their security requirements, they have no other
option but to go with manually provisioned customer-hosted runtime plane and customerhosted
control plane.
4A developer for a transportation organization is implementing exactly one processing
functionality in a Reservation Mule application to process and store passenger
records. This Reservation application will be deployed to multiple CloudHub
workers/replicas. It is possible that several external systems could send duplicate
passenger records
to the Reservation application.
An appropriate storage mechanism must be selected to help the Reservation application
process each passenger record exactly once as much as possible. The selected storage
mechanism must be shared by all the CloudHub workers/replicas in order to synchronize
the state information to assist attempting exactly once processing of each passenger
record by the deployed Reservation Mule application.
Which type of simple storage mechanism in Anypoint Platform allows the Reservation Mule
application to update and share data between the CloudHub workers/replicas exactly
once, with minimal development effort?
A. Persistent Object Store
B. Runtime Fabric Object Store
C. Non-persistent Object Store
D. In-memory Mule Object Store
What correctly characterizes unit tests of Mule applications?
A.
They test the validity of input and output of source and target systems
B.
They must be run in a unit testing environment with dedicated Mule runtimes for the environment
C.
They must be triggered by an external client tool or event source
D.
They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity
They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity
Explanation: Explanation
Correct Answer: They are typically written using MUnit to run in an embedded Mule runtime
that does not require external connectivity.
*****************************************
Below TWO are characteristics of Integration Tests but NOT unit tests:
>> They test the validity of input and output of source and target systems.
>> They must be triggered by an external client tool or event source.
It is NOT TRUE that Unit Tests must be run in a unit testing environment with dedicated
Mule runtimes for the environment.
MuleSoft offers MUnit for writing Unit Tests and they run in an embedded Mule Runtime
without needing any separate/ dedicated Runtimes to execute them. They also do NOT
need any external connectivity as MUnit supports mocking via stubs.
https://dzone.com/articles/munit-framework
An API implementation is deployed on a single worker on CloudHub and invoked by
external API clients (outside of CloudHub). How can an alert be set up that is guaranteed to
trigger AS SOON AS that API implementation stops responding to API invocations?
A.
Implement a heartbeat/health check within the API and invoke it from outside the Anypoint Platform and alert when the heartbeat does not respond
B.
Configure a "worker not responding" alert in Anypoint Runtime Manager
C.
Handle API invocation exceptions within the calling API client and raise an alert from that API client when the API Is unavailable
D.
Create an alert for when the API receives no requests within a specified time period
Configure a "worker not responding" alert in Anypoint Runtime Manager
Explanation: Explanation
Correct Answer: Configure a “Worker not responding” alert in Anypoint Runtime Manager.
*****************************************
>> All the options eventually helps to generate the alert required when the application stops
responding.
>> However, handling exceptions within calling API and then raising alert from API client is
inappropriate and silly. There could be many API clients invoking the API implementation
and it is not ideal to have this setup consistently in all of them. Not a realistic way to do.
>> Implementing a health check/ heartbeat with in the API and calling from outside to
detmine the health sounds OK but needs extra setup for it and same time there are very
good chances of generating false alarms when there are any intermittent network issues
between external tool calling the health check API on API implementation. The API
implementation itself may not have any issues but due to some other factors some false
alarms may go out.
>> Creating an alert in API Manager when the API receives no requests within a specified
time period would actually generate realistic alerts but even here some false alarms may
go out when there are genuinely no requests from API clients.
The best and right way to achieve this requirement is to setup an alert on Runtime
Manager with a condition "Worker not responding". This would generate an alert
AS SOON AS the workers become unresponsive.
A customer wants to host their MuleSoft applications in CloudHub 1.0, and these
applications should be available at the domain https://api.acmecorp.com.
After creating a dedicated load balancer (DLB) called acme-dib-prod, which further action
must the customer take to complete the configuration?
A. Configure the DLB with a TLS certificate for api.acmecorp.com and create an A record for api.acmecorp.com to the public IP addresses associated with their DLB
B. Configure the DLB with a TLS certificate for api.acmecorp.com and create a CNAME record from api.acmecorp.com to acme-dib-prod.|lb.anypointdns.net
C. Configure the DLB with a TLS certificate for acme-dib-prod.Jb.anypointdns.net and create a CNAME record from api.acmecorp:com to acme-dlb-prod.lb.anypointdns.net
D. Configure the DLB with a TLS certificate for aplacmecorp.com and create a CNAME record from api.aomecorp.com to acme-dib-prod.ei.cloubhub.io
Explanation:
When setting up a custom domain for MuleSoft applications hosted on
CloudHub 1.0 using a Dedicated Load Balancer (DLB), follow these steps:
Set Up the TLS Certificate: Configure the DLB (acme-dib-prod) with a TLS
certificate that covers the custom domain api.acmecorp.com. This certificate will
allow HTTPS traffic to be securely directed through the DLB to your Mule
applications.
A Platinum customer uses the U.S. control plane and deploys applications to CloudHub in Singapore with a default log configuration. The compliance officer asks where the logs and monitoring data reside?
A. Logs are held in: Singapore and monitoring data is held in the United States
B. Logs and monitoring data are held in the United States
C. Logs are held in the United States and monitoring data is held in Singapore
D. Logs and monitoring data are held in Singapore
Explanation:
For applications deployed on CloudHub in a foreign region (e.g., Singapore),
MuleSoft handles log and monitoring data in the region where the control plane
resides. This data storage policy is standard for CloudHub deployments to maintain
centralized log and monitoring data.
When could the API data model of a System API reasonably mimic the data model
exposed by the corresponding backend system, with minimal improvements over the
backend system's data model?
A.
When there is an existing Enterprise Data Model widely used across the organization
B.
When the System API can be assigned to a bounded context with a corresponding data
model
C.
When a pragmatic approach with only limited isolation from the backend system is deemed appropriate
D.
When the corresponding backend system is expected to be replaced in the near future
When a pragmatic approach with only limited isolation from the backend system is deemed appropriate
Explanation: Explanation
Correct Answer: When a pragmatic approach with only limited isolation from the backend
system is deemed appropriate.
*****************************************
General guidance w.r.t choosing Data Models:
>> If an Enterprise Data Model is in use then the API data model of System APIs should
make use of data types from that Enterprise Data Model and the corresponding API
implementation should translate between these data types from the Enterprise Data Model
and the native data model of the backend system.
>> If no Enterprise Data Model is in use then each System API should be assigned to a
Bounded Context, the API data model of System APIs should make use of data types from
the corresponding Bounded Context Data Model and the corresponding API
implementation should translate between these data types from the Bounded Context Data
Model and the native data model of the backend system. In this scenario, the data types in
the Bounded Context Data Model are defined purely in terms of their business
characteristics and are typically not related to the native data model of the backend system.
In other words, the translation effort may be significant.
>> If no Enterprise Data Model is in use, and the definition of a clean Bounded Context
Data Model is considered too much effort, then the API data model of System APIs should
make use of data types that approximately mirror those from the backend system, same
semantics and naming as backend system, lightly sanitized, expose all fields needed for
the given System API’s functionality, but not significantly more and making good use of
REST conventions.
The latter approach, i.e., exposing in System APIs an API data model that basically mirrors
that of the backend system, does not provide satisfactory isolation from backend systems
through the System API tier on its own. In particular, it will typically not be possible to
"swap out" a backend system without significantly changing all System APIs in front of that
backend system and therefore the API implementations of all Process APIs that depend on
those System APIs! This is so because it is not desirable to prolong the life of a previous
backend system’s data model in the form of the API data model of System APIs that now
front a new backend system. The API data models of System APIs following this approach
must therefore change when the backend system is replaced.
On the other hand:
>> It is a very pragmatic approach that adds comparatively little overhead over accessing
the backend system directly
>> Isolates API clients from intricacies of the backend system outside the data model
(protocol, authentication, connection pooling, network address, …)
>> Allows the usual API policies to be applied to System APIs
>> Makes the API data model for interacting with the backend system explicit and visible,
by exposing it in the RAML definitions of the System APIs
>> Further isolation from the backend system data model does occur in the API
What is typically NOT a function of the APIs created within the framework called API-led connectivity?
A.
They provide an additional layer of resilience on top of the underlying backend system,
thereby insulating clients from extended failure of these systems.
B.
They allow for innovation at the user Interface level by consuming the underlying assets
without being aware of how data Is being extracted from backend systems.
C.
They reduce the dependency on the underlying backend systems by helping unlock data
from backend systems In a reusable and consumable way.
D.
They can compose data from various sources and combine them with orchestration logic to create higher level value.
They provide an additional layer of resilience on top of the underlying backend system,
thereby insulating clients from extended failure of these systems.
Explanation: Explanation
Correct Answer: They provide an additional layer of resilience on top of the underlying
backend system, thereby insulating clients from extended failure of these systems.
*****************************************
In API-led connectivity,
>> Experience APIs - allow for innovation at the user interface level by consuming the
underlying assets without being aware of how data is being extracted from backend
systems.
>> Process APIs - compose data from various sources and combine them with
orchestration logic to create higher level value
>> System APIs - reduce the dependency on the underlying backend systems by helping
unlock data from backend systems in a reusable and consumable way.
However, they NEVER promise that they provide an additional layer of resilience on top of
the underlying backend system, thereby insulating clients from extended failure of these
systems.
https://dzone.com/articles/api-led-connectivity-with-mule
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved