Oracle Cloud Oracle APEX Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application Development

1. Introduction

Oracle APEX (Oracle Application Express) is Oracle’s low-code application development platform for building data-centric web applications on top of Oracle Database. On Oracle Cloud, Oracle APEX is available as a managed cloud service (commonly presented in the OCI Console as APEX Application Development) and is also included with Oracle Database offerings such as Oracle Autonomous Database.

In simple terms: Oracle APEX lets you build secure web apps quickly using your database as the foundation, with minimal code, and deploy them in Oracle Cloud with managed infrastructure.

Technically, Oracle APEX is a metadata-driven runtime that stores application definitions in Oracle Database tables and renders pages through a web listener (typically Oracle REST Data Services (ORDS)). In Oracle Cloud deployments, the database (often Autonomous Database) and the APEX runtime are managed by Oracle, while you focus on schemas, data models, app logic, security, and lifecycle.

Oracle APEX solves a common problem: teams need internal tools, workflow apps, reporting portals, and CRUD applications fast—without building and operating a full custom web stack. It also helps modernize Excel- and email-based processes into secure, auditable, scalable applications backed by Oracle Database.

Naming note: “Oracle APEX” is the product. In Oracle Cloud Infrastructure (OCI), the console experience may be branded as APEX Application Development. This tutorial uses Oracle APEX as the primary service name (as requested) and calls out OCI-specific service names where relevant. Verify the latest naming in official docs if the console labels change.

2. What is Oracle APEX?

Official purpose

Oracle APEX is a low-code development platform for rapidly building and deploying secure, scalable, data-driven web applications on Oracle Database.

Official documentation (start here):
https://docs.oracle.com/en/database/oracle/apex/
OCI APEX service documentation:
https://docs.oracle.com/en/cloud/paas/apex-service/

Core capabilities (what you can do)

Build responsive web apps (forms, reports, dashboards, workflows)
Model data in Oracle Database and generate UI on top of it
Implement authentication/authorization and fine-grained access control
Create REST APIs and integrate with external systems (typically via ORDS and APEX features)
Automate processes (validations, computations, dynamic actions)
Deliver apps with built-in UI components (Interactive Reports/Grids, charts, calendars, etc.)
Manage app lifecycle (development, packaging, deployment)

Major components

Oracle APEX runtime engine: renders pages and executes app logic
APEX Builder: browser-based IDE to create and manage applications
APEX Administration Services: manage instances, workspaces, security settings
Workspaces: logical isolation boundaries for teams/apps/schemas
Oracle Database schemas: where your tables, views, PL/SQL, and data live
ORDS (Oracle REST Data Services): HTTP gateway and REST layer commonly used to serve APEX and REST endpoints (managed for you in many Oracle Cloud setups)

Service type

Low-code application development platform tightly coupled to Oracle Database
In Oracle Cloud, commonly consumed as a managed platform service (APEX Application Development) and/or as part of Autonomous Database

Scope (regional/global/etc.)

Oracle APEX deployments in Oracle Cloud are generally regional resources because they run in a specific OCI region (aligned to where your database/service instance is provisioned). Access is global over HTTPS, but resource placement, latency, and data residency are region-based.

How it fits into the Oracle Cloud ecosystem

Oracle APEX fits naturally into Oracle Cloud in these patterns: – APEX + Autonomous Database for rapid app delivery with managed database operations – Integration with OCI services for enterprise needs: – Identity (OCI IAM / Identity Domains) for authentication federation (verify exact options in your region/service) – Logging/Audit for governance – Networking controls for private access patterns (service capabilities vary by deployment type—verify in official docs) – Object Storage for files, exports, and app assets (integration patterns vary)

3. Why use Oracle APEX?

Business reasons

Faster delivery for internal apps, departmental solutions, and prototypes that often become production systems
Lower total cost of ownership for data-centric apps because much of the platform is built-in
Reduced dependency on specialized front-end stacks for common enterprise patterns (forms, reports, approvals)

Technical reasons

Database-first development: Oracle Database features (SQL, PL/SQL, constraints, analytics) are first-class
Strong built-in UI components:
Interactive Reports/Grids
Charts and dashboards
Validations and wizard-driven CRUD
Extensibility: use SQL/PL/SQL where low-code ends, and add JavaScript/CSS when needed (with governance)

Operational reasons

In Oracle Cloud managed offerings, you avoid operating:
web servers for the APEX runtime
patching of the APEX middle tier (depending on the service mode)
Centralized administration through APEX instance/workspace controls

Security/compliance reasons

Built-in security patterns (session state protection, authorization schemes, declarative validations)
Oracle Database security features underpin the platform (roles, privileges, auditing options)
Strong alignment to enterprise governance (logging/auditing and identity integration patterns)

Scalability/performance reasons

APEX scales with Oracle Database performance characteristics and tuning
Works well for many concurrent users for typical data-entry/reporting workloads when database design and SQL are efficient
Production-grade performance depends on:
schema design
indexing
SQL quality
session state design
database capacity choices (especially with Autonomous Database)

When teams should choose Oracle APEX

Choose Oracle APEX when: – Your data lives in Oracle Database (or should) – You need secure CRUD apps, reports, dashboards, workflow-style apps quickly – You want strong governance and database-centric logic (PL/SQL) – You want a managed platform option on Oracle Cloud

When teams should not choose Oracle APEX

Avoid or reconsider Oracle APEX when: – You need highly custom UI interactions akin to a full SPA framework and you don’t want to manage custom JavaScript complexity – Your primary data platform is not Oracle and you cannot justify Oracle Database – You need workloads that are not a natural fit for database-centric request/response apps (for example: real-time multiplayer, heavy streaming, graphics-intensive front ends) – You require deployment modes that APEX service does not support in your environment (for example: strict on-prem-only constraints without an Oracle Database/Apex stack)

4. Where is Oracle APEX used?

Industries

Oracle APEX is commonly used in: – Finance and insurance (approvals, compliance dashboards, operational tools) – Healthcare (internal portals, scheduling tools, audit-heavy workflows) – Manufacturing and logistics (inventory, QA tracking, field reporting) – Public sector (case management, reporting portals) – Education (admin systems, departmental tools) – Retail (ops dashboards, SKU data tools)

Team types

Database teams expanding into application delivery
Enterprise app teams building internal tools quickly
Platform teams standardizing on Oracle Database + Oracle Cloud
Citizen developers with governance (often with IT oversight)

Workloads

CRUD applications and departmental tools
Operational dashboards and analytics-driven portals
Workflow and approvals (often implemented with tables + status transitions)
Data quality, master data stewardship apps
Admin portals for other systems

Architectures

APEX + Autonomous Database (common in Oracle Cloud)
APEX + Oracle Database + ORDS (self-managed or managed variants)
APEX integrated with external services through REST APIs

Real-world deployment contexts

Production internal apps (hundreds to thousands of users)
External-facing portals (careful security design, WAF, identity federation)
Dev/test sandboxes and prototypes that later harden into production

Production vs dev/test usage

Dev/test: ideal for quick iteration; use separate workspaces/schemas and separate OCI environments where possible
Production: enforce change control (export/import apps), least privilege, auditing, performance testing, and a data lifecycle strategy

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle APEX on Oracle Cloud fits well.

1) Internal Request & Approval Portal

Problem: Email-based approvals are slow, untracked, and not auditable.
Why Oracle APEX fits: Rapid CRUD + status workflow + role-based access.
Example: Purchase request app with approver routing and an audit report.

2) Operational KPI Dashboard for Business Units

Problem: Teams need near-real-time dashboards without building a BI stack for every department.
Why it fits: Interactive Reports/Charts over SQL views; scheduled data refresh via DB jobs.
Example: Warehouse throughput dashboard with drill-down by site and shift.

3) Data Quality / Data Stewardship Tool

Problem: Master data corrections happen ad hoc and aren’t traceable.
Why it fits: Interactive Grid editing, validation, change logs via triggers/auditing.
Example: Customer master cleanup with duplicate detection and resolution workflow.

4) Incident / Issue Tracker (Lightweight)

Problem: Teams need a simple tracker integrated with Oracle data.
Why it fits: Quick tables + report + form + notifications integration.
Example: Internal IT issue tracker tied to asset inventory tables.

5) Secure External Partner Portal (Database-Backed)

Problem: Partners need to upload/view records securely with limited access.
Why it fits: Fine-grained authorization with row-level logic; strong database security.
Example: Supplier portal for delivery confirmations and invoice status.

6) Spreadsheet-to-App Modernization

Problem: Critical processes depend on spreadsheets with no controls.
Why it fits: APEX can generate apps from tables; import spreadsheet data; enforce constraints.
Example: Replace a spreadsheet-based training compliance tracker with a web app.

7) Compliance Evidence Collection App

Problem: Audit evidence is scattered across folders and emails.
Why it fits: Forms, file attachments (pattern varies), status workflow, reporting.
Example: SOX evidence submission with role-based review and timestamps.

8) Customer Service Back Office Console

Problem: Agents need a fast console for searches, edits, and case notes.
Why it fits: Fast query UIs, dynamic actions, PL/SQL for business logic.
Example: A customer lookup page with activity timeline and quick actions.

9) Self-Service Data Access Portal

Problem: Analysts repeatedly request the same extracts.
Why it fits: Parameterized reports with export; controlled access; audit trails.
Example: A “download my region’s data” portal with row-level filters.

10) REST-Backed Micro-Portal for a Single Domain

Problem: A small team needs a web UI over a stable API/data model.
Why it fits: APEX is efficient for building UI quickly; ORDS/APEX REST can expose APIs.
Example: A portal for managing reference data that other apps consume via REST.

11) Admin UI for a Multi-System Integration Hub

Problem: Integration processes need configuration screens and monitoring.
Why it fits: UI for configuration tables + monitoring reports; integrates with logs/metrics.
Example: Manage routing rules and view processing errors from integration tables.

12) Rapid Prototype for Product Validation

Problem: Need to validate workflows with users quickly before building a full product.
Why it fits: Low-code iteration with working data model and security from day one.
Example: Prototype an onboarding workflow with role-based steps and reports.

6. Core Features

Feature availability can differ depending on whether you use Oracle APEX via APEX Application Development (managed service) or install/configure APEX with your own database/ORDS. Always verify in official docs for your exact deployment model.

1) Declarative App Builder (Browser IDE)

What it does: Build pages, navigation, components, processes using a wizard-driven UI.
Why it matters: Accelerates development; standardizes patterns.
Practical benefit: Teams can deliver apps in days rather than weeks.
Caveat: Complex UI customizations can reintroduce traditional web complexity—govern custom JS/CSS carefully.

2) Interactive Reports and Interactive Grids

What it does: End users can filter/sort/group/aggregate/export; grids support editing.
Why it matters: Reduces need for custom reporting UI.
Practical benefit: Powerful reporting with minimal code.
Caveat: Large datasets require paging/indexing and careful SQL; don’t “SELECT *” on huge tables.

3) Universal Theme and Responsive UI Components

What it does: Provides a consistent responsive design system.
Why it matters: Modern UX without heavy front-end work.
Practical benefit: Mobile-friendly apps by default.
Caveat: Highly bespoke UX might require advanced theming skills.

4) Authentication and Authorization Schemes

What it does: Supports multiple authentication approaches (APEX accounts, external identity providers depending on setup) and declarative authorization rules.
Why it matters: Security is foundational; controls who can do what.
Practical benefit: Implement role-based access quickly.
Caveat: External SSO integration depends on environment (OCI Identity Domains vs other IdPs). Verify supported configurations in the APEX service docs.

5) Session State Management and Security Protections

What it does: Manages state between requests; includes protections such as session state protection options and built-in security settings.
Why it matters: Helps prevent common web vulnerabilities.
Practical benefit: Secure defaults when used correctly.
Caveat: Developers can still introduce risk with unsafe dynamic SQL, weak authorization checks, or careless item/session handling.

6) SQL Workshop and Database Object Browser

What it does: Build and manage tables, views, packages, data loads, and SQL scripts from the browser.
Why it matters: Great for rapid iteration and onboarding.
Practical benefit: Enables DB-centric dev without external tools.
Caveat: For production change control, prefer versioned SQL scripts and CI/CD patterns rather than ad hoc changes.

7) REST Enablement (ORDS integration patterns)

What it does: Commonly, ORDS enables REST APIs on Oracle Database objects and can host APEX.
Why it matters: Integration with other systems.
Practical benefit: Publish or consume REST endpoints without building a separate API tier.
Caveat: Exact REST features and administration options vary by deployment (managed service vs self-managed ORDS). Verify in official ORDS and APEX service documentation.

ORDS docs: https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/

8) Automations, Validations, and Dynamic Actions

What it does: Declarative logic for validations, computations, conditional UI behavior, and automation.
Why it matters: Keeps logic consistent and maintainable.
Practical benefit: Less code, fewer bugs.
Caveat: Overuse of page-level logic can become hard to reason about; keep business logic centralized in PL/SQL where appropriate.

9) Application Lifecycle: Export/Import and Deployment

What it does: Export apps as SQL scripts for deployment; install in other environments.
Why it matters: Enables dev/test/prod separation.
Practical benefit: Repeatable deployments.
Caveat: You still need a disciplined release process (Git, CI/CD, approvals).

10) Built-in Monitoring Aids (APEX Activity/Logs)

What it does: Provides app-level insight (page views, errors, sessions) within APEX tools.
Why it matters: Helps troubleshoot user issues and performance.
Practical benefit: Faster incident response.
Caveat: For enterprise observability, also use Oracle Cloud logging/metrics where available.

7. Architecture and How It Works

High-level service architecture

At runtime: 1. A user accesses your APEX app via HTTPS. 2. The request is handled by the APEX web tier (often via ORDS). 3. APEX reads application metadata and session state from Oracle Database. 4. SQL/PLSQL executes in the database to fetch/update data. 5. HTML/JSON responses return to the browser.

Request/data/control flow

Control flow: Browser → APEX runtime → PL/SQL processes/validations → database commit/rollback
Data flow: SQL queries and DML on your schema objects; optional external REST calls from within APEX (via built-in web service capabilities) depending on configuration
State: APEX maintains session state; secure session configuration is critical

Integrations with related services (Oracle Cloud context)

Common Oracle Cloud integrations include: – Oracle Autonomous Database: primary data store and execution engine – OCI IAM / Identity Domains: centralized identity, federation, MFA (integration varies by setup; verify) – OCI Audit: records API calls in OCI for governance – OCI Logging & Monitoring: visibility into service and database metrics/logs (capabilities depend on the specific service resource) – OCI Networking: VCN patterns are more relevant when you manage DB/network directly; managed APEX service is typically public-facing with managed endpoints—verify private connectivity options if required

Dependency services

Oracle Database (commonly Autonomous Database in OCI)
ORDS (commonly managed as part of the platform)
OCI identity and network controls for access and governance

Security/authentication model (conceptual)

Authentication: identifies the user (APEX accounts or federated identity)
Authorization: determines permissions (roles, authorization schemes, row-level checks)
Database security: tables, views, packages; least privilege; avoid exposing powerful schemas

Networking model (conceptual)

APEX apps are accessed over HTTPS.
The database is not directly accessed from clients; requests go through APEX runtime.
For integrations to private services, you may need network design (VCN, gateways) depending on where those services live—capabilities vary by APEX deployment model.

Monitoring/logging/governance considerations

Enable and review APEX activity logging for application-level events.
Use Autonomous Database performance views/metrics for SQL and resource usage.
Use OCI Audit to monitor administrative actions in the tenancy.
Standardize tagging and compartments for environment separation.

Simple architecture diagram

flowchart LR
  U[User Browser] -->|HTTPS| APEX[Oracle APEX Runtime]
  APEX -->|SQL/PLSQL| DB[(Oracle Database / Autonomous Database)]
  DB --> APEX
  APEX --> U

Production-style architecture diagram (Oracle Cloud)

flowchart TB
  Users[Users / Browsers] -->|HTTPS| APEXSvc[Oracle APEX (Managed Service / ORDS)]
  IdP[OCI IAM Identity Domain / Federated IdP] -->|SSO/OAuth/OIDC (as supported)| APEXSvc

  APEXSvc -->|SQL/PLSQL| ADB[(Oracle Autonomous Database)]
  APEXSvc -->|Outbound REST (optional)| Ext[External APIs / SaaS]

  subgraph Governance[Governance & Ops]
    Audit[OCI Audit]
    Mon[OCI Monitoring / Metrics]
    Log[OCI Logging (where supported)]
  end

  APEXSvc -.-> Mon
  ADB -.-> Mon
  APEXSvc -.-> Log
  APEXSvc -.-> Audit

Notes: – Exact identity integration and logging export features depend on your APEX deployment model and OCI region. Verify supported integrations in the APEX service and Autonomous Database documentation.

8. Prerequisites

Account / tenancy requirements

An Oracle Cloud account (OCI tenancy)
Access to a region that offers Oracle APEX service options (APEX Application Development and/or Autonomous Database). Region availability can vary—verify in OCI documentation.

Permissions / IAM roles

You need IAM permissions to: – Create and manage the APEX-related service instance (in the OCI Console this is typically under Developer Services). – Create and manage the underlying database resources if your setup includes provisioning Autonomous Database. – View logs/metrics and manage networking if your architecture requires it.

Because IAM policy resource names can change and differ by service mode, verify the exact IAM policy statements in official docs for: – APEX Application Development (OCI) – Autonomous Database – OCI IAM Identity Domains (if using SSO)

Start with: – OCI IAM overview: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm
– APEX service docs: https://docs.oracle.com/en/cloud/paas/apex-service/

Billing requirements

A payment method may be required even for Always Free resources (Oracle’s sign-up requirements can change).
For production, assume usage-based billing for database capacity and related services.

Tools needed

For the core lab: – A modern browser Optional: – SQL client for Oracle Database (SQL Developer, SQLcl) if you prefer local tools (not required for APEX-only workflows)

Region availability

Choose a region with:
APEX Application Development (if you want the managed APEX service experience)
Autonomous Database (if you want to run APEX in your ADB)
Verify in the OCI Console service availability list for your tenancy.

Quotas / limits

Always Free and trial tenancies can have strict limits (number of instances, OCPU, storage).
Production quotas are tenancy-specific; request quota increases as needed.

Prerequisite services

Depending on your path: – Oracle APEX Application Development service (managed) and/or – Oracle Autonomous Database (recommended for most Oracle Cloud APEX deployments)

9. Pricing / Cost

Oracle APEX as a product is typically included with Oracle Database (licensing depends on your database licensing model), and in Oracle Cloud you commonly pay for the underlying platform resources rather than “APEX per user” licensing.

Because Oracle pricing is region/SKU/edition dependent and can change, do not rely on static numbers in articles. Use official pricing sources for current rates.

Pricing dimensions (typical in Oracle Cloud)

Your costs usually come from: – Autonomous Database (or Oracle Database service) consumption: – Compute capacity (for example OCPU-based or ECPU-based measures depending on the service and pricing model) – Storage (GB/month) – Optional backups and additional features depending on service selection – Networking: – Egress (data leaving OCI to the internet) can be chargeable – Private connectivity (FastConnect, VPN) has cost implications – Observability and security services (if used): – Logging ingestion/storage – Additional security tooling (WAF, etc.) – Object Storage (if you store exports/files/assets there)

Free tier (if applicable)

Oracle Cloud offers an Always Free tier for some services and shapes, which can include options that support small APEX workloads (often via Always Free Autonomous Database and/or APEX service experiences).

Oracle Cloud Free Tier: https://www.oracle.com/cloud/free/

Always Free eligibility and limits vary by region and account status. Verify current Always Free APEX/ADB availability in your tenancy.

Key cost drivers

Database sizing (compute + storage) is usually the dominant driver.
Poor SQL and missing indexes can increase compute usage.
High concurrency and heavy reporting can increase required capacity.
Data egress for downloads and integrations can add cost.

Hidden or indirect costs to watch

Exporting large datasets to users on the public internet (egress)
Logging retention and log volume
Non-production environments left running
Backups and long-term retention choices
Third-party integrations (SaaS/API usage fees)

Network/data transfer implications

Ingress is typically cheaper than egress; egress can be a surprise cost.
Keep data processing inside OCI regions when possible.
Use caching/export controls for large downloads.

How to optimize cost (practical)

Start with Always Free / smallest viable Autonomous Database size for dev/test.
Use good database design:
proper indexing
avoid heavy “SELECT *”
materialized views for expensive aggregates (if appropriate)
Schedule or limit expensive reports.
Separate dev/test from prod; shut down non-prod resources if supported by your service.
Control exports and enforce pagination.

Example low-cost starter estimate (no fabricated numbers)

A typical low-cost starter path is: – Use Always Free resources if eligible: – Always Free Autonomous Database + APEX usage for small apps – Keep storage minimal and purge old exports/logs. – Keep integrations minimal (no heavy egress).

Exact cost depends on region and your tenancy’s Always Free eligibility. Verify using: – OCI Pricing: https://www.oracle.com/cloud/price-list/
– OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html

Example production cost considerations

For production, plan costs around: – Database capacity sized for peak concurrency and reporting – HA/DR requirements (multi-region replication, backups, standby patterns) – Security front doors (WAF) if internet-facing – Monitoring and log retention for compliance – Environment multiplication (dev/test/stage/prod)

10. Step-by-Step Hands-On Tutorial

This lab builds a real, small application using Oracle APEX on Oracle Cloud with a database-backed table, a report, and a form. It is designed to be safe and low-cost by using Always Free options where available.

This tutorial assumes you will use the Oracle Cloud Console experience commonly labeled APEX Application Development (managed APEX). If your tenancy only supports APEX via Autonomous Database, the app-building steps inside APEX are nearly identical, but provisioning steps differ. Verify the correct provisioning path in official docs: https://docs.oracle.com/en/cloud/paas/apex-service/

Objective

Provision Oracle APEX on Oracle Cloud, create a workspace, build a simple “Ticket Tracker” app (report + form), and validate that you can create/update records securely.

Lab Overview

You will: 1. Create (or select) an OCI compartment for the lab. 2. Provision an Oracle APEX instance (prefer Always Free if eligible). 3. Log in to APEX Administration Services and create a workspace. 4. Create a database table and sample data. 5. Build an APEX application using the Create App wizard. 6. Validate the app works. 7. Clean up resources to avoid costs.

Step 1: Prepare your Oracle Cloud environment (compartment and access)

Sign in to the Oracle Cloud Console.
Confirm you are in the correct region (top-right region selector).
Create a compartment for the lab (recommended): – Go to Identity & Security → Compartments – Click Create Compartment – Name: lab-apex – Description: Oracle APEX lab compartment – Click Create

Expected outcome: You have a dedicated compartment to isolate lab resources for governance and cleanup.

Verification: – You can navigate to the new compartment and it appears in the compartment picker.

Common issue: – If you cannot create compartments, you likely lack permissions. Ask your tenancy admin or use an existing compartment with appropriate privileges.

Step 2: Provision an Oracle APEX instance (managed service path)

In the OCI Console, navigate to the APEX service: – Typically: Developer Services → APEX Application Development
(Exact menu location may change—search for “APEX” in the console search bar.)
Click Create APEX Instance (or similar button).
Choose: – Compartment: lab-apex – Display name: apex-lab – Database / Always Free options: choose Always Free if available in your tenancy/region. – Admin credentials: set and store an admin password securely (follow password rules shown in the console).
Create the instance and wait for provisioning to complete.

Expected outcome: OCI creates an APEX instance and provides an APEX URL (the web endpoint).

Verification: – The instance status becomes Available (or equivalent). – You can open the APEX URL in a browser and see the login page.

Common issues and fixes: – Always Free capacity unavailable: Try a different region (if allowed) or provision paid resources. – Quota exceeded: Request quota increase or delete unused resources. – Password rejected: Follow complexity rules exactly (length, character classes, prohibited words).

Alternative path (if you don’t see APEX Application Development):
Provision an Autonomous Database, then launch APEX from the database tools. Use the Autonomous Database docs and “APEX” access instructions. Autonomous Database docs: https://docs.oracle.com/en/cloud/paas/autonomous-database/

Step 3: Log in as APEX admin and create a workspace

Open the APEX URL from your instance.
Log in to Administration Services (you may see a choice like “Administration Services” vs “App Builder” depending on setup). – Use the admin username provided by the provisioning workflow (often ADMIN) and the password you set.
Create a workspace: – Go to Manage Workspaces → Create Workspace – Workspace name: TICKET_LAB – Workspace type: choose the default option appropriate for your instance (often a new schema or existing schema) – Create a database user/schema for the workspace if prompted:
- Schema name: TICKET_SCHEMA
- Password: set a strong password (store it securely)
Finish workspace creation.

Expected outcome: You have a workspace that can create database objects and applications.

Verification: – Log out and log back in to the APEX URL, then choose App Builder and confirm you can select the TICKET_LAB workspace.

Common issues: – Workspace creation fails due to naming rules or password rules—adjust accordingly. – If you don’t have admin privileges, you may need the instance admin to create the workspace.

Step 4: Create the database table and insert sample data

In APEX, open SQL Workshop → SQL Scripts (or SQL Commands).
Run the following SQL to create a simple ticket table:

create table tickets (
  ticket_id      number generated by default as identity primary key,
  title          varchar2(200) not null,
  description    varchar2(4000),
  status         varchar2(30) default 'NEW' not null,
  priority       varchar2(10) default 'MEDIUM' not null,
  created_by     varchar2(128) default user not null,
  created_at     timestamp with local time zone default current_timestamp not null,
  updated_at     timestamp with local time zone
);

create index tickets_status_ix on tickets(status);
create index tickets_priority_ix on tickets(priority);

Insert a few rows:

insert into tickets (title, description, status, priority)
values ('Cannot login', 'User reports login failure after password reset', 'NEW', 'HIGH');

insert into tickets (title, description, status, priority)
values ('Update dashboard', 'Add filter by region', 'IN_PROGRESS', 'MEDIUM');

insert into tickets (title, description, status, priority)
values ('Data export needed', 'Need weekly export for finance', 'NEW', 'LOW');

commit;

Expected outcome: A TICKETS table exists with sample data.

Verification: Run:

select status, priority, count(*) as cnt
from tickets
group by status, priority
order by status, priority;

You should see aggregated counts.

Common issues: – “Insufficient privileges”: you may be in the wrong workspace/schema. Confirm the parsing schema and workspace schema mapping.

Step 5: Build the “Ticket Tracker” application using the Create App wizard

Go to App Builder → Create → New Application.
Name the application: Ticket Tracker.
Add a page: – Add Report page based on TICKETS. – Choose an Interactive Report (good for filtering/export) or Interactive Grid (good for editing). For this lab, start with an Interactive Report.
Add a second page: – Add Form page based on TICKETS to create/update tickets. – Ensure the form links from the report (wizard usually offers this).
Review application settings: – Authentication: keep default (often “APEX Accounts”) for the lab. – Theme: keep default.
Click Create Application, then Run Application.

Expected outcome: You can view tickets in a report and create/update tickets via a form.

Verification: – The report page loads and shows the 3 sample tickets. – Click into a ticket and update its status to IN_PROGRESS. – Return to report and confirm the updated status appears.

Common issues: – If the form doesn’t save, check required columns (TITLE, STATUS, PRIORITY) and defaults. – If you see “Page not found” errors, confirm the app creation completed and you launched the correct app ID.

Step 6 (Optional but recommended): Add a simple status validation and audit update

Add a lightweight data integrity rule so status values stay clean.

In SQL Workshop → SQL Commands, create a constraint:

alter table tickets add constraint tickets_status_ck
check (status in ('NEW','IN_PROGRESS','RESOLVED','CLOSED'));

Add an automatic timestamp on update:

create or replace trigger tickets_bu
before update on tickets
for each row
begin
  :new.updated_at := current_timestamp;
end;
/

Expected outcome: Status values are constrained; updates track UPDATED_AT.

Verification: – Try setting status to INVALID in the form; it should fail with a constraint error. – Update a ticket and confirm UPDATED_AT becomes non-null.

Common issues: – Trigger creation privileges should exist in your schema. If not, verify workspace schema permissions.

Step 7 (Optional): Expose a read-only REST endpoint (verify availability first)

Oracle APEX often works alongside ORDS for REST. Some managed deployments restrict ORDS administration.

If your environment supports it, you can use REST Enabled SQL or ORDS modules to expose a read-only endpoint. Because enablement differs across environments, verify in official docs and your APEX instance settings before attempting.

ORDS docs: https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/

A safe pattern is to not expose REST publicly in this lab unless you understand access control and network exposure.

Validation

Use this checklist:

[ ] OCI APEX instance status is Available
[ ] APEX URL is reachable over HTTPS
[ ] Workspace TICKET_LAB exists and you can open App Builder
[ ] TICKETS table exists and contains rows
[ ] “Ticket Tracker” app runs
[ ] You can create and update tickets
[ ] Constraint prevents invalid status values
[ ] UPDATED_AT updates on record changes

Troubleshooting

Issue: “403 Forbidden” or login redirect loop – Cause: cookie/session issues, or misconfigured domain/SSO. – Fix: clear site cookies for the APEX URL; try an incognito window; verify identity settings.

Issue: Provisioning stuck – Cause: capacity/quota issues. – Fix: check OCI notifications; try another region; confirm quotas.

Issue: App saves fail with generic error – Fix: – check browser console for details – open APEX developer toolbar (if available) – review APEX error logs / activity reports – verify table constraints/defaults and required columns

Issue: Slow report – Fix: – add indexes for filters – ensure report query is selective – avoid expensive functions on indexed columns without function-based indexes (advanced)

Cleanup

To avoid ongoing costs and to keep your tenancy clean:

In APEX: – Delete the “Ticket Tracker” application if you no longer need it. – Drop objects if desired:

drop table tickets purge;
drop trigger tickets_bu;

In OCI Console: – Terminate/delete the APEX instance (and underlying database resources if created separately). – Remove the lab-apex compartment only after all resources inside are deleted (OCI compartments cannot be deleted if they contain resources).

Expected outcome: No billable APEX/DB resources remain running from this lab.

11. Best Practices

Architecture best practices

Keep the database as the source of truth:
constraints (NOT NULL, CHECK)
foreign keys
normalized design where appropriate
Use views as stable query interfaces for reports.
Encapsulate business logic in PL/SQL packages for reuse and testability.
For multi-environment setups:
dev/test/prod separation (separate databases or at least separate schemas/workspaces)
consistent deployment pipeline (export app + versioned SQL scripts)

IAM/security best practices

Prefer least privilege:
don’t develop apps in powerful admin schemas
restrict workspace admin rights
Use authorization schemes for every non-trivial action (create/update/delete/admin pages).
Avoid putting secrets in application items or client-side code.
Use MFA and centralized identity where supported (OCI Identity Domains/federation).

Cost best practices

Right-size database capacity for:
concurrency
reporting complexity
peak usage windows
Use Always Free for sandboxes where eligible.
Shut down or delete unused environments.
Reduce data egress and uncontrolled exports.

Performance best practices

Index for your access paths (filters, joins).
Avoid N+1 query patterns (for example, per-row lookups in PL/SQL loops).
Use pagination and selective filters in reports.
Precompute expensive aggregates for dashboards (materialized views or summary tables where appropriate).

Reliability best practices

Use database backups and retention policies appropriate for your RPO/RTO.
Implement safe deploys:
apply DB migrations first (compatible changes)
deploy APEX app export next
Test upgrades and changes in staging.

Operations best practices

Monitor:
database CPU/storage utilization
top SQL
APEX errors/activity
Track changes:
use Git for APEX exports and SQL scripts
adopt release tagging and rollback strategy
Standardize naming and tagging in OCI:
include environment, owner, cost center in tags

Governance/tagging/naming best practices

Use compartments by environment and team (common OCI practice).
Tag resources:
env=dev|test|prod
app=ticket-tracker
owner=team-name
Document ownership and runbooks.

12. Security Considerations

Identity and access model

OCI IAM controls who can provision/manage APEX instances and related cloud resources.
APEX authentication controls who can sign into apps (APEX accounts or federated identity depending on configuration).
APEX authorization controls what authenticated users can do within the app:
page access
button/process execution
row-level access checks

Encryption

Data-at-rest encryption is typically provided by Oracle Database services in Oracle Cloud (verify exact guarantees for your service and region).
TLS (HTTPS) is used for client connections to APEX endpoints.
If you handle sensitive data, verify:
encryption configuration
key management options (OCI Vault integration patterns may vary)

Network exposure

Managed APEX endpoints are typically internet-accessible by default (service dependent).
If exposing to the internet:
enforce strong authentication
restrict access where possible (IP allowlists if supported; otherwise via front-door controls)
consider a WAF pattern for external-facing portals (verify compatibility with your APEX endpoint approach)

Secrets handling

Avoid hardcoding secrets in:
application items
PL/SQL packages
JavaScript
Prefer secure credential storage patterns supported by APEX (for example, APEX credential features) and/or retrieve short-lived tokens from trusted services.
If integrating with OCI Vault, design a secure retrieval pattern and verify supported connectivity.

Audit/logging

Use:
OCI Audit (for cloud resource changes)
APEX activity monitoring for app usage and error tracking
database auditing options for sensitive tables (implementation depends on your database service)

Compliance considerations

Oracle APEX can support compliance needs, but compliance is not automatic: – Define data classification and access policies. – Implement logging and retention. – Use least privilege and separation of duties. – Validate the compliance posture of the underlying OCI region and services (industry certifications vary by region/service).

Common security mistakes

Building apps in a schema with excessive privileges.
Missing authorization checks on “admin” pages or processes.
Trusting client-side values (hidden items) without server-side validation.
Exposing data via reports without row-level access controls.
Writing dynamic SQL without bind variables (SQL injection risk).

Secure deployment recommendations

Use separate schemas for:
application owner
data access logic (optional)
Apply defense-in-depth:
constraints + authorization schemes + auditing
Threat model external-facing apps:
brute-force protection
session management rules
rate limiting/front-door protections (as supported)

13. Limitations and Gotchas

The exact limitations depend on whether you use managed APEX service, Autonomous Database tooling, or self-managed APEX/ORDS. Always validate against your service documentation and tenancy limits.

Common limitations / gotchas

Service availability varies by region (APEX service presence and Always Free capacity).
Always Free limits can restrict:
number of instances
compute/storage
concurrent capacity expectations
SSO integration details vary:
OCI IAM Identity Domains configuration may require specific setup and may not be identical across environments.
Outbound network access for calling external APIs may have restrictions depending on service networking model.
Large exports can hit performance and egress costs.
APEX app exports are SQL scripts:
great for deployments, but you must manage versioning and rollbacks intentionally.
Database design still matters:
low-code doesn’t remove the need for indexes, constraints, and SQL tuning.
Multi-tenancy inside APEX (workspaces) is not a replacement for true environment isolation:
for prod, prefer separate environments/databases.

Migration challenges

Migrating from non-Oracle stacks to APEX is easiest when:
data model is well-defined
business rules can move into PL/SQL and constraints
Migrating APEX apps between environments requires careful handling of:
workspace IDs
credentials/integrations
environment-specific URLs

Vendor-specific nuances

Oracle APEX is tightly coupled to Oracle Database features and release cadence.
Managed service operational controls differ from self-managed installations (some knobs are abstracted away).

14. Comparison with Alternatives

How Oracle APEX compares

Oracle APEX is best viewed as: – a low-code platform deeply integrated with Oracle Database – optimized for data-centric enterprise applications

Below are common alternatives and when to choose them.

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle APEX (Oracle Cloud)	Data-centric apps on Oracle Database	Fast delivery, strong reporting, DB security, low ops overhead in managed modes	Not a full SPA framework by default; DB-centric mindset required	You want rapid CRUD/reporting/workflow apps on Oracle Database
Oracle Visual Builder (Oracle Cloud)	Low-code with more UI-centric app patterns	Visual UI design, integrations (product-dependent)	Different strengths than APEX; may not match DB-first approach	You need UI-centric low-code and your architecture aligns with Visual Builder
Custom app on OCI (Functions/OKE/Compute) + DB	Full control and custom UX	Any framework, microservices, custom scaling	Higher engineering/ops cost	You need complex custom UX or non-standard runtime requirements
APEX self-managed (on Oracle Database + ORDS)	Maximum control over runtime	Control patching/networking; fits regulated environments	You operate and secure more components	You need on-prem/hybrid control or specific runtime constraints
Microsoft Power Apps	Citizen dev in Microsoft ecosystem	Fast internal apps, M365 integration	Data model/logic constraints; licensing differs	You’re standardized on Microsoft and apps are M365/Dataverse-centric
Google AppSheet	Simple mobile/web apps, spreadsheet-like workflows	Fast no-code delivery	Complex enterprise governance can be harder	You need quick forms/workflows with minimal engineering
Mendix / OutSystems	Enterprise low-code at scale	Rich low-code ecosystem, strong UI	Platform licensing and governance complexity	You want broad low-code platform features beyond DB-first development
Django/Rails/Laravel (self-managed)	Traditional web apps	Full control, huge ecosystems	Slower delivery for CRUD/reporting; ops burden	You need open-source stack control and custom architecture freedom

15. Real-World Example

Enterprise example: Compliance Evidence Portal

Problem: A regulated enterprise needs an auditable portal for collecting compliance evidence across departments, replacing email and shared folders.
Proposed architecture:
Oracle APEX (Oracle Cloud) for the portal UI
Autonomous Database for evidence metadata, workflow state, and audit trails
Optional Object Storage for large attachments (integration pattern depends on your org’s standards; verify best approach)
OCI IAM Identity Domains (or federated IdP) for SSO and MFA (verify supported integration)
OCI Audit + database auditing for governance
Why Oracle APEX was chosen:
Rapid development with strong authorization controls
Database-enforced integrity and reporting for auditors
Managed operations reduce platform overhead
Expected outcomes:
Reduced audit cycle time
Clear ownership and traceability
Fewer security risks from uncontrolled file sharing

Startup / small-team example: Operations Console for Customer Onboarding

Problem: A small SaaS team needs an internal console to manage onboarding steps and customer configuration stored in Oracle Database.
Proposed architecture:
Oracle APEX app with forms and interactive reports
Autonomous Database Always Free for dev/test (if eligible), then scale up for production
REST integrations to the SaaS backend for provisioning actions (where supported)
Why Oracle APEX was chosen:
Small team can ship quickly without building a full admin front end
Strong reporting and search over onboarding records
Expected outcomes:
Faster onboarding turnaround
Reduced manual errors
A maintainable internal tool with minimal ops overhead

16. FAQ

1) Is Oracle APEX the same as “APEX Application Development” in Oracle Cloud?

Oracle APEX is the product. In the OCI Console, the managed service experience is commonly labeled APEX Application Development. The underlying development experience is Oracle APEX.

2) Do I need to know PL/SQL to use Oracle APEX?

Not for basic CRUD apps and reports, but PL/SQL is very useful for: – validations – business rules – integrations – performance tuning and reusable logic

3) Where is my application stored?

APEX application definitions are stored in Oracle Database tables (metadata-driven). Your data is stored in your schemas in the same database.

4) Is Oracle APEX suitable for production?

Yes, Oracle APEX is widely used in production for internal and external apps. Production success depends on good database design, security configuration, and disciplined deployments.

5) How do I separate dev/test/prod?

Common approaches: – separate OCI environments (compartments/tenancies) and separate databases – separate APEX instances/workspaces for environments
For strong isolation, prefer separate databases.

6) How do I deploy changes?

Use APEX Export/Import for the application and version-controlled SQL scripts for schema changes. Build a repeatable release process.

7) Can Oracle APEX integrate with external APIs?

Yes, APEX can call REST services (capabilities depend on APEX version and configuration). For exposing APIs, ORDS is a common approach. Verify exactly what’s enabled in your Oracle Cloud APEX deployment.

8) Does Oracle APEX support SSO?

APEX supports multiple authentication approaches, and in Oracle Cloud you may integrate with OCI Identity Domains or other IdPs depending on supported configurations. Verify the exact supported SSO method in APEX service docs for your environment.

9) Can I build mobile apps with APEX?

APEX builds responsive web apps that work on mobile browsers. For native mobile apps, consider additional approaches (or a different platform) depending on requirements.

10) What are the most common performance bottlenecks?

inefficient SQL (full table scans, missing indexes)
heavy reports over large datasets without filters/pagination
too much per-row PL/SQL logic
unoptimized data models

11) How do I handle row-level security?

Use authorization schemes and enforce row-level filters in queries/views. For stronger guarantees, implement database-enforced security patterns (views, policies, application contexts) appropriate to your design.

12) Is Oracle APEX “no code”?

It’s best described as low-code. Many applications can be built declaratively, but real-world apps often require SQL/PL/SQL and some JavaScript.

13) Can Oracle APEX run without Oracle Cloud?

Yes. Oracle APEX can run anywhere Oracle Database runs (on-premises, other clouds), but you must manage infrastructure and ORDS/web tier if not using a managed Oracle Cloud service.

14) What’s the safest way to start?

Start with a small internal app: – define a table with constraints – create a report + form – implement authorization and auditing early Then scale patterns to larger apps.

15) How do I estimate cost for an APEX app in OCI?

Estimate based on: – database compute and storage – environments (dev/test/prod) – egress and logging retention
Use the official OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html

16) Can multiple apps share the same APEX instance?

Yes. APEX instances can host multiple workspaces and applications. Use workspaces/schemas to separate teams/apps where appropriate.

17) What’s the difference between a workspace and a schema?

A schema is a database namespace/owner for objects (tables, views). A workspace is an APEX concept that maps to one or more schemas and isolates APEX development and apps.

17. Top Online Resources to Learn Oracle APEX

Resource Type	Name	Why It Is Useful
Official documentation	Oracle APEX Documentation	Core concepts, Builder guides, security and administration. https://docs.oracle.com/en/database/oracle/apex/
Official OCI service docs	APEX Application Development on OCI	Provisioning, service behavior, instance/workspace management. https://docs.oracle.com/en/cloud/paas/apex-service/
Official database docs	Oracle Autonomous Database Documentation	Common deployment base for APEX on Oracle Cloud. https://docs.oracle.com/en/cloud/paas/autonomous-database/
Official REST layer docs	Oracle REST Data Services (ORDS) Documentation	REST enablement and HTTP gateway patterns. https://docs.oracle.com/en/database/oracle/oracle-rest-data-services/
Official pricing	Oracle Cloud Price List	Authoritative pricing reference (region/SKU dependent). https://www.oracle.com/cloud/price-list/
Official calculator	OCI Cost Estimator	Build cost scenarios without guessing. https://www.oracle.com/cloud/costestimator.html
Free tier	Oracle Cloud Free Tier	Always Free eligibility and onboarding. https://www.oracle.com/cloud/free/
Official architecture references	Oracle Cloud Solutions / Architecture Center	Reference architectures and patterns (search for APEX/ADB patterns). https://docs.oracle.com/en/solutions/
Official labs	Oracle LiveLabs	Hands-on labs; search for APEX and Autonomous Database. https://livelabs.oracle.com
Official community/blog	Oracle APEX Blog	Product updates and practical patterns from Oracle. https://blogs.oracle.com/apex/
Samples/community	apex.oracle.com (APEX community)	Examples, forums, and shared apps; validate guidance against docs. https://apex.oracle.com/

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	Developers, DevOps/SRE, platform teams	Cloud + DevOps practices that can complement APEX delivery and operations	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Engineers and managers	SDLC, tooling, and delivery practices (useful for APEX CI/CD governance)	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers and operators	Cloud operations concepts relevant to Oracle Cloud environments	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, reliability engineers	Reliability/observability practices applicable to APEX-backed services	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops and automation teams	AIOps concepts for monitoring/incident response (adjacent skills)	Check website	https://www.aiopsschool.com/

Note: Oracle APEX certifications and official training are typically offered via Oracle University. Verify current certification availability and exam names at: https://education.oracle.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	General technical training platform/site (verify offerings)	Learners seeking guided training resources	https://rajeshkumar.xyz/
devopstrainer.in	DevOps-focused training (adjacent to APEX delivery pipelines)	DevOps engineers supporting APEX deployments	https://devopstrainer.in/
devopsfreelancer.com	Freelance DevOps/support services (verify scope)	Teams needing delivery/ops help around cloud projects	https://www.devopsfreelancer.com/
devopssupport.in	Support/training services (verify scope)	Ops teams needing support for cloud tooling	https://www.devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify offerings)	Architecture review, delivery automation, operations support	CI/CD setup for database + APEX exports; environment governance	https://cotocus.com/
DevOpsSchool.com	DevOps/Cloud consulting (verify offerings)	DevOps processes, platform engineering practices	Release pipelines, infrastructure governance, monitoring approach	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify offerings)	Delivery and operations enablement	Standardizing deployment workflows and ops runbooks	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Oracle APEX

SQL fundamentals (joins, aggregates, indexes)
Relational data modeling (keys, normalization, constraints)
Basic web concepts (HTTP, cookies, authentication vs authorization)
Oracle Cloud fundamentals:
compartments, IAM, policies
regions
basic cost management concepts

What to learn after Oracle APEX

Oracle Database performance tuning:
execution plans
indexing strategies
bind variables
Secure application design in APEX:
authorization patterns
session state protection concepts
DevOps for APEX:
exporting apps
version control (Git)
automated schema migrations
Identity federation (OCI IAM Identity Domains, OIDC/SAML concepts) where relevant

Job roles that use Oracle APEX

Oracle APEX Developer
Oracle Database Developer (with APEX)
Application Developer (internal tools)
Solutions Architect (Oracle Cloud + Oracle Database)
Platform Engineer/DevOps Engineer supporting Oracle workloads
Data Engineer building operational data apps

Certification path (if available)

Oracle’s certification catalog changes. For the latest: – Check Oracle University: https://education.oracle.com/
Look for: – Oracle Cloud Infrastructure certifications (foundational to deploying APEX on OCI) – Any current APEX-specific certification offerings (verify availability and version alignment)

Project ideas for practice

Asset inventory app (CRUD + role-based access)
Approval workflow app (status transitions + audit)
Data quality tool (interactive grid + validations)
Customer onboarding portal (multi-step form + reporting)
“Self-service export” portal with governance controls
Incident tracker with SLA calculations (PL/SQL + scheduled jobs)

22. Glossary

Oracle APEX: Oracle Application Express, a low-code platform for building web apps on Oracle Database.
OCI (Oracle Cloud Infrastructure): Oracle Cloud platform for compute, networking, storage, and managed services.
APEX Application Development: Common OCI console label for the managed APEX service experience.
Workspace: An APEX logical environment that contains apps and maps to one or more database schemas.
Schema: A database namespace/owner for objects (tables, views, packages).
ORDS: Oracle REST Data Services, commonly used as the HTTP gateway for APEX and REST APIs.
Autonomous Database (ADB): Managed Oracle Database service in Oracle Cloud with automated operations.
Interactive Report: APEX component enabling end-user filtering, sorting, grouping, and exporting.
Interactive Grid: APEX component for editable, spreadsheet-like data interaction.
Authentication: Proving who a user is (login).
Authorization: Determining what an authenticated user can access/do.
Least privilege: Security principle of granting only required permissions.
Egress: Network data leaving a cloud provider to the internet/other networks; often billable.
Compartment: OCI resource isolation boundary for organizing and controlling access.
OCI Audit: OCI service that records API calls and administrative events for governance.

23. Summary

Oracle APEX on Oracle Cloud is a practical, database-centric Application Development service for building secure web applications quickly—especially when your data is (or should be) in Oracle Database. Architecturally, APEX runs as a metadata-driven engine served over HTTPS (often via ORDS) with Oracle Database executing the SQL/PL/SQL that powers your app.

Cost is typically driven by the underlying database resources (compute/storage), plus indirect costs like logging retention and network egress. Security hinges on disciplined authorization, least privilege, safe SQL/PL/SQL, and appropriate identity integration (often via OCI IAM/Identity Domains, depending on supported configurations).

Use Oracle APEX when you need rapid delivery of CRUD/reporting/workflow apps with strong database foundations and manageable operations. Your next step is to repeat the lab with a dev/test/prod structure, adopt version control for APEX exports and schema scripts, and review the official Oracle APEX and OCI APEX service documentation to align with your environment’s exact capabilities: – https://docs.oracle.com/en/cloud/paas/apex-service/ – https://docs.oracle.com/en/database/oracle/apex/

rajeshkumar

Category