🧱 Oracle APEX — RAD Web pur, Database-centric (Oracle Database)

Décision (checklist “go / no-go”)

Scale / HA pattern

[Load Balancer]
   |------> [ORDS node #1]
   |------> [ORDS node #2]
   |------> [ORDS node #N]
                |
                v
          [Oracle DB HA]
          - RAC / Data Guard / backups testés
        

Isolation (multi-apps) — pattern PDB

CDB
  - PDB_APP_HR   (APEX workspace HR, ORDS pool HR)
  - PDB_APP_FIN  (workspace FIN, ORDS pool FIN)
  - PDB_APP_OPS  (workspace OPS, ORDS pool OPS)
=> isolation workloads + tuning indépendant
        

Anatomie d’une “page pro” (minimum viable production)

Lifecycle d’une requête (vue “debuggable”)

1) Browser GET / page request
2) ORDS -> DB -> APEX runtime
3) APEX resolve metadata -> render regions
4) User POST submit (items + changes)
5) Validations
6) Processes (PL/SQL)
7) Commit/rollback
8) Branch -> next page
        

Patterns “qui tiennent la route”

Tables:
- T_ENTITY (PK, cols, created_at, created_by, updated_at, updated_by)
- T_AUDIT (entity, entity_id, action, actor, payload, ts)

APEX:
- List page (IR/IG)
- Form page (create/edit)
- Processes call pkg_entity.save(...)
- Authorization by role + row-level policy
            

Views:
- V_PORTAL_SEARCH (denormalized read model)

APEX:
- Faceted Search region
- Report region bound to V_PORTAL_SEARCH
- “Details” modal dialog page
- Export async si volumétrie

Perf:
- indexes sur colonnes filtrées
- pagination keyset si nécessaire
            

Reports (tuning-ready)

Bonnes pratiques :
- SQL “read model” (vues dédiées)
- colonnes utiles, éviter select *
- pagination / fetch
- filtres indexés
- éviter les fonctions non sargables sur colonnes filtrées
- agrégats pré-calculés si besoin (MV)
        

Forms & DML

- region form (table / view)
- validations (client/server)
- process:
    pkg_entity.validate(...)
    pkg_entity.save(...)
- messages standardisés
- authorization scheme (role + row-level)
            

- DML direct dans 10 process
- validations différentes par page
- logique métier dans dynamic actions
=> incohérences, maintenance impossible
            

Search UX (facets / smart filters)

Best practice :
- construire une vue V_SEARCH (read model)
- index sur colonnes filtrées
- faceted search + report list
- page details en modal
- export asynchrone si > 100k rows
        

Write path (robuste)

Option A — Automatic DML (APEX)
- simple, rapide
- OK si règles métier simples

Option B — Custom DML (recommandé si domain)
- process IG -> appelle pkg_domain.apply_changes(...)
- gère :
   - validations domain
   - erreurs standardisées
   - audit
   - concurrency (row version)
        

T_ENTITY
- id PK
- row_version number

Update:
WHERE id = :id AND row_version = :row_version;
IF SQL%ROWCOUNT=0 THEN conflict;
row_version := row_version + 1;
            

pkg_audit.log(
  p_entity => 'T_ENTITY',
  p_action => 'UPDATE',
  p_actor  => :APP_USER,
  p_payload=> json_object(...)
);
            

Validation (3 niveaux)

Pièges (les vrais)

• Locks : édition concurrente sur mêmes lignes → pense row_version / conflict.
• Volumétrie : IG n’est pas fait pour afficher 500k lignes en “scroll infini” sans stratégie.
• DML implicite : si tu relies IG à une vue complexe, attention à updatability.
• Validation : erreurs doivent remonter proprement (messages user + corrId).
• Security : authorization scheme sur page/region + row-level policy en DB si sensible.

Authentication — stratégies

Golden rule :
- Auth = “qui es-tu”
- AuthZ = “as-tu le droit”
Ne pas confondre. Ne pas mettre la logique de droit dans Auth.
        

Authorization — RBAC + row-level

Attacher des schemes à :
- pages
- regions
- buttons
- processes
- menu entries

Ex: ROLE_ADMIN, ROLE_MANAGER, ROLE_USER
            

Données sensibles = contrôle en DB :
- vues filtrées par :APP_USER
- ou policy (selon approche)
APEX AuthZ ne doit pas être le seul rempart.
            

Session management — durcissement

Session State Protection (SSP) — le “must” APEX

Objectif :
- empêcher la manipulation d'items via URL / client tampering
- protéger le session state

Mise en place (standard) :
1) activer SSP (application-level)
2) configurer page & item protection (wizard ou manuel)
3) tester : tampering -> rejet / erreurs attendues
        

- prends une URL page?PXX_ID=123
- modifie en 999999
- résultat attendu :
   - refus
   - ou page non autorisée
   - ou item ignoré selon config
            

Browser security — “hardening web”

Mesures typiques (selon policy entreprise) :
- headers (HSTS, X-Frame-Options, etc.)
- CSP (Content Security Policy) si possible
- protection XSS via réglages APEX + sanitation
- upload hardening (types, taille, scanning)
- rate limiting (reverse proxy)
        

Checklist sécurité “prod”

1. Auth : SSO si possible, sinon comptes & politique mots de passe.
2. AuthZ : schemes sur pages/regions/actions + audit admin.
3. SSP : activé + items sensibles protégés + tests tampering.
4. Session : timeouts + rejoin policy + TLS only.
5. DB : least privilege schémas + packages domain, pas de droits inutiles.
6. ORDS : TLS, pools, patching, logs, alerting.
7. Ops : exports versionnés (traçabilité).

SQL patterns utiles

SELECT  *
FROM    v_search
WHERE   (created_at, id) < (:last_created_at, :last_id)
ORDER BY created_at DESC, id DESC
FETCH FIRST :page_size ROWS ONLY;
            

CREATE OR REPLACE VIEW v_search AS
SELECT
  e.id,
  e.status,
  e.type,
  e.created_at,
  u.display_name owner_name,
  (SELECT COUNT(*) FROM t_child c WHERE c.e_id = e.id) child_cnt
FROM t_entity e
JOIN t_user u ON u.id = e.owner_id;
            

Pages “light” : règle d’or

- 1 page = 1 objectif
- 1 région lourde max
- reports lourds -> pages dédiées
- details -> modal dialog
- lazy loading / partial refresh quand possible
        

ORDS sizing (conceptuel)

Pool trop petit -> files d'attente, latence
Pool trop grand -> DB saturée (CPU/locks), instabilité

Approche :
- partir petit
- mesurer (latence/p95, 5xx, pool wait)
- ajuster selon workload
- séparer pools par app si besoin
        

KPI run (minimum)

App:
- p95 page render (pages clés)
- p95 report query time
- error rate (validation, 5xx)

DB:
- top SQL by elapsed time
- waits (IO/CPU/locks)
- parse/execute ratio

ORDS:
- pool utilization
- request rate
- 5xx spikes / timeouts
        

Modes de déploiement (génériques)

REST contracts (anti lock-in / intégrations)

Approche recommandée :
- endpoints versionnés (/v1/...)
- DTO stables (JSON)
- erreurs standardisées (code + message + corrId)
- auth (SSO / tokens) selon policy
- rate limit + audit
        

Hardening ORDS

• TLS obligatoire, certificats gérés proprement.
• Rate limiting au reverse proxy (protection brute force).
• Logs centralisés + corrId.
• Limiter endpoints exposés (pas d’API “ouverte” involontaire).
• Patching régulier (ORDS & JVM).

Service layer PL/SQL (clean)

pkg_domain_entity
- function can_access(p_user, p_id) return boolean;
- procedure validate(p_dto in out nocopy ...);
- procedure create(p_dto..., p_id out ...);
- procedure update(p_dto...);
- procedure delete(p_id...);

APEX pages:
- processes appellent pkg_domain_entity.*
- UI reste thin
        

Read-models (vues dédiées)

V_SEARCH :
- denormalized, report friendly
- contient champs filtre/tri
- évite joins multi-pages

Avantages :
- SQL plus simple côté APEX
- tuning plus facile
- stabilité & perf
        

Contrat d’erreurs (standardiser)

Error contract (suggestion) :
- code : VALIDATION | AUTH | CONFLICT | TECH
- user_message : message affichable
- tech_message : logs
- corr_id : id corrélation

APEX :
- afficher user_message
- logger tech_message + corr_id
        

Artifacts (ce que tu versions)

Repo Git :
/db
  - migrations.sql (ou outils)
  - packages/*.sql
  - views/*.sql
  - seed/*.sql
/apex
  - app_export.sql
  - static_files/ (images, css, js)
  - env_config/ (substitutions)
/ops
  - ords-config.md
  - runbooks.md
        

Pipeline minimal (prod-like)

1) Build DB
   - apply migrations
   - compile packages
   - smoke SQL checks

2) Import APEX app
   - import app_export.sql
   - set substitutions

3) Smoke tests
   - login + 3 pages clés
   - SSP tampering test
   - 1 write path test

4) Deploy/Reload ORDS config (si besoin)
5) Monitor KPI post-release (p95, 5xx)
        

Rollback (très concret)

Rollback plan :
- APEX app export N-1
- DB rollback (si possible) ou restore snapshot
- ORDS config rollback
- validation smoke tests
        

HA : ce qu’on oublie souvent

• Tests de failover (DB) planifiés.
• Compatibilité ORDS/APEX/DB lors d’upgrade.
• Sessions : policies + timeouts (éviter effets de bords lors de failover).
• Capacity planning : pool ORDS vs sessions DB.

Patching cadence

Ordre (générique) :
1) environnements non-prod
2) ORDS upgrade (si requis) + tests
3) APEX upgrade (si requis) + tests
4) DB patches (selon politique)
5) prod avec rollback
        

Backups : “testés” sinon inutiles

- snapshots DB (selon infra)
- exports APEX versionnés
- exports ORDS config
- restore drills (trimestriels)