Every App running in Runtime deals with its own data and most of the times, that same data is stored in external locations to ODC.

In order to keep a high standard, namely in terms of managing data in transit, securing its access and reduce latency to it, ODC uses a Data Fabric Securiy approach, based on the same implementation available in AWS.

Integrations with external databases are defined using Data Fabric Connectors, configuring the connections to those databases in the ODC Portal.

Data Fabric Connectors process all the external databases in an uniform way, with no storage persistence in Data Fabric itself, or in any component in the ODC Architecture.
They retrieve essential metadata from external systems, so developers can select integration tables, objects and columns, which are meant to be used by a given App. The selected metadata is securely stored in serverless, NoSQL databases during the connection's lifetime in the ODC Portal.

Connecting to external databases

When a new database connection is set, developers must supply the database server hostname, port and also the user credentials - user name and password, in the ODC Portal.
ODC encrypts passwords and stores them securely, as secrets in the cloud secret store.

Passwords are never stored in clear text and Outsystems doesn't have a way of accessing them.

More details regarding this operation can be read here.

Memory

While Apps are running in Runtime or when developers preview data in ODC Studio, Data Fabric executes queries on the external systems set in the ODC Portal and once data is fetched, it's stored in memory for processing, before being sent back to either the runtime Apps or ODC Studio.

What is meant by memory for these scenarios, it's the one concerning all App's Pod memory and in-memory databases, which only contain non-human readable information. Also, it needs to be highlighted that memory data is not logged, so it's not persisted in disk, as well.

What is stored in memory?

There are different kinds of data and each one is stored in memory, in a distincted way:

• Query parameter values are stored both in the App's Pod memory, as well as in the in-memory database, typically being discarded once the result is consumed. If an error prevents the query statement to be closed (which triggers the deletion of the values), the parameter values are set to be deleted after 5 minutes;
• Query results are stored in the App's Pod memory, with the same retention policy, as the query parameter values, mentioned before;
• Metadata - tables, columns, primary key/foreign key constraints, will remaid in memory in both the App's Pod memory, as wel as in the in-memory database and as long as the connection lasts.

Caches

ODC uses caching in order to optimize performance inside its architecture, by storing certain kinds of information, while dealing with external data.
When integrating with external systems ODC extends this same caching principle storing the following information:

• Query statements executing in runtime Apps are chached to maintain consistent execution plans i the underlying system to enhance performance;
• Query results are cached in the App's pod memory. The cache expiration is set by the developers at the aggregate level;
• Metadata is cached during the connection creation or when refreshing metadata in the ODC Portal. After these moments, metadata is stored in serverless NoSQL databases

Data in transit

When making queries to an external database, either by developers in data preview (ODC Studio), or by end users in runtime Apps, and getting the result of those queries back, data goes through different communication channels.

For instance, queries start at the frontend, go through several different Kubernetes services, connect to the external system and then return the results back to the frontend, as it's shown in the following diagram.

The two communication mechanisms employed by ODC to keep security while data is in transit are:

• message-oriented middleware, which encrypts messages , in order to protect potential sensitive data, such as messages with Personal Identifiable Information (PII), before sending it. To achieve this ODC uses a key management service, which encodes and decodes messages, ensuring security and confidentiality;
• REST APIs strictly use HTTPS for data in transit. Each request maintains access control through web tokens. These web tokens contain only essential information for authentication and authorization and also validate the identity and access control of the caller to the given API.

Termination or other deletion case scenarios

If an ODC subscription is terminated, customer metadata stored persistently is automatically deleted. This same principle applies to connections to external customer systems set in the ODC Portal, namely customer databases.

In the case a customer environment is deleted from ODC, without previously removing any connections to external systems, any data still in the in-memory database is automatically cleared after 4 hours.