Which of the below matches the most to Core Module Pattern - Base ECS Pattern...

The Base ECS (Expose, Consume, Synchronize) pattern, often referred to as the Integration Wrapper pattern, is a fundamental architectural structure for integrating with external systems in OutSystems. It mandates a two-module approach for abstraction and stability. The first module, the Connector, encapsulates all technical aspects of the integration, such as consuming a specific API and its data structures. The second module, the Core Service (or Wrapper), consumes the Connector and exposes a simplified, stable, and business-aligned API to the rest of the application portfolio, effectively hiding the complexity of the external system from the consumers.

A. This description focuses solely on the Connector module's role, which is only one half of the complete Base ECS pattern.

B. This describes the "Summary/Detail" caching pattern, a specific data synchronization strategy, not the fundamental architectural structure of the Base ECS.

C. This describes an advanced pattern where synchronization logic is decoupled into a third module, which is a variation, not the base pattern.

E. This describes an "Integration Broker" or "Gateway" pattern, which is used to abstract and orchestrate multiple external systems.

F. This describes a reactive synchronization method using a subscription or webhook model, which is a specific implementation, not the base pattern.

G. This explicitly describes the "ECS with Local Replica" pattern, a common variation that adds local caching, but it is not the base pattern itself.

H. This describes the functional behavior of a remote integration but omits the crucial two-module architectural structure that defines the pattern.

I. This describes the "Read-Through Cache" pattern, a specific on-demand caching strategy used when full synchronization is not feasible.

J. This describes the principle of exposing read-only entities, a best practice applied within the Core Service module, not the entire integration pattern.

1. OutSystems Documentation

"Architecture Patterns in OutSystems" Guide: The "Integration Wrapper" pattern is detailed

stating

"This pattern consists of two modules: a connector that encapsulates an external API with the input/output structures

and a wrapper that exposes a normalized API to consumers." This guide provides a diagram showing the Connector (ISV) and the Core Service (CS) wrapper

which directly corresponds to option D.

2. OutSystems Training

"Architecture of OutSystems Applications" Course Material: In the section on integration layers

the course explains the need to isolate external system complexities. It presents the pattern of having a dedicated Connector module and a Core Service module that acts as a wrapper to provide a stable API

insulating consumer modules from changes in the external system. This reinforces the two-module structure described in option D.

3. OutSystems Documentation

"Designing the Architecture of Your OutSystems Applications" White Paper: Section 3.3

"Integration Layer

" discusses abstracting integrations. It advocates for creating a "connector" to handle the technical protocol and a "core service" to expose a public

stable API

which aligns perfectly with the description in option D.