ODC Architecture Specialist flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

ODC deployment stages

Development, Test and Production are the fixed stages in OutSystems Developer Cloud; each stage runs an isolated copy of the app and its data, and revisions only move forward through them.

Architecture Canvas layers

End-user, Core and Foundation: end-user modules orchestrate screens, core modules own business rules and entities, foundation modules hold generic utilities; references flow downward, never upward.

Immutable revision

Deploying an app in ODC produces a numbered revision that cannot be edited afterwards; further changes require a new revision, and rollback means redeploying a previously published one.

Service Action

The mechanism ODC provides for one module to call logic in another: the producing module exposes an action as a service action and consumers reference it explicitly.

Studio versus Portal

ODC Studio is the desktop IDE used to design and publish modules; ODC Portal is the browser console used to manage stages, deployments, users, configuration, logs and metrics.

Dependency direction on canvas

A module may only reference modules in the same or a lower canvas layer; upward references and cycles are prohibited because they destroy reuse, testability and independent deployment.

NFRs resolved at design time

Because ODC hides servers and infrastructure, latency, throughput and availability targets must be translated into module boundaries, API contracts and data model choices during design.

Reactive Web App module

An ODC module type that renders a responsive browser interface; it contains screens, client actions, screen aggregates and references to libraries supplying server-side logic.

Library module

An ODC module type without user interface that packages reusable server actions, entities, structures and client actions for other modules, consumed through exposed service actions.

One app, one deployment unit

Everything inside an ODC app is built and deployed together, so the app boundary must match the release cadence, scaling profile and security boundary you actually need.

Acyclic reference graph

Module and app references must form a directed acyclic graph; a cycle blocks independent building and deployment and usually indicates that shared logic belongs lower in the canvas.

Offline mobile synchronisation

Mobile modules can keep data locally and synchronise with the server; conflicts and duplicates must be handled by an explicit designed strategy, not assumed away.

Screen Aggregate

A query bound to a screen that runs at screen load and returns only the attributes and rows the interface needs, cutting payload size and round trips.

Client versus server action

Client actions run in the browser and are visible to users; server actions run inside the app container and are the right place for validation, secrets and privileged data access.

Static Entity

Reference data defined in the model and deployed with the app; its records are overwritten at each deployment, so it must not hold transactional or user-entered data.

Aggregate

ODC's declarative query over entities that is translated to SQL and executed in the database, supporting filters, sorting, grouping and calculated attributes.

Private Gateway

An outbound-only agent installed in a private network that lets ODC apps call internal services without exposing those services to the public internet.

Entity versus Structure

Entities are persisted in the ODC database and survive deployments; structures are in-memory composite types used for parameters, API payloads and screen data.

Avoid cross-app entity sharing

Sharing entities between apps couples their schemas and blocks independent deployment; expose data through service actions or REST APIs so each app owns its tables.

Timer

A scheduled server-side action persisted in the database; it runs asynchronously, survives app redeployment and is used for batch or delayed work instead of holding request threads.

End-user authentication

End users of ODC apps sign in through the identity provider configured for the tenant, either the built-in one or an external OIDC provider such as Entra ID or Okta.

Server-side role check

Roles granted to end users must be enforced on the server with a role check; hiding interface elements alone is cosmetic and is bypassed by calling the exposed API directly.

Secrets management

Credentials and API keys belong in ODC Portal configuration or deployment-injected secrets, never in module code, static entities or client-side JavaScript.

IT-user single sign-on

Developers and administrators authenticate to ODC Studio and Portal with their own identities through the configured identity provider; shared accounts destroy the audit trail.

Least privilege in service actions

Expose only the actions external consumers require, and have each one re-check the caller's role and re-validate input instead of trusting the calling side.

Audit and log streaming

ODC records deployment and access events in the portal and can stream runtime logs to an external SIEM, which is how security monitoring and forensics are performed.

Per-app autoscaling

ODC scales containers per app, so modules with very different load profiles should live in separate apps rather than being scaled together as one set.

Pagination

Fetching large result sets in pages, using aggregates that limit rows plus interface controls that request the next page, keeps response time and memory flat as data grows.

Index filtered attributes

Entity attributes used in aggregate filters, sorts and joins should be indexed; without an index the database performs full scans as the table grows.

Backward-compatible schema change

Because redeploying does not revert database schema, drops and renames must be split across releases so the previous revision still works against the new schema.

Deployment plan

An ordered list of app revisions promoted from one stage to the next in ODC Portal, sequenced so consumers deploy after the libraries and producers they reference.

Impact analysis before publish

Checking which modules and apps reference a changed element before publishing prevents broken references and untested regressions from reaching Test or Production.