What is the most effective way to design for these requirements in order to minimize the impact of future change?

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?
A . Use a MuleSoft Scatter-Gather and a MuleSoft Batch Job to handle the different files coming from different sources
B . Create a Process API to receive the file and process it using a MuleSoft Batch Job while delegating the data save process to a System API
C . 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 . Use a composite data source so files can be retrieved from various sources and delivered to a MuleSoft Batch Job for processing

Answer: C

Explanation:

* Scatter-Gather is used for parallel processing, to improve performance. In this scenario, input files are coming from different vendors so mostly at different times. Goal here is to minimize the impact of future change. So scatter Gather is not the correct choice.

* If we use 1 API to receive all files from different Vendors, any new vendor addition will need changes to that 1 API to accommodate new requirements. So Option A and C are also ruled out.

* Correct answer is 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. Answer to this question lies in the API led connectivity approach.

* API-led connectivity is a methodical way to connect data to applications through a series of reusable and purposeful modern APIs that are each developed to play a specific role C unlock data from systems, compose data into processes, or deliver an experience. System API: System API tier, which provides consistent, managed, and secure access to backend systems. Process APIs: Process APIs take core assets and combines them with some business logic to create a higher level of value. Experience APIs: These are designed specifically for consumption by a specific end-user app or device.

So in case of any future plans, organization can only add experience API on addition of new Vendors, which reuse the already existing process API. It will keep impact minimal.