Refer to the exhibit. A business process involves the receipt of a file from an external vendor over SFTP. The file needs to be parsed and its content processed, validated, and ultimately persisted to a database. The delivery mechanism is expected to change in the future as more vendors send similar files using other mechanisms such as file transfer or HTTP POST.
What is the most effective way to design for these requirements in order to minimize the impact of future change?
To minimize the impact of future changes, it is essential to adopt a layered architecture separating the concerns of file reception and data processing. Creating an API that receives the files and then invokes a Process API ensures that any changes in the file delivery mechanisms (like SFTP, file transfer, or HTTP POST) only affect the receiving layer. This approach encapsulates the file reception logic, allowing the core data processing logic, which can be more complex and likely more stable, to remain unaffected. Utilizing the Process API to handle the data processing using a MuleSoft Batch Job and other System APIs as needed provides modularity and scalability, making the system adaptable to future changes and additions.
D is correct
It should be D. Key here is there will be future changes. You want to design so that Process API does not need any change. Fronting Process API with another API layer gurantees that Process API will not need to change for any future changes. Everything else can remain same for future changes, just the API that sends requests to Process API need to change.
It should be D
D is better than C, as having 3-layers exp, prc and sys, but C has only prc and sys
API Led connectivity- answer D
D. Create an API that receives the file and invokes a Process API with the data contained in the file, then have the Process API process the data using a MuleSoft Batch Job and other System APIs as needed
D is the only applicable
it should be A