Deal of The Day! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

Salesforce Exam MuleSoft Platform Architect I Topic 1 Question 23 Discussion

Actual exam question for Salesforce's MuleSoft Platform Architect I exam
Question #: 23
Topic #: 1
[All MuleSoft Platform Architect I Questions]

A company stores financial transaction data in two legacy systems. For each legacy system, a separate, dedicated System API (SAPI) exposes data for that legacy system. A Process API (PAPI) merges the data retrieved from ail of the System APIs into a common format. Several API clients call the PAPI through its public domain name.

The company now wants to expose a subset of financial data to a newly developed mobile application that uses a different Bounded Context Data Model. The company wants to follow MuleSoft's best practices for building out an effective application network.

Following MuleSoft's best practices, how can the company expose financial data needed by the mobile application in a way that minimizes the impact on the currently running API clients, API implementations, and support asset reuse?

Show Suggested Answer Hide Answer
Suggested Answer: A

To achieve the goal of exposing financial data to a new mobile application while following MuleSoft's best practices, the company should follow an API-led connectivity approach. This approach ensures minimal disruption to existing clients, maximizes reusability, and respects the separation of concerns across API layers.

of Solution:

Experience APIs for Client-Specific Requirements:

Create two new Experience APIs (EAPI-1 and EAPI-2) for the mobile application, tailored to meet the specific data and format requirements of the mobile application. These APIs encapsulate the client-specific needs and provide a custom interface without impacting other clients.

Process API Layer for Data Transformation:

By adding Mobile PAPI-2, we allow the mobile application to access the required subset of data, formatted according to the mobile application's requirements. This approach ensures that data transformation and aggregation are handled in the Process layer, maintaining consistency and reusability across different applications.

Reuse of System APIs:

Both the new Mobile PAPI-2 and existing PAPI-1 access data from System APIs (SAPI-1 and SAPI-2), which continue to expose data from each legacy system in a consistent, reusable manner. This avoids duplicating logic and ensures that data access remains centralized and manageable.

Why Option A is Correct:

Option A aligns with MuleSoft's best practices by isolating client-specific requirements in the Experience layer, utilizing Process APIs for data orchestration and transformation, and maintaining reusable System APIs for backend access.

This approach also ensures that the current API clients are not impacted, as new clients (e.g., the mobile app) interact with newly defined Experience APIs without modifying the existing API setup.

of Incorrect Options:

Option B: This option seems similar but lacks clarity on the separation of mobile-specific requirements and does not explicitly mention data transformation, which is essential in this scenario.

Option C: Creating a single mobile Experience API that exposes a subset of PAPI endpoints directly adds unnecessary complexity and may violate the separation of concerns, as transformation logic should not be in the Experience layer.

Option D: Deploying a new PAPI and using an API Proxy to redirect existing endpoints would add unnecessary complexity, disrupt the current API clients, and increase maintenance efforts.

Reference For additional guidance, refer to MuleSoft documentation on API-led connectivity best practices and best practices for structuring Experience, Process, and System APIs.


Contribute your Thoughts:

Destiny
20 days ago
Haha, the company better hope their API naming game is on point. EAPI-1, EAPI-2, Mobile PAPI-2? Someone's been watching too much Star Wars.
upvoted 0 times
...
Harrison
21 days ago
Wait, are we sure the mobile app needs a completely different data model? Maybe we can just tweak the existing PAPI to serve the mobile app's needs. That could be a simpler solution than building a whole new API.
upvoted 0 times
Zena
19 hours ago
A: Add two new Experience APIs (EAPI-i and EAPI-2). Add Mobile PAPI-2 to expose the intended subset of financial data as requested. Both PAPIs access the Legacy Systems via SAPI-1 and SAPI-2.
upvoted 0 times
...
...
Lashawn
26 days ago
Hmm, I'm not sure about Option D. Deploying a new PAPI implementation and an API Proxy feels a bit overkill for this use case. The mobile app's needs can be better addressed with a focused Experience API.
upvoted 0 times
...
Keva
27 days ago
I agree, Option C is the way to go. Building a dedicated mobile Experience API allows for a clean separation of concerns and makes it easier to maintain the different client requirements.
upvoted 0 times
Otis
15 days ago
I agree, having a separate mobile Experience API makes everything more manageable and efficient.
upvoted 0 times
...
Leslie
18 days ago
Option C is definitely the best choice. It keeps things organized and ensures compatibility with the mobile app.
upvoted 0 times
...
...
Tarra
1 months ago
I'm not sure, but option D also seems like a viable solution with a new PAPI implementation and API Proxy to redirect existing endpoints.
upvoted 0 times
...
Meaghan
1 months ago
I agree with Jenelle. Option A seems like the most efficient way to minimize impact on existing API clients and support asset reuse.
upvoted 0 times
...
Jenelle
2 months ago
I think option A is the best choice because it adds new Experience APIs and a Mobile PAPI to expose the subset of financial data.
upvoted 0 times
...
Sommer
2 months ago
Option C seems the most efficient approach, with a new mobile-specific Experience API that can handle the data transformation. This minimizes the impact on existing clients and API implementations.
upvoted 0 times
Kerry
24 days ago
It's important to minimize the impact on existing clients and API implementations, so Option C makes sense.
upvoted 0 times
...
Shelia
1 months ago
I agree, having a separate API for the mobile application will help keep things organized.
upvoted 0 times
...
Annice
1 months ago
Option C seems like the best choice. It creates a new mobile Experience API for the subset of data needed.
upvoted 0 times
...
...

Save Cancel