A REST API is being designed to implement a Mule application.
What standard interface definition language can be used to define REST APIs?
A.
Web Service Definition Language(WSDL)
B.
OpenAPI Specification (OAS)
C.
YAML
D.
AsyncAPI Specification
OpenAPI Specification (OAS)
A new upstream API Is being designed to offer an SLA of 500 ms median and 800 ms
maximum (99th percentile) response time. The corresponding API implementation needs to
sequentially invoke 3 downstream APIs of very similar complexity.
The first of these downstream APIs offers the following SLA for its response time: median:
100 ms, 80th percentile: 500 ms, 95th percentile: 1000 ms.
If possible, how can a timeout be set in the upstream API for the invocation of the first
downstream API to meet the new upstream API's desired SLA?
A.
Set a timeout of 50 ms; this times out more invocations of that API but gives additional
room for retries
B.
Set a timeout of 100 ms; that leaves 400 ms for the other two downstream APIs to complete
C.
No timeout is possible to meet the upstream API's desired SLA; a different SLA must be
negotiated with the first downstream API or invoke an alternative API
D.
Do not set a timeout; the Invocation of this API Is mandatory and so we must wait until it
responds
Set a timeout of 100 ms; that leaves 400 ms for the other two downstream APIs to complete
Explanation:
Explanation
Correct Answer: Set a timeout of 100ms; that leaves 400ms for other two downstream APIs
to complete
*****************************************
Key details to take from the given scenario:
>> Upstream API's designed SLA is 500ms (median). Lets ignore maximum SLA response
times.
>> This API calls 3 downstream APIs sequentially and all these are of similar complexity.
>> The first downstream API is offering median SLA of 100ms, 80th percentile: 500ms;
95th percentile: 1000ms.
Based on the above details:
>> We can rule out the option which is suggesting to set 50ms timeout. Because, if the
median SLA itself being offered is 100ms then most of the calls are going to timeout and
time gets wasted in retried them and eventually gets exhausted with all retries. Even if
some retries gets successful, the remaining time wont leave enough room for 2nd and 3rd
downstream APIs to respond within time.
>> The option suggesting to NOT set a timeout as the invocation of this API is mandatory
and so we must wait until it responds is silly. As not setting time out would go against the
good implementation pattern and moreover if the first API is not responding within its
offered median SLA 100ms then most probably it would either respond in 500ms (80th
percentile) or 1000ms (95th percentile). In BOTH cases, getting a successful response
from 1st downstream API does NO GOOD because already by this time the Upstream API
SLA of 500 ms is breached. There is no time left to call 2nd and 3rd downstream APIs.
>> It is NOT true that no timeout is possible to meet the upstream APIs desired SLA.
As 1st downstream API is offering its median SLA of 100ms, it means MOST of the time we
would get the responses within that time. So, setting a timeout of 100ms would be ideal for
MOST calls as it leaves enough room of 400ms for remaining 2 downstream API calls.
A code-centric API documentation environment should allow API consumers to investigate and execute API client source code that demonstrates invoking one or more APIs as part of representative scenarios. What is the most effective way to provide this type of code-centric API documentation environment using Anypoint Platform?
A. Enable mocking services for each of the relevant APIs and expose them via their Anypoint Exchange entry
B. Ensure the APIs are well documented through their Anypoint Exchange entries and API Consoles and share these pages with all API consumers
C. Create API Notebooks and include them in the relevant Anypoint Exchange entries
D. Make relevant APIs discoverable via an Anypoint Exchange entry
Explanation: Explanation
Correct Answer: Create API Notebooks and Include them in the relevant Anypoint
exchange entries
*****************************************
>> API Notebooks are the one on Anypoint Platform that enable us to provide code-centric
API documentation
: https://docs.mulesoft.com/exchange/to-use-api-notebook
Bottom of Form
Top of Form
An auto manufacturer has a mature CI/CD practice and wants to automate packaging and deployment of any Mule applications to various deployment targets, including CloudHub workers/replicas, customer-hosted Mule runtimes, and Anypoint Runtime Fabric. Which MuleSoft-provided tool or component facilitates automating the packaging and deployment of Mule applications to various deployment targets as part of the company's CI/CD practice?
A. Anypoint Runtime Manager
B. Mule Maven plugin
C. Anypoint Platform CLI
D. Anypoint Platform REST APIs
Explanation:
For organizations with established CI/CD practices, the Mule Maven plugin
is the recommended tool for automating packaging and deployment across multiple
environments, including CloudHub, on-premise Mule runtimes, and Anypoint Runtime
Fabric. Here’s why:
A client has several applications running on the Salesforce service cloud. The business requirement for integration is to get daily data changes from Account and Case Objects. Data needs to be moved to the client's private cloud AWS DynamoDB instance as a single JSON and the business foresees only wanting five attributes from the Account object, which has 219 attributes (some custom) and eight attributes from the Case Object. What design should be used to support the API/ Application data model?
A. Create separate entities for Account and Case Objects by mimicking all the attributes in SAPI, which are combined by the PAPI and filtered to provide JSON output containing 13 attributes.
B. Request client’s AWS project team to replicate all the attributes and create Account and Case JSON table in DynamoDB. Then create separate entities for Account and Case Objects by mimicking all the attributes in SAPI to transfer ISON data to DynamoD for respective Objects
C. Start implementing an Enterprise Data Model by defining enterprise Account and Case Objects and implement SAPI and DynamoDB tables based on the Enterprise Data Model,
D. Create separate entities for Account with five attributes and Case with eight attributes in SAPI, which are combined by the PAPI to provide JSON output containing 13 attributes.
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
An established communications company is beginning its API-led connectivity journey, The
company has been using a successful Enterprise Data Model for many years. The company has identified a self-service account management app as the first effort for APIled,
and it has identified the following APIs.
A. Customer SAPI
B. Customer Lookup PAPI
C. Mobile Account Management EAPI
D. Service SAPI
Explanation: In the API-led connectivity approach, APIs are categorized into Experience,
Process, and System layers:
Enterprise Data Model Scope:
Why Option C is Correct:
Explanation of Incorrect Options:
References:
For additional guidance, review MuleSoft's best practices on API-led
connectivity and data modeling.
4 Production environment is running on a dedicated Virtual Private Cloud (VPC) on CloudHub 1,0, and the security team guidelines clearly state no traffic on HTTP. Which two options support these security guidelines?
A. Option A
B. Option B
C. Option C
D. Option D
E. Option E
| Page 1 out of 19 Pages |
Contact Us - Privacy Policy ... Copyright © - All Rights Reserved