Entity is exposed as read-only, and an API is available to centralize business logic for entity creation/ update.

Same as the Base ECS pattern, but with a local replica. Data is stored to serve as a local cache. Pro: Leverage Entity Use, Simpler Integration API. Con: Less impact on the source system.

Same as ECS with direct integration, but implemented through an Enterprise Service Bus.

A pattern with two modules: a connector module that encapsulates an external API with the input/ output structures and a wrapper module to expose the normalized API to consumers.

Tries to fetch data from a local cache entity; if not found, it retrieves a single entry from the external
system. Only that record is cached (read-through caching). Use when: The database is too large or costly to synchronize, and integration only requires a small portion of the data. Avoid if: Access to lists of data is needed upfront.

Same as ECS with a local replica, but an API module is provided. This allows changes in the external system to notify OS, which then retrieves updates from the ERP system (subscription system).

Same as ECS with a local replica, but synchronization logic is separated. Pro: Code independence.
Consumers of CS are not affected by synchronization. Sync can orchestrate multiple CS.

A wrapper used to contain the logic, actions, and data that exposes code within an external library, or to inspect an external database and import the data structures so they can be used as entities within
OS.

Entity is not within Outsystems but resides in an external ERP system. IS makes remote calls to the external system/database. No data is stored inside OS. Con: Data retrieval may not be optimized as it traverses two systems. Integration API must support all use cases.

Used when data comes from multiple external systems. IS determines which driver to use based on the data.