Sviluppo software APEX: la guida Oracle APEX 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Lo sviluppo software APEX è la pratica di creare applicazioni web aziendali con Oracle APEX (Application Express), una piattaforma low-code che risiede all’interno di Oracle Database. Sul mercato statunitense l’espressione si riferisce quasi sempre a Oracle APEX e non ad Apex, il linguaggio di programmazione della piattaforma Salesforce: i due condividono il nome e nient’altro, e la sezione di confronto più sotto li distingue in un’unica tabella.

La maggior parte delle organizzazioni non arriva ad APEX perché desidera un nuovo strumento. Ci arriva perché un patrimonio Oracle Forms sta invecchiando, è in scadenza un aggiornamento di WebLogic oppure processi critici girano su fogli di calcolo e database Access di cui nessuno vuole farsi carico. Questo rende APEX una decisione di modernizzazione prima ancora che una scelta di strumenti, ed è per questo che i team che offrono servizi di modernizzazione delle applicazioni legacy partono di solito da un inventario di ciò che esiste, di quali dati contano e di quali schermate si possono dismettere, e solo dopo scelgono tra APEX, codice su misura o una combinazione dei due.

Questa guida spiega che cos’è Oracle APEX e come funziona, cosa è cambiato con le release 26.1 e 26.2 del 2026, i casi d’uso tipici, cosa includono i servizi di sviluppo, il processo di delivery passo per passo, la migrazione da Oracle Forms ad APEX, il confronto con altre piattaforme low-code e con il codice su misura, i costi, i casi in cui APEX è la scelta sbagliata, la sicurezza e una checklist per scegliere una società di sviluppo software Oracle APEX.

Che cos’è lo sviluppo software APEX?

Lo sviluppo software APEX consiste nel creare applicazioni web su Oracle APEX, una piattaforma low-code in cui pagine, form, report, grafici e workflow vengono assemblati in modo dichiarativo e memorizzati come metadati all’interno di Oracle Database. La logica di business si scrive in SQL e PL/SQL, i linguaggi nativi del database, e gli sviluppatori aggiungono JavaScript, CSS o chiamate REST solo dove i componenti dichiarativi non bastano.

Oracle APEX si chiamava in precedenza Oracle Application Express ed è una funzionalità di Oracle Database senza costi aggiuntivi dal 2004. Secondo la pagina prodotto di Oracle, non ci sono canoni separati per sviluppatore, per applicazione o per utente finale: se si dispone di un Oracle Database supportato, si possono creare ed eseguire applicazioni APEX su di esso. Questo modello di prezzo è uno dei motivi principali per cui lo sviluppo software Oracle APEX è diffuso nelle organizzazioni che già pagano Oracle.

Una tipica applicazione APEX è composta da alcuni elementi costitutivi che ogni sviluppatore Oracle riconosce:

• Interactive Reports e Interactive Grid per tabelle di dati ricercabili, filtrabili e modificabili.
• Form e wizard generati da tabelle o viste, con validazioni e calcoli.
• Dynamic Actions che aggiungono comportamenti lato client (mostrare, nascondere, aggiornare, richiamare PL/SQL) senza JavaScript scritto a mano.
• Grafici, calendari, mappe e ricerca a faccette per dashboard ed esplorazione self-service.
• Approvazioni, workflow e automazioni per processi aziendali in più fasi e job pianificati.
• Sorgenti dati REST e REST-enabled SQL per consumare ed esporre API.

Come funziona Oracle APEX dietro le quinte

Oracle APEX non ha un livello separato di application server: la definizione dell’applicazione è memorizzata come metadati in tabelle del database, e Oracle REST Data Services (ORDS) fa da web listener che inoltra le richieste del browser al motore APEX all’interno del database. Quando un utente apre una pagina, il motore legge la definizione della pagina, esegue l’SQL e il PL/SQL a cui fa riferimento e restituisce l’HTML al browser tramite ORDS.

Questa architettura ha conseguenze pratiche. I dati non lasciano mai il database per essere elaborati in un livello intermedio, quindi le schermate ad alta intensità di dati sono veloci e il modello di sicurezza del database si applica a ogni query. Il deployment è più semplice perché non c’è un application server Java o .NET da aggiornare, e un’applicazione può essere esportata, versionata e importata come un’unica unità. Il rovescio della medaglia è l’accoppiamento stretto: un’applicazione APEX è, per definizione, un’applicazione Oracle Database.

Chi sviluppa con APEX

Con APEX lavorano soprattutto tre gruppi: sviluppatori PL/SQL e di database che conoscono già il modello dati, reparti IT incentrati su Oracle che devono consegnare rapidamente strumenti interni e citizen developer lato business che operano sotto la governance dell’IT. Il filo conduttore è l’SQL. Uno sviluppatore che scrive buon SQL e PL/SQL può diventare produttivo in APEX nel giro di poche settimane, mentre uno sviluppatore front-end senza esperienza di database troverà la curva di apprendimento più ripida di quanto suggerisca l’etichetta «low-code».

Per i sistemi in produzione, i team più efficaci affiancano agli specialisti APEX un esperto di prestazioni del database e, quando l’interfaccia conta, uno sviluppatore front-end che conosce lo Universal Theme. I citizen developer sono produttivi per prototipi e strumenti di reparto, ma le applicazioni enterprise richiedono comunque code review, test e un piano di aggiornamento come qualsiasi altro software.

Oracle APEX o Salesforce Apex: di quale «APEX» si parla?

Oracle APEX è una piattaforma low-code per creare applicazioni web su Oracle Database, mentre Salesforce Apex è un linguaggio di programmazione proprietario e fortemente tipizzato per la logica di business sulla piattaforma Salesforce. I risultati di ricerca per «apex software development» mescolano entrambi, insieme ad aziende che si chiamano Apex senza alcun legame, quindi conviene verificare a quale dei due si riferiscano davvero un annuncio di lavoro, un fornitore o una proposta.

Se il Suo progetto riguarda in realtà Salesforce, la nostra guida ai servizi di consulenza Salesforce e la pagina sull’integrazione Salesforce sono i punti di partenza migliori. Il resto di questo articolo tratta Oracle APEX.

Quali sono le novità di Oracle APEX nel 2026 (26.1 e 26.2)?

Le release del 2026 spostano Oracle APEX verso un’IA governata e uno sviluppo compatibile con git: la 26.1 ha introdotto APEXlang, AI Agents e AI Interactive Reports, mentre la 26.2 ha reso APEXlang utilizzabile file per file e ha integrato APEX con Oracle Deep Data Security. Per i team che pianificano nuovi progetti di sviluppo software APEX nel 2026, queste due release cambiano il modo in cui le applicazioni vengono versionate, revisionate e protette.

Secondo l’annuncio di Oracle sulla 26.1, la release è disponibile on-premises su tutte le distribuzioni di Oracle AI Database (Exadata, Linux e Windows), con i servizi OCI e multicloud a seguire. Il partner Oracle Pretius descrive la 26.1 come la prima release APEX importante dopo circa diciotto mesi e riassume l’impostazione di Oracle sull’IA governata con la formula «If you generate it, you own it» (se lo generi, ne sei responsabile). I dettagli della 26.2 provengono dall’annuncio di Oracle sulla 26.2; Oracle ha ripubblicato i file di download il 9 ottobre 2026 e mantiene una pagina dei problemi noti che vale la pena leggere prima di un aggiornamento.

APEXlang e controllo di versione

APEXlang trasforma un’applicazione APEX in file leggibili e versionabili, il che significa che il lavoro su APEX può finalmente passare attraverso gli stessi branch git, la stessa code review e la stessa pipeline CI/CD del resto del Suo software. Prima di APEXlang i team esportavano l’intera applicazione come un unico grande script SQL, per cui due sviluppatori che modificavano pagine diverse producevano esportazioni in conflitto e le revisioni confrontavano codice generato dalla macchina.

APEX 26.2 completa il quadro con l’importazione a livello di file: una singola pagina o un componente condiviso può essere esportato e importato come file .apx, e il builder può confrontare un file con l’applicazione e importare solo le modifiche. In pratica ciò consente a più sviluppatori di lavorare in parallelo sulla stessa applicazione, rende significativi i diff nelle merge request e permette a una pipeline di distribuire solo ciò che è cambiato. Per un team di sviluppo software Oracle APEX, è il cambiamento di processo più importante del 2026.

AI Agents e AI Interactive Reports

Gli AI Agents di APEX sono assistenti che agiscono solo attraverso strumenti esplicitamente approvati da uno sviluppatore, e gli AI Interactive Reports consentono agli utenti di rimodellare un report in linguaggio naturale su dati che sono già autorizzati a vedere. L’obiettivo progettuale è un’IA governata: il modello suggerisce, ma ogni azione e ogni riga di dati passa attraverso i controlli di APEX e del database definiti dal team di sviluppo.

APEX 26.2 ha ampliato la scelta dei modelli con il supporto per la OpenAI Responses API, Google Gemini Interactions e OCI Generative AI, ha aggiunto un’impostazione Reasoning Effort per gli AI Agents e ha introdotto le identità gestite per i servizi OCI, così le credenziali non devono essere memorizzate nell’applicazione. L’aggiornamento degli Interactive Reports nella stessa release ha aggiunto filter chip, filtri a selezione multipla nelle intestazioni e colonne calcolate descritte in linguaggio naturale. Se prevede di inserire funzioni di IA in applicazioni aziendali anche al di fuori di APEX, il nostro team si occupa di integrazione dell’IA generativa su stack diversi.

Cosa non è cambiato nel 2026

Le release del 2026 non hanno cambiato i fondamenti di APEX: resta una piattaforma Oracle Database, ancora incentrata sulle competenze SQL e PL/SQL, e ancora con un ritmo di rilascio rapido che richiede aggiornamenti regolari. Le organizzazioni che cercano indipendenza dal database o uno stack JavaScript-first non la troveranno in APEX 26.x.

Il ritmo degli aggiornamenti va pianificato. Come DSP riassume la politica di supporto di Oracle, sono supportate solo le due release APEX più recenti, ciascuna per circa 18 mesi dalla disponibilità generale; secondo questo calendario la 24.2 è supportata fino a luglio 2027 circa e la 26.1 fino a novembre 2027 circa. In pratica, un’applicazione APEX ha bisogno di un aggiornamento circa una volta l’anno per restare su una release supportata.

Cosa si può costruire con Oracle APEX?

Oracle APEX è ideale per applicazioni aziendali incentrate sui dati, quando i dati risiedono già in Oracle Database e gli utenti devono cercarli, modificarli, approvarli e farne report. Sette casi d’uso coprono la maggior parte dei progetti reali:

• App aziendali interne e di back office: applicazioni CRUD per ordini, asset, contratti, magazzino o gestione delle pratiche sopra tabelle esistenti.
• App di approvazione e workflow: richieste di acquisto, approvazioni di modifiche e flussi di onboarding con approvazioni integrate, liste di attività e notifiche email.
• Dashboard e reportistica BI leggera: grafici, KPI e report self-service sui dati operativi senza una licenza BI separata per ogni utente.
• Estensioni di Oracle E-Business Suite e Oracle Fusion: schermate e processi che l’ERP non copre, costruiti accanto ai dati di EBS o sui dati di Fusion tramite REST, senza personalizzare l’ERP stesso.
• Sostituzioni di Oracle Forms, Access ed Excel: versioni web moderne di moduli Forms legacy e di processi basati su fogli di calcolo, con dati centralizzati e audit trail.
• Portali per clienti e partner: portali self-service sicuri in cui gli utenti esterni vedono i propri ordini, fatture o sinistri memorizzati in Oracle.
• SaaS multi-tenant su Oracle: prodotti SaaS verticali in cui i dati di ogni tenant sono separati nel database e il fornitore ha già standardizzato su Oracle.

Cosa includono i servizi di sviluppo software Oracle APEX?

I servizi di sviluppo software Oracle APEX coprono l’intero ciclo di vita di un’applicazione APEX: creare nuove app, modernizzare sistemi legacy migrando ad APEX, aggiornare e integrare patrimoni APEX esistenti e mantenerli veloci, sicuri e supportati. Un partner competente dovrebbe offrire la maggior parte dei seguenti servizi:

• Sviluppo di applicazioni APEX su misura: nuove applicazioni dai requisiti e dal modello dati fino alla produzione, inclusi autenticazione, ruoli e reportistica.
• Modernizzazione di Oracle Forms e dei sistemi legacy: analisi dei processi esistenti in Forms, Reports, Access o fogli di calcolo e loro ricostruzione per fasi come applicazioni APEX.
• Aggiornamenti di APEX: migrazione delle applicazioni da release precedenti come 19.x, 21.x o 23.x alla 24.2 e alla 26.x, correzione dei componenti deprecati e adozione di APEXlang.
• Integrazioni: interfacce REST e ORDS con sistemi ERP, CRM, di pagamento e SaaS, oltre al single sign-on con gli identity provider aziendali. La nostra guida all’integrazione dei sistemi enterprise approfondisce i pattern.
• Lavoro su UI e UX: layout, navigazione e accessibilità sullo Universal Theme e sul tema Iris rinnovato, con componenti personalizzati solo dove ripagano lo sforzo.
• Ottimizzazione delle prestazioni: ottimizzazione di SQL e PL/SQL, strategia di indicizzazione e di paginazione per Interactive Reports e Grid di grandi dimensioni.
• Supporto e manutenzione: monitoraggio, correzione dei bug, piccoli miglioramenti e un ciclo di aggiornamento pianificato e allineato al calendario dei rilasci di Oracle.

L’equilibrio tra questi servizi dipende dal punto di partenza. Un progetto greenfield spende la maggior parte del budget in discovery e sviluppo, mentre un patrimonio esistente di solito spende di più in aggiornamenti, prestazioni e refactoring di anni di pagine accumulate.

Come funziona il processo di sviluppo APEX?

Un progetto APEX ben gestito segue lo stesso ciclo di vita disciplinato di qualsiasi software enterprise, solo con iterazioni più brevi, perché le schermate funzionanti si possono generare dal modello dati in poche ore. I sette passaggi seguenti sono una sequenza pratica per una nuova applicazione o per una fase di modernizzazione.

1. Discovery e audit dei dati. Mappare utenti, processi e lo schema esistente, individuare i problemi di qualità dei dati e concordare il perimetro. Deliverable: un backlog prioritizzato, una bozza del modello dati di destinazione e una stima fissa per la prima release.
2. Modello dati. Progettare o rifattorizzare tabelle, viste e package PL/SQL prima di costruire le schermate; APEX 24.2 e successive possono proporre un modello di partenza con la modellazione dei dati assistita dall’IA in SQL Workshop. Deliverable: uno schema revisionato con vincoli e dati di test.
3. Prototipo in pochi giorni. Generare le pagine principali dal modello e sottoporle a utenti reali entro la prima o la seconda settimana, il che funziona come un proof of concept a basso rischio sia per il processo sia per la scelta della piattaforma. Deliverable: un prototipo cliccabile su strutture dati reali.
4. Sviluppo e integrazione. Implementare le regole di business in package PL/SQL, collegare sorgenti REST e sistemi di destinazione e aggiungere autenticazione, autorizzazione e audit. Deliverable: incrementi completi di funzionalità ogni una o due settimane.
5. Test e code review. Revisionare i diff APEXlang nelle merge request, eseguire test unitari sul PL/SQL (ad esempio con utPLSQL) e automatizzare i percorsi utente chiave con uno strumento di test nel browser. Deliverable: un report di test e una suite di regressione.
6. Deployment tramite CI/CD. Promuovere i file APEXlang e gli script di database da sviluppo a test e produzione tramite una pipeline invece che con esportazioni manuali. Deliverable: rilasci ripetibili e verificabili con script di rollback.
7. Aggiornamenti e supporto. Pianificare una finestra di aggiornamento circa ogni 12–18 mesi per restare entro le release supportate da Oracle e monitorare prestazioni e utilizzo dopo il go-live. Deliverable: un calendario degli aggiornamenti e uno SLA di supporto.

Il maggiore risparmio di tempo in questo processo non viene dal builder low-code in sé, ma dal feedback precoce degli utenti: poiché le schermate APEX costano poco da modificare prima che la logica PL/SQL si consolidi, i problemi di processo emergono alla seconda settimana invece che durante i test di accettazione.

Come si migra da Oracle Forms a Oracle APEX?

La migrazione da Oracle Forms a Oracle APEX va affrontata come una riprogettazione: si mantiene e riutilizza la logica di business PL/SQL nel database, ma si ricostruiscono schermate e flussi utente per il web. Una conversione uno a uno non funziona perché Forms è stateful e guidato dai trigger, mentre APEX è stateless e basato sulle richieste, e le stesse FAQ di Oracle sulla modernizzazione da Forms ad APEX lo confermano: nessuno strumento converte Forms in APEX in modo completamente automatico.

I tempi dipendono dalle date di supporto e dall’infrastruttura. Secondo le tempistiche pubblicate nell’ambito della Lifetime Support Policy di Oracle, come riassunto dalla guida alla migrazione 2026 di Aqlix, l’ultima release di Oracle Forms è la 14c (14.1.2) di dicembre 2024, con Premier Support fino al 2030 ed Extended Support a pagamento fino a dicembre 2033. Forms richiede inoltre WebLogic Server, mentre APEX no, quindi dismettere Forms elimina di solito un intero livello di middleware da licenziare e aggiornare. La stessa guida stima, come stima di un fornitore, che le migrazioni di medie dimensioni richiedano circa 6–18 mesi e i patrimoni grandi 2–3 anni.

Oracle documenta il punto di partenza integrato nella sua guida alla creazione di un progetto di migrazione da Forms ad APEX, che analizza l’XML di Forms caricato e aiuta a tracciare lo stato di ogni modulo.

Piano di migrazione da Forms ad APEX passo per passo

1. Inventario e valutazione della complessità. Elencare ogni form, report, libreria e menu, registrarne l’utilizzo e assegnare a ogni modulo un punteggio in base a trigger, blocchi e integrazioni per decidere cosa migrare, accorpare o dismettere.
2. Analisi dell’XML di Forms. Convertire i moduli in XML e caricarli in un progetto di migrazione APEX per vedere blocchi, item e codice dei trigger in un unico posto.
3. Progettazione della UX di destinazione. Progettare flussi nativi per il web (pagine di ricerca, master-detail, wizard) invece di copiare i canvas di Forms, e validarli con gli utenti chiave.
4. Spostamento della logica nei package del database. Estrarre le regole di business dai trigger dei form in package PL/SQL richiamabili da APEX e da qualsiasi altro client.
5. Sviluppo per fasi ed esercizio in parallelo. Ricostruire i moduli in ordine di priorità, farli girare in parallelo con Forms dove necessario e confrontare i risultati su dati reali.
6. Formazione e passaggio definitivo. Formare gli utenti, passare modulo per modulo, dismettere i Forms non più usati e infine rimuovere WebLogic dallo stack.

Errori comuni nei progetti da Forms ad APEX

• Copia al pixel. Ricreare i canvas di Forms in un browser conserva decenni di soluzioni di ripiego e produce un’app web più lenta e macchinosa.
• Logica dei trigger lasciata nell’interfaccia. Spostare logica del tipo WHEN-VALIDATE-ITEM nei processi di pagina invece che nei package del database ripete il problema di accoppiamento originale.
• Trascurare Oracle Reports. I report sono spesso più numerosi dei form e richiedono un piano dedicato, che si tratti di reportistica APEX, di Data Reporter o di uno strumento separato.
• Nessuna baseline di test. Senza risultati attesi registrati dal vecchio sistema, nessuno può dimostrare che il nuovo calcoli gli stessi totali.

Gli stessi schemi si ritrovano nei programmi di modernizzazione in generale; il nostro articolo su costi e cause di fallimento della modernizzazione legacy tratta il business case e i motivi più comuni per cui i progetti si arenano.

Oracle APEX, altre piattaforme low-code e codice su misura a confronto

Oracle APEX è l’opzione più forte quando i dati risiedono in Oracle e l’app è incentrata sui dati; Microsoft Power Apps si adatta alle organizzazioni che usano Microsoft 365, OutSystems punta a portafogli di applicazioni enterprise più ampi e il codice su misura vince quando contano soprattutto UX, scalabilità o indipendenza da qualsiasi piattaforma. Il confronto seguente è qualitativo ed evita deliberatamente cifre di prezzo, perché le licenze delle piattaforme commerciali cambiano spesso e dipendono da accordi negoziati.

Per un’analisi più approfondita del compromesso, consulti il nostro confronto tra no-code e software su misura e il framework per decidere tra sviluppare o acquistare software enterprise. Molte organizzazioni finiscono per adottare un mix: APEX per gli strumenti interni incentrati su Oracle e codice su misura per i prodotti rivolti ai clienti.

Quando Oracle APEX è la scelta sbagliata?

Oracle APEX è la scelta sbagliata quando i dati non risiedono in Oracle, quando il prodotto è rivolto ai consumatori e guidato dal design, oppure quando l’organizzazione intende ridurre la propria dipendenza da Oracle. In questi casi il vantaggio di velocità del low-code è superato da soluzioni di ripiego, lock-in e vincoli di assunzione. Tenga d’occhio questi segnali:

• Dati fuori da Oracle o strategia multi-database. Se la maggior parte dei dati si trova in PostgreSQL, SQL Server o in data warehouse cloud, APEX aggiunge una dipendenza da Oracle invece di eliminare attriti.
• App mobile consumer, fortemente orientate al design o offline-first. Esperienze di brand curate al pixel, animazioni e funzionalità native del dispositivo sono costose da forzare in un framework per app aziendali.
• Traffico pubblico molto elevato con interattività front-end complessa. Le applicazioni ricche lato client per grandi pubblici anonimi sono servite meglio da un front-end dedicato e da un’architettura basata su API.
• Nessuna competenza PL/SQL disponibile. Se né il Suo team né il mercato del lavoro a cui attinge hanno una solida esperienza in SQL e PL/SQL, la manutenzione diventerà il collo di bottiglia.
• Un piano strategico per abbandonare Oracle. Creare nuove applicazioni su APEX aumenta proprio la dipendenza che si sta cercando di ridurre.
• Carichi pesanti in tempo reale e di event streaming. L’elaborazione di eventi ad alta frequenza e lo streaming analytics si adattano meglio a piattaforme specializzate che a un framework web basato sulle richieste.

Quando valgono diversi di questi punti, l’alternativa è di solito un’applicazione su misura con un livello API che può continuare a leggere da Oracle durante la transizione. È il cuore dello sviluppo software enterprise: scegliere l’architettura per i prossimi dieci anni invece della prima schermata più veloce.

Quanto costa lo sviluppo Oracle APEX nel 2026?

La licenza della piattaforma Oracle APEX è di solito pari a 0 $ in aggiunta a un Oracle Database già in uso; i costi reali dello sviluppo software APEX sono l’impegno di sviluppo, l’hosting e gli aggiornamenti regolari richiesti dal ciclo di rilascio. La tabella seguente scompone il costo totale di possesso nelle sue componenti.

I dati OCI provengono dall’annuncio con cui Oracle ha abbassato le barriere d’ingresso con prezzi per ECPU e per gigabyte, che ha sostituito la precedente configurazione di ingresso da 1 OCPU e 1 TB a 358 $ al mese, e dalla pagina dei prezzi di APEX di Oracle. I prezzi su OCI cambiano, quindi vanno considerati un riferimento e non un preventivo.

All’interno dell’impegno di sviluppo, questi fattori incidono di più sulla stima:

• Numero e complessità dei form e dei report Oracle da migrare o sostituire.
• Integrazioni con sistemi ERP, CRM, di pagamento, documentali e di gestione delle identità.
• Migrazione e pulizia dei dati da fogli di calcolo, Access o schemi legacy.
• Autenticazione e SSO con gli identity provider aziendali e ruoli granulari.
• Requisiti di conformità come audit trail, residenza dei dati e revisioni degli accessi.

Come riferimento dai nostri prezzi di modernizzazione, gli incarichi a perimetro fisso sulla nostra pagina di modernizzazione del software partono da 2.300 $ per un audit di modernizzazione con interventi rapidi, 9.200 $ per un refactoring sistemico e 28.700 $ per una modernizzazione completa, con prezzi in USD definiti dopo una fase di discovery che dura di solito 4–6 settimane. Se la destinazione sia APEX, codice su misura o una combinazione dei due si decide in quella discovery, non prima.

Come scegliere una società di sviluppo software Oracle APEX?

Per scegliere una società di sviluppo software Oracle APEX occorre verificare l’esperienza in produzione sulle release correnti, una competenza sul database che vada oltre la costruzione di pagine e un piano credibile per test, sicurezza e aggiornamenti. Una breve checklist aiuta a confrontare i fornitori sulla sostanza e non sulle slide:

1. Applicazioni APEX 24.2 o 26.x attive in produzione che il fornitore sappia descrivere nel dettaglio, comprese dimensioni, utenti e integrazioni.
2. Competenza approfondita in PL/SQL e nelle prestazioni del database, non solo nella costruzione di pagine: chieda come ottimizzerebbero una Interactive Grid lenta su una tabella con decine di milioni di righe.
3. Referenze di migrazione da Oracle Forms con tempistiche oneste e lezioni apprese, se la modernizzazione rientra nel Suo perimetro.
4. Pratica con APEXlang, git e CI/CD: come gestiscono branch, revisioni e deployment delle modifiche APEX dopo la 26.1 e la 26.2.
5. Un modello di sicurezza chiaro: schemi di autenticazione, schemi di autorizzazione, protezione dello stato di sessione e uso di Deep Data Security nella 26.2.
6. Un piano di aggiornamento e supporto allineato alla finestra di supporto di Oracle di due release, circa 18 mesi ciascuna.
7. Una discovery trasparente a perimetro fisso prima di una stima completa, con deliverable che restano Suoi anche se cambia fornitore.

Oracle APEX è abbastanza sicuro per le applicazioni enterprise?

Sì, Oracle APEX è abbastanza sicuro per le applicazioni enterprise quando i team utilizzano correttamente il modello di sicurezza del database e mantengono le applicazioni su release supportate. Poiché APEX gira all’interno di Oracle Database, l’accesso ai dati resta entro il perimetro di sicurezza del database invece di passare attraverso un application server aggiuntivo.

• Gli schemi di autenticazione si integrano con gli identity provider aziendali tramite standard come SAML e OpenID Connect, oltre a schemi basati sul database e personalizzati.
• Gli schemi di autorizzazione controllano l’accesso ad applicazioni, pagine, regioni, pulsanti e processi in base ai ruoli.
• La protezione dello stato di sessione impedisce agli utenti di manomettere i parametri URL e i valori degli item di pagina.
• Deep Data Security in APEX 26.2 verifica Data Roles e Data Grants nel database su ogni istruzione SQL, comprese le chiamate REST e le azioni degli AI Agents, secondo l’annuncio di Oracle sulla 26.2.
• Solo release supportate: restare entro le due release APEX attualmente supportate garantisce il flusso continuo delle correzioni di sicurezza.

Le funzionalità della piattaforma sono solo metà del lavoro; codice sicuro, revisioni e test contano altrettanto. La nostra guida al ciclo di vita dello sviluppo software sicuro spiega come integrare questi controlli in ogni rilascio.

Domande frequenti