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
Mail Us support@pass4success.com
Location US
Mob_nav_barsMENU

Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) Exam - Topic 2 Question 16 Discussion

Say, there is a legacy CRM system called CRM-Z which is offering below functions:1. Customer creation2. Amend details of an existing customer3. Retrieve details of a customer4. Suspend a customer
B) Implement different system APIs named createCustomer, amendCustomer, retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns
A) Implement a system API named customerManagement which has all the functionalities wrapped in it as various operations/resources
C) Implement different system APIs named createCustomerInCRMZ, amendCustomerInCRMZ, retrieveCustomerFromCRMZ and suspendCustomerInCRMZ as they are modular and has seperation of concerns

Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) Exam - Topic 2 Question 16 Discussion

Actual exam question for Salesforce's Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) exam
Question #: 16
Topic #: 2
[All Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) Questions]

Say, there is a legacy CRM system called CRM-Z which is offering below functions:

1. Customer creation

2. Amend details of an existing customer

3. Retrieve details of a customer

4. Suspend a customer

Show Suggested Answer Hide Answer
Suggested Answer: B



Correct Answer : Implement different system APIs named createCustomer, amendCustomer, retrieveCustomer and suspendCustomer as they are modular and has seperation of concerns

*****************************************

>> It is quite normal to have a single API and different Verb + Resource combinations. However, this fits well for an Experience API or a Process API but not a best architecture style for System APIs. So, option with just one customerManagement API is not the best choice here.

>> The option with APIs in createCustomerInCRMZ format is next close choice w.r.t modularization and less maintenance but the naming of APIs is directly coupled with the legacy system. A better foreseen approach would be to name your APIs by abstracting the backend system names as it allows seamless replacement/migration of any backend system anytime. So, this is not the correct choice too.

>> createCustomer, amendCustomer, retrieveCustomer and suspendCustomer is the right approach and is the best fit compared to other options as they are both modular and same time got the names decoupled from backend system and it has covered all requirements a System API needs.


by Eulah at Sep 12, 2024, 10:26 PM

Limited Time Offer

25%

Off

Get Premium Salesforce Certified MuleSoft Platform Architect (Mule-Arch-201) Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Emmett
9 months ago
I like the idea of separation of concerns in B!
upvoted 0 times
...
Marylin
10 months ago
Wait, why would we need to specify "InCRMZ"? Seems unnecessary.
upvoted 0 times
...
Lavina
10 months ago
C is too long, makes it harder to remember the API names.
upvoted 0 times
...
Serita
10 months ago
I disagree, A is simpler and easier to manage.
upvoted 0 times
...
Berry
10 months ago
Option B seems the best for modularity.
upvoted 0 times
...
Jackie
10 months ago
I feel like option C is overcomplicating things with the "InCRMZ" suffix, but I can't quite recall why that might be a problem.
upvoted 0 times
...
Ora
11 months ago
I practiced a similar question where we had to choose between modular and monolithic designs, and I think B is the way to go here.
upvoted 0 times
...
Margurite
11 months ago
I'm not entirely sure, but I think option A might be simpler since it wraps everything into one API.
upvoted 0 times
...
Kimberely
11 months ago
I remember discussing the importance of modularity in APIs, so option B seems like a good choice for separation of concerns.
upvoted 0 times
...
Katy
11 months ago
I think I'd lean towards option A. Having a single customerManagement API seems more efficient and easier to work with, rather than dealing with multiple separate APIs.
upvoted 0 times
...
Miesha
11 months ago
Option C looks good to me. Naming the APIs with the CRM-Z prefix makes it clear that they're interacting with the legacy system, which is important for maintainability.
upvoted 0 times
...
Kirk
11 months ago
Hmm, I'm a bit confused. Should we wrap all the CRM-Z functions into a single API or create separate ones? I'm not sure which approach would be better.
upvoted 0 times
...
Charlette
11 months ago
This seems like a straightforward question. I'd go with option B and implement separate APIs for each functionality to maintain separation of concerns.
upvoted 0 times
...
Ria
11 months ago
Okay, I've got this. Adding a digital signature is the way to go. That will verify the document's authenticity and prevent any unauthorized changes.
upvoted 0 times
...
Lilli
2 years ago
I'm with the others on this one. Option C is the clear winner. Though I do wonder if the CRM-Z developers are still using floppy disks and punch cards...
upvoted 0 times
...
Edwin
2 years ago
Option B looks good too, but I think C is the stronger choice. Who wants to deal with a generic 'customerManagement' API when you can have specific, descriptive ones?
upvoted 0 times
...
Raymon
2 years ago
I agree with My. Option C is the most modular and maintainable approach. Separating the concerns like that is a best practice.
upvoted 0 times
...
My
2 years ago
Option C is the way to go! Keeping the API names specific to the CRM-Z system makes it clear which operations are being performed on that legacy system.
upvoted 0 times
Cecily
2 years ago
User 3: Option C it is then, for modular and separated concerns.
upvoted 0 times
...
Nydia
2 years ago
User 2: I agree, having specific API names for CRM-Z system operations is clear.
upvoted 0 times
...
Eloisa
2 years ago
I think option C is the best choice.
upvoted 0 times
...
...
Hannah
2 years ago
I see your point, Chana. But I still think having separate APIs for each function can lead to better scalability and maintainability in the long run.
upvoted 0 times
...
Chana
2 years ago
I disagree, I believe option B is better because it follows the principle of separation of concerns and makes the system more modular.
upvoted 0 times
...
Hannah
2 years ago
I think option A is the best choice because having all functionalities in one API makes it easier to manage.
upvoted 0 times
...

Save Cancel