Per chi lavora nel settore IT, in particolar modo con la tecnologia Oracle, il nome Oracle Forms non dovrebbe suonare del tutto sconosciuto.
Si tratta di una tecnologia, ormai consolidata da tempo, molto popolare soprattutto tra coloro che progettano e creano applicazioni enterprise basate su database Oracle.
Le stesse Oracle Enterprise Business Suite sono sviluppate per buona parte usando Oracle Forms; insomma, una tecnologia talmente affermata che anche nell’ultima incarnazione del famoso ERP – al momento in cui scrivo è stata rilasciata la Release 12.2 – continuano ad essere una componente tecnologica centrale.
In questo articolo desidero spiegarti, usando un esempio pratico, come puoi migrare una form sviluppata in Oracle Forms in un’applicazione sviluppata in Oracle APEX usando gli strumenti di migrazione che proprio APEX mette a disposizione.
Tengo a precisare non vuole essere una guida tecnica approfondita e che molti aspetti più tecnici dipendono, per ovvie ragioni, da come è stata progetta ed implementata l’applicazione Oracle Forms.
Piuttosto cercherò di presentarti un approccio alla migrazione Oracle Forms in Oracle APEX e quali sono le tipiche attività che devono essere fatte usando esempi pratici e concreti.
Se poi desideri approfondire l’argomento, fammelo sapere nei commenti a questo post!
IN QUESTO ARTICOLO
Oracle Forms: i limiti di oggi
Senza nulla togliere a ciò che rappresenta, è un fatto che oggi le applicazioni sviluppate con Oracle Forms non sono più all’avanguardia ed i loro limiti sono abbastanza evidenti.
Prima di tutto non sono responsive, non possono essere utilizzate su dispositivi mobile e per funzionare necessitano di un client java (quindi niente browser).
In un mondo sempre più orientato alle applicazioni mobile, anche e soprattutto quelle aziendali, queste limitazioni hanno un certo peso.
Pertanto, non è difficile comprendere perché molte aziende, e forse anche tu che stai leggendo questo articolo, abbiano maturato negli ultimi anni l’intenzione di sviluppare soluzioni più moderne.
Parlo di intenzione perché, purtroppo, chi è del settore sa benissimo che progetti di migrazione di questo tipo non sono mai semplici e vanno affrontati con le dovute cautele.
Bisogna scegliere la piattaforma giusta, quindi nuove licenze e costi, e di spesso va riprogettata da zero tutta la base dati.
Inoltre, se si parla di applicativi molto datati, spesso è difficile ri-mappare tutte le logiche di business che sono state implementate nel tempo e si rendono necessarie gravose attività di reverse engineering sul codice originale.
Infine, si devono mettere in cantiere le eventuali conversioni e migrazioni dati per non parlare di tutto quello che comporta l’adozione di un sistema nuovo (training, supporto agli utenti, ecc.)
Insomma, è davvero un gran lavoro che spesso non trova una reale giustificazione all’investimento.
Non c’è da stupirsi se ci si chiede se esiste un modo più “semplice” per migrare le proprie vecchie applicazioni in Oracle Forms ad applicazioni web moderne, che siano fruibili non solo da PC ma anche da smartphone e tablet, mantenendo la logica di business e proteggendo allo stesso tempo gli investimenti che sono stati fatti.
La risposta è Oracle APEX.
Perché modernizzare le applicazioni da Oracle Forms ad Oracle APEX
Modernizzare significa ringiovanire le applicazioni già in produzione attraverso un’interfaccia moderna e supportata da Oracle.
Il tutto senza dover cambiare la logica di business sulla quale esse sono basate, tipicamente ben collaudata e apprezzata dagli utenti.
Questo è il cuore e il senso profondo che sta dietro ad una scelta di questo tipo di attività, la vera ragione che dovrebbe spingerti in questo progetto.
Ma quanto è complicato fare qualcosa del genere?
Te lo dico subito, qualora te lo stessi chiedendo: no, non esiste ancora (chissà fra un po’ di tempo) un magico tool di migrazione che trasforma in maniera automatizzata una form (qualunque essa sia) in una bellissima applicazione in APEX (non ti nascondo che anche io l’ho cercato tanto..).
Il lavoro di sviluppo dietro ad un’attività di questo tipo c’è, questo è indubbio.
Però questo non ti deve scoraggiare.
Permettimi di fare qualche considerazione.
La prima è che se già stai usando Oracle Forms con un database Oracle, hai già Oracle APEX a disposizione, senza costi o licenze aggiuntive.
Questo significa che non solo probabilmente già adesso potresti iniziare ad usarlo, ma anche che le applicazione APEX che creerai condivideranno la stessa base dati della tua applicazione basata su Oracle Forms.
Nulla ti vieta di approcciare questa migrazione in modalità incrementale (form dopo form) per “vedere come va”: una “lazy migration“.
La seconda considerazione da fare è che, come scoprirai, Oracle APEX è davvero facile da usare, talmente facile che potresti valutare di acquisire le competenze per sviluppare le tue applicazioni internamente.
Se la tua intenzione è quella di adottare APEX per dare vita ad un ecosistema di applicazioni enterprise integrate, quella di avere delle competenze interne potrebbe essere una decisione strategica, soprattutto in termini di costi e time-to market, da non sottovalutare.
La terza considerazione è che, come già sottolineato, scegliere Oracle APEX permette di concentrarti sul cuore di questa attività, ovvero trasformare e modernizzare le tue applicazioni.
Il modello dati, gli eseguibili PLSQL, le logiche di business potrebbero non cambiare, mentre a cambiare è il vestito indossato dalle tue applicazioni sviluppate in Oracle Forms.
Ovvero passare da questo:

a questo:

Ti sembra impossibile? No, non lo è.
In questa serie di articoli ti spiegherò un metodo pratico per migrare la tua applicazione Oracle Forms verso un’applicazione Oracle APEX.
Sei pronto? Iniziamo!
Come migrare un’applicazione da Oracle Forms ad Oracle APEX
Prima di iniziare
Per migrare la una form dovrai avere a disposizione un ambiente Oracle APEX su cui lavorare, possibilmente installato sullo stesso database Oracle che la tua applicazione Oracle Form utilizza (in caso contrario devi installare tutti gli oggetti database come viste, tabelle, sorgenti PLSQL, ecc.).
Se invece vuoi fare questo tutorial insieme a me, useremo lavoreremo su due form di demo (tra un attimo troverai il link per scaricare tutti gli oggetti che ti servono): sarà sicuramente un esercizio utile.
Per fare questo esercizio hai bisogno di:
- Sorgenti Oracle Forms in formato XML (tra un attimo ti spiego come generarli)
- Database Oracle con tutti gli oggetti che la tua applicazione utilizza già installati (tabelle, viste , sequenze, trigger, ecc.). Se usi lo stesso database dell’applicazione Oracle Forms dovresti già avere tutto.
- Un ambiente Oracle APEX e un WORKSPACE APEX per sviluppare l’applicazione
Se hai già Oracle APEX installato (in Premise o in Cloud) leggi questa guida su come creare un Workspace.
In alternativa puoi avere un ambiente Oracle APEX di prova in due modi.
- Iscrivendoti al servizio di prova disponibile su apex.oracle.com significa che hai già un ambiente Oracle APEX in cui lavorare con un WORKSPACE attivo, in caso contrario leggi la guida su come ottenere un ambiente APEX di prova.
- Ti ricordo che questa opzione è utilizzabile solo se vuoi fare un test.
- Se, invece, vuoi lavorare su un’applicazione che gestirà dati reali allora devi prendere in considerazione la successiva opzione.
- Registrandoti gratuitamente su Oracle Cloud Free Tier.
- Con la registrazione base, puoi avere un database Oracle personale sulla piattaforma Oracle Cloud, Always FREE ovvero senza costi di licenza.
- Questo ambiente può essere utilizzato per implementare da subito le tue applicazioni enterprise.
Per fare questo esercizio farò riferimento alla guida che potete trovare nel blog ufficiale di Oracle APEX.
Come detto poco fa, puoi fare questo esercizio usando due form di demo che servono per gestire gestire l’anagrafica clienti e il portafoglio ordini:
- customers_fmb: anagrafica cliente
- orders_fmb: testata ordini e righe ordini
Puoi scaricare i sorgenti della form in formato XML e gli script per installarli da questo link.
Parte 1: convertire i sorgenti FMB in XML
La prima attività da fare è convertire i file FMB in XML.
Questo passaggio è necessario perché, come vedremo successivamente, dovremo importare gli XML direttamente dentro Oracle APEX per creare un Progetto di Migrazione (non preoccuparti, tra poco ti spiego cos’è)
Se stai usando i sorgenti delle form demo che hai scaricato da questa guida, non devi eseguire questa parte del tutorial perché ho già reso disponibili gli XML.
Per fare questa attività dovete utilizzare il tool di conversione Forms2XML Conversion Tool disponibile all’interno di Form Builder.
- Avviate Form Builder

- Dal menù File, seleziona la funzione Converti

- Seleziona Tipo di File: Form
- Seleziona Direzione: Da binario a testo
- File: seleziona il file FMB da convertire
- Premi Converti
Il programma genererà un file XML con lo stesso nome del file sorgente.
Parte 2: creare un progetto di migrazione Oracle Forms
In Oracle APEX un progetto di Migrazione Oracle Forms è uno strumento che ti supportare nell’individuare i vari componenti della form che vuoi migrare (blocchi, trigger, record set, ecc.) e ti aiuta a monitorare l’avanzamento nelle attività di sviluppo.
Per creare un progetto di Migrazione Oracle Forms:
- Collegati ad Oracle APEX
- Clicca su App Builder
- Nel pannello a destra, clicca sul link Migrazione Oracle Forms

- Clicca sul bottone Crea Progetto
- Inserisci le informazioni richieste: Nome del Progetto, una Descrizione e lo Schema sotto il quale deve essere creata l’applicazione.
- Prima di procedere, assicurati di utilizzare lo stesso schema del database che contiene tutti gli oggetti di database necessari nei moduli della form (tabelle, trigger, procedure, ecc,..)

- Carica i file XML che hai generato precedentemente (anche più di uno, dipende da quante form vuoi includere nella tua nuova applicazione)
- Quando hai caricato tutti i file XML, clicca su Crea

- Alla fine dovresti atterrare nella pagina del progetto dove vedrai, per ogni XML che hai caricato, il dettaglio dei componenti che vanno migrati.
- Clicca sul Nome File

- Nella pagina di riepilogo puoi vedere l’elenco di tutti componenti della form suddivisi per tipologia (blocchi, alert, triggers, ecc.) e, per ciascuno di essi, un’indicazione di come convertirli in APEX.
- Pertanto, ribadisco che non esiste uno strumento di conversione automatica. Tutti i componenti della form vanno migrati manualmente.
- Tuttavia, un Progetto di Migrazione ti aiuta ad avere una visione complessiva di tutti i componenti che la costituiscono come librerie, blocchi, triggers, ecc.

- Ad esempio, clicca su Triggers

- Nella schermata seguente verranno elencati tutti i trigger della form con tutti i dettagli (livello di esecuzione, sorgente PLSQL, ecc,.)

Ricorda che creare un Progetto di Migrazione è sicuramente il miglior modo per fare questo tipo di lavoro, perché ti consente di tenere traccia di ogni componente della form.
Durante lo sviluppo della tua applicazione APEX potrai in ogni momento accedere il progetto di migrazione, filtrare per gli oggetti migrati e recuperare quelli che sono ancora da migrare.
Questa strumento, semplice e chiaro, ti aiuterà a non perderti nessun pezzo durante le attività di sviluppo.
Parte 3: creare l’applicazione Oracle APEX
Finalmente arriviamo alla parte divertente, ovvero la creazione della nostra applicazione in APEX.
In questo esercizio implementeremo in Oracle APEX una applicazione nuove, basata su due maschere Oracle Forms
- Clienti: permette di creare e modificare clienti.
- Ordini di Vendita: permette di creare e modificare ordini di vendita.
Quando si affronta un progetto di migrazione di questo tipo, è bene pensare a come si desidera implementare l’esperienza utente.
Infatti, APEX mette a disposizione diversi tipi di componenti grafici utili per cercare ed interrogare la base dati, piuttosto che per modificare un singolo record.
In generale abbiamo diverse opzioni per strutturare la nostra applicazione.
Pertanto, in questo tutorial implementeremo all’interno della stessa applicazione diverse tipologie di soluzioni.
In questo modo avrai una prima idea di quelle che sono le possibilità di questo framework di sviluppo.
Starà poi a te decidere quella che più ti piace.
Soluzioni per applicazione Form Clienti
- Soluzione 1: Pagina con filtri dinamici: una pagina con filtri dinamici a sinistra (simili alla ricerca in Amazon per intenderci) con la possibilità di creare nuovi record o aggiornare quelli attuali
- Faceted Search + Classic Report
- Customer Form

- Soluzione 2: Pagina con Report Interattivo
- Interactive Report
- Customer Form

Soluzioni per applicazione Ordini di Vendita
- Soluzione 1: Pagina Master Detail con layout verticale
- Master Detail – Stacked
- Item Form

- Soluzione 2: Pagina Master Detail con layout affiancato
- Master Detail – Side by Side
- Item Form

- Soluzione 3: Pagina con filtri dinamici e form per inserimento
- Faceted Search + Classic Report
- Blank Page + Collections

Creazione della nuova applicazione
- Accedi all’App Builder di Oracle APEX e clicca su Crea

- Seleziona l’opzione Crea Nuova Applicazione

- Dai un nome alla tua applicazione e configura il suo aspetto iniziale. Per maggiori dettagli leggi la guida su come creare un’applicazione APEX da zero.
Soluzione 1 Form Clienti: pagina di ricerca di tipo Faceted Search + Form
La prima pagina che dobbiamo creare deve essere di tipo Faceted Search + Classic Report.
- Da questa pagina clicca sul link Aggiungi Pagina

- selezionia l’opzione Faceted Search

- Nella seguente schermata dai un nome alla pagina, seleziona la tabella sorgente dalla quale devono essere letti i dati e seleziona l’opzione Includi form
- Clicca Aggiungi Pagina

Soluzione 2 Form Clienti: pagina di ricerca di tipo Interactive Report + Form
La seconda pagina che dobbiamo creare è di tipo Interactive Report, pertanto come fatto al passo precedente
- clicca su Aggiungi Pagina e seleziona l’opzione Interactive Report.

- Anche in questo caso andrai ad indicare il nome della pagina, la tabella sorgente dalla quale leggere i dati. Ricordati di selezionare l’opzione per la creazione della form di inserimento e modifica.
- Se nella tabella sorgente sono definite delle CONSTRAINT di tipo FOREIGN KEY potrai esplicitare nella sezione Colonne Ricerca la relazione tra i campi della tabella che stiamo mappando con le relative tabelle collegate in chiave.
- Nell’esempio che sto facendo, sulla tabella S_CUSTOMER esistono 2 vincoli di tipo FOREIGN KEY
- Nel nostro esempio, il campo SALES_REP_ID nella tabella S_CUSTOMER rappresenta l’ID della tabella S_EMP. Nella form faremo visualizzare il campo NAME.

Soluzione 1 e 2 Form Ordini: pagina di visualizzazione dell’ordine di tipo Master Details
La terza pagina che creeremo servirà per visualizzare l’ordine (tabella S_ORD) e le sue righe (tabella S_ITEMS).
- clicca su Aggiungi Pagina e seleziona l’opzione Master Detail.

- Inserisci le informazioni richieste:
- il nome della pagina: Order – Stacked
- il tipo di layout: In Pila
- la tabella master: S_ORD
- la tabella detail: S_ITEM
- Premi Aggiungi Pagina

Soluzione 3 Form Ordini: pagina di ricerca di tipo Faceted Search
- Aggiungi una nuova pagina di tipo Faceted Search con queste caratteristiche:
- nome pagina: Order – Faceted Search
- tabella: S_ORD

Generazione della nuova applicazione
Abbiamo definito la struttura di base della nostra applicazione.
Prima di procedere alle successive fasi creiamo la nostra applicazione, che raffineremo in seguito.
- seleziona le Funzioni accessorie che vuoi includere
- clicca sul bottone Crea Applicazione

- Dopo aver generato l’applicazione, possiamo avviarla tramite il bottone Esegui Applicazione

- Questo è il risultato che abbiamo ottenuto.

A questo punto possiamo procedere con le successive attività che consisteranno nel migrare le logiche di business della form Oracle e le personalizzazioni (sia estetiche che funzionali) alla nostra nuovissima applicazione.
Parte 4: migrare form Clienti
Ora che abbiamo creato la nostra applicazione APEX, ci possiamo concentrare sulle attività di migrazione di tutti gli oggetti della form (trigger form, procedure, ecc.) che implementano le varie logiche di business dell’applicazione.
Prima di tutto ci concentreremo sulla form Clienti, nella sezione successiva di questa guida, vedremo la form Ordini.
Il punto di partenza per questa attività è il progetto di Migrazione Oracle Forms che abbiamo creato nella Parte 2 di questa guida e che possiamo recuperare in ogni momento cliccando sul link che trovi in basso nel pannello a destra all’interno della sezione App Builder.

Per prima cosa accediamo all’elenco dei componenti della form customer_fmb per distinguere cosa può essere effettivamente migrato in APEX (attributo Applicabile=Si) da cosa non può essere migrato (attributo Applicabile=No) in quanto trattasi di componenti specifiche di Oracle Forms.

Gli oggetti che possono essere migrati sono di norma i seguenti
- Alerts
- Blocchi
- Items
- Gruppi di record
- Triggers
- Liste Valori
- Programs Units
Mentre non potrai, per ovvi motivi, migrare oggetti come ad esempio finestre, canvas e attributi visivi.
Per questi ultimi oggetti vanno eventualmente trattati in modo specifico.
Ad esempio: se nella tua form esistono degli attributi visivi che settano il colore di un campo o lo sfondo di un’area, in APEX puoi ottenere lo stesso risultato usando il CSS predefinito di APEX oppure caricando un file CSS personalizzato.
Vediamo nel dettaglio cosa va fatto.
Blocchi
Cliccando sul dettaglio dei Blocchi database, possiamo vedere i blocchi della form, di cui solo uno è stato marchiato come da includere: Customer, la cui origine è la tabella S_CUSTOMER.
Da questa pagina possiamo vedere le varie proprietà del blocco. Ad esempio se è consentito l’aggiornamento, l’inserimento e la cancellazione.
Inoltre possiamo vedere la query che viene eseguita.

Nei dettagli del blocco possiamo vedere altre informazioni come le proprietà degli items del blocco e i trigger che sono stati definiti nella form.

Notiamo subito che questo blocco è stato già migrato (grazie alla procedura guidata che hai visto nella Parte 2).
Infatti, abbiamo creato una pagina di tipo Interactive Report per l’interrogazione e la relativa Form per l’aggiornamento e cancellazione dei record nella tabella S_CUSTOMER.

Per concludere possiamo affermare che l’attività di migrazione dei blocchi consiste nel verificare per ogni tipo di blocco:
- tipo di blocco (basato su query o su tabella)
- tipi di permessi sul blocco (aggiornamento, inserimento, cancellazione) e di conseguenza implementare in APEX la pagina usando la funzionalità più adeguata. Ad esempio:
- se la cancellazione e l’aggiornamento sono consentiti, dovrai sviluppare un Interactive Report + Form.
- se è un blocco di sola lettura puoi limitarti ad un Interactive Report.
- trigger: li vediamo tra poco
Trigger
Per quanto riguarda i trigger del blocco S_CUSTOMER, li possiamo vedere sempre nella sezione dettagli.
Il primo trigger, di tipo WHEN-MOUSE-DOUBLECLICK, richiama la procedura EDIT_TEXTITEM (standard di Oracle Forms).
Questa procedura richiama a sua volta un editor di testo a comparsa e può essere omessa nel modulo APEX.
L’unico trigger da valutare è il seguente, di tipo POST-QUERY.

Forse non te ne sei reso conto: abbiamo già migrato questo trigger in APEX.
Per verificarlo è sufficiente verificare la definizione del campo SALES_REP_ID, che è di tipo Lista Valori

Liste Valori
Partendo sempre dal progetto di migrazione analizziamo le liste valori da migrare.
Nel nostro esempio c’è solo una lista valori da migrare, che è legata al campo SALES_REP_ID del blocco Customer che abbiamo migrato alla fine del paragrafo precedente

Accedendo ai dettagli della LOV possiamo vedere la query la popola

In effetti, se torniamo all’applicazione che stiamo costruendo, il sistema ha già creato una lista valori in automatico (tramite il wizard), però non è esattamente identica.
Dall’App Builder accedi ad una delle due pagine di tipo Form che abbiamo creato nella nella sezione precedente.

Nel mio esempio, la pagina 3 – Customer viene chiamata quando si entra in edit dalla pagina 2 – Customer – Faceted Search.

In maniera simile, la pagina 5 – Customer viene richiamata dalla pagina 4 – Customer – Interactive Report.
In entrambe la pagine, 3 – Customer e 5 – Customer, viene utilizzata la stessa Lista Valori APEX: S_EMP.LAST_NAME

Pertanto adesso andremo a modificare questa lista valori per far si che esegua la stessa query della form Oracle.
Per vedere la LOV Apex:
- Accedi alla sezione Componenti Condivisi

- Clicca su Liste Valori

- Clicca sul nome della LOV

- Possiamo vedere i dettagli della Lista Valori

- Cambia il nome della Lista Valori da S_EMP.LAST_NAME al nome originale SALES_REP_LOV (questa attività non è strettamente necessaria)
- Cambia il Tipo di Origine da Tabella a Query SQL ed inserisci la query recuperandola dal progetto di migrazione.
- Tieni a mente che puoi aggiungere ulteriori colonne in visualizzazione

- Nella sezione Mapping Colonne specifica quale colonna va mostrata e quale valore deve essere restituito dalla LOV

- Clicca su Colonne di visualizzazione aggiuntive -> Seleziona colonne
- Aggiungi le colonne aggiuntive che vuoi mostrare

- Quando hai fatto, clicca su Applica Modifiche

- Quando hai fatto, puoi tornare al progetto di migrazione e marchiare come Completata la migrazione della LOV.
Alert
Gli Alert sono messaggi che vengono mostrati all’utente a seguito di determinati eventi.
Ad esempio, prima di cancellare un record il sistema chiede conferma con un messaggio di avviso.
Nella form che stiamo migrando ci sono 2 Alert.
Il primo DELETE_ALERT, chiede conferma all’utente prima di eliminare un record cliente.
Il secondo, CONFIRM_ALERT, viene mostrato se l’utente vuole annullare delle modifiche al record prima di salvare.

Vediamo come possiamo gestire questi messaggi.
DELETE_ALERT
Creando l’applicazione con il Wizard, il sistema ha già creato un messaggio di Alert che scatta quando si preme il bottone per eliminare il record.
Tuttavia, il messaggio che mostra a video è quello standard di Oracle APEX

Per modificare il messaggio:
- Vai su App Builder and clicca sulla tua applicazione
- Seleziona Componenti Condivisi (Shared Components).
- Clicca su Scorciatoie (Shortcuts).
- Clicca su Crea (Create).
- Seleziona l’opzione Completamente nuovo/a (Shortcut From Scratch).
- Clicca su Avanti (Next).
- Inserisci i parametri richiesti:
- Nome: DELETE_ALERT.
- Type: Testo in apici con escape Javascript (Text with JavaScript Escaped Single Quotes).
- Scorciatoia: il testo del messaggio originale
- Clicca Crea.

A questo punto il messaggio è stato creato e bisogna collegarlo alla pagina che lo deve richiamare.
- Seleziona la pagina Customer
- Nel tab della struttura, clicca sul nome della pagina

- Nelle proprietà della pagina, vai alla sezione Dichiarazione di funzione e variabile globale
- Aggiorna la variabile con il seguente valore
- var htmldb_delete_message='”DELETE_ALERT”‘;

CONFIRM_REVERT
Per quanto riguarda l’Alert CONFIRM_REVERT, ogni pagina APEX ha una proprietà che permette di avvisare l’utente che tentano di chiudere la pagina senza aver salvato i dati.
Pertanto sarà sufficiente verificare che questa proprietà sia abilitata.
- Seleziona la pagina
- Nel tab della struttura, clicca sul nome della pagina
- Nelle proprietà della pagina, vai alla sezione Avvisa in presenza di modifiche non salvate
- Attiva la proprietà

Program Units
Le Program Units sono procedure PLSQL che vengono definite all’interno del sorgente della form.
Questi oggetti vengono implementati per diversi motivi.
Possono eseguire delle validazioni, aggiornare dei dati sul database oppure gestire il comportamento della form (ad esempio mostrare o nascondere delle finestre o aprire altre form)
La migrazione di questi componenti in Oracle APEX va valutata caso per caso, in funzione dello scopo della specifica Program Unit.
Ad esempio, potresti dover creare un nuovo package PLSQL da eseguire a livello di database oppure definire un’ Azione Dinamica (Dynamic Action) in APEX.
Riguardo all’esempio che stiamo implementando, le Program Unit individuate non devono essere migrate perché sono state definite per gestire l’interazione con i nodi di un albero (collapse, expand, ecc.) e per inizializzare i blocchi di dati.

Parte 5: migrare form Ordini
In questa parte della guida ci concentreremo sulla form degli ordini di vendita.
Riguardo alla migrazione degli oggetti Oracle Forms, valgono tutte le considerazioni che abbiamo fatto precedentemente per la maschera dei clienti.
Quindi devi analizzare, usando a supporto il progetto di migrazione che hai creato, tutti gli oggetti della form originale (blocchi, trigger, ecc.) ed implementarli nella tua applicazione APEX.
Se ricordi, all’inizio dell’esercizio abbiamo ipotizzato diverse tipologie di pagina per la gestione degli ordini di vendita.
Te le ricordo qui sotto
- Pagina Master Detail: layout verticale
- Master Detail – Stacked
- Item Form
- Pagina Master Detail: layout affiancato
- Master Detail – Side by Side
- Item Form
- Pagina con filtri dinamici e form per inserimento
- Faceted Search + Classic Report
- Blank Page + Collections
Nell’esercizio che stiamo facendo, ci concentreremo sulla terza delle opzioni che ho introdotto all’inizio, ossia una pagina con filtri dinamici e una form per inserire l’ordine.
Tuttavia le stesse considerazioni le puoi applicare alle altre tipologie di layout.
Per fare questo avremo bisogno di implementare due pagine:
- Faceted Search + Classic Report: ci permetterà filtrare e cercare gli ordini di vendita. Se hai seguito la guida passo-passo dovresti già avere questa pagina nella tua applicazione
- Blank Page + Collections: ci servirà per inserire l’ordine ed implementare tutte le validazioni necessarie. Questa pagina va creata e dovrà essere richiama dalla pagina di ricerca
Uso delle librerie APEX_COLLECTION
In questa parte dell’esercizio utilizzeremo le API APEX_COLLECTION.
L’uso di queste strutture dati è molto utile perché permette di caricare le informazioni in record virtuali affinché possano essere consultati, manipolati e validati durante la sessione utente.
Grazie alle APEX_COLLECTION, puoi controllare i dati che sta inserendo l’utente prima di lanciare l’istruzione di INSERT o UPDATE in tabella.
In particolare lavoreremo cone le seguenti istruzioni:
- COLLECTION_EXISTS: funzione che verifica se una collection esiste nella sessione corrente.
- CREATE_COLLECTION: procedura che crea una nuova collection nella sessione corrente.
- ADD_MEMBER: procedura che aggiunge un record ad una collection.
- DELETE_MEMBER: procedura che elimina un record da una collection.
- DELETE_COLLECTION: procedura che elimina la collection nella sessione corrente.
Creazione delle Liste Valori
Per andare avanti con lo sviluppo abbiamo bisogno che le seguenti liste valori siano state migrate:
- SALES_REP_LOV: una lista valori dinamica che legge i dati dalla tabella S_EMP. Abbiamo già implementato questa LOV.
- S_CUSTOMER.NAME: una lista valori dinamica basata sui dati della tabella S_CUSTOMER.
- Questa LOV è già stata creata dalla procedura guidata.

- S_ORD.PAYMENT_TYPE: una lista valori statica con i seguenti valori: CASH, CREDIT, CHECK. Questa LOV non esiste e va creata.

- S_PRODUCT.NAME: una lista valori dinamica basata sulla tabella S_PRODUCT
- Questa LOV è già stata creata dalla procedura guidata.
- Nel progetto di migrazione è indicato di migrare la LOV PRODUCTS_LOV
Creazione della Form Ordini
Come detto prima, vogliamo creare una form Ordini in Oracle APEX che poi dovrà essere richiamata dalla pagina con i filtri dinamici che abbiamo già creato (se non lo hai fatto, vai alla Parte 3 di questa guida)
Per creare una pagina di inserimento (una Form Page) segui le seguenti istruzioni
- Clicca su App Builder.
- Clicca sulla tua applicazione.
- Clicca Crea Pagina (Create Page).
- Seleziona il tipo pagina Form Page e clicca su Successivo.

- Seleziona nuovamente Form and click Successivo.

- Inserisci le seguenti informazioni
- Numero Pagina: lascia il default
- Nome Pagina: Order – Details.
- Modalità Pagina: Normale
- Dirama Qui se si fa click su Sottometti: seleziona la pagina Orders Faceted Search Page (nel mio esempio è la pagina numero 7)
- Annulla e vai a pagina: seleziona la pagina Orders Faceted Search Page (nel mio esempio è la pagina numero 7)
- Indicatore di percorso: Breadcrumb
- Clicca su Successivo

- Preferenze di navigazione: Non associare questa pagina a una voce di menù di navigazione

- Nella sezione Origine Dati inserisci le seguenti informazioni:
- Origine Dati: Database locale
- Tipo Origine: Tabella
- Proprietario tabella/Vista: lo schema della tua applicazione
- Nome tabella/vista: S_ORD.
- Clicca su Successivo

- Seleziona tutte le colonne da visualizzare nella form
- Indica come chiave primaria la PRIMARY-KEY della tabella S_ORD: la colonna ID

- Clicca su Crea.
Grazie a questa pagina, l’utente potrà create e aggiornare le informazioni dell’ordine di vendita.
Tuttavia mancano ancora diverse cose da fare prima di poter affermare che è completa:
- mappare le liste valori ai campi
- implementare tutte le validazioni
- agganciare la form alla pagina di ricerca dell’ordine (Orders – Faceted Search)
Validazione dei campi
Apri la definizione della pagina ed imposta le liste valori sui seguenti campi:
- PX_CUSTOMER_ID: S_CUSTOMER.NAME
- PX_SALES_REP_ID: SALES_REP_LOV
- PX_PAYMENT_TYPE: S_ORD.PAYMENT_TYPE
Ricordati che sostituire X con il numero della tua pagina. Ad esempio per me la pagina è identificata dal numero 18, quindi i campi saranno P18_CUSTOMER_ID, P18_SALES_REP_ID, P18_PAYMENT_TYPE.
Dopo aver fatto questa attività ed aver aggiustato un po’ il layout della mia form, ho ottenuto questo risultato

Il prossimo passo consiste nell’implementare le validazioni
Validazione della testata dell’ordine
Nel Progetto Migrazione Form ci sono diversi trigger di validazione da migrare, ovvero implementare nella nostra applicazione.

Concentriamoci sul trigger WHEN-VALIDATE-RECORD del blocco S_ORD

Per implementare questa validazione

- Seleziona la voce Convalida in corso e con il pulsante destro seleziona Crea Convalida
- Apri la pagina Order Detail
- Clicca sul tab Elaborazioni (Processing)

- Specifica le seguenti proprietà
- Nome: Validate Order Dates
- Tipo: Espressione
- Linguaggio: PL/SQL
- Espressione PL/SQL: :PX_DATE_SHIPPED > :PX_DATE_ORDERED dove X va sostituito con il numero della pagina che tu hai creato
- Messaggio di errore: Ship date is before order date!
- Elemento associato: P18_DATE_SHIPPED

La seconda validazione che implementeremo è il trigger WHEN-RADIO-CHANGED, definito sul campo PAYMENT_TYPE del blocco S_ORD

Per implementate questa validazione, creeremo una procedura PLSQL che prenderà come parametri il cliente ed il tipo di pagamento e restituirà un messaggio di errore nel caso in cui la validazione restituisce un esito negativo.
- Seleziona il campo PX_PAYMENT_TYPE e clicca on il pulsante destro su Crea Convalida

- Inserisci i seguenti parametri
- Nome: Validate Payment Type
- Tipo: Corpo funzione che restituisce il testo dell’errore
- Corpo funzione: copia ed incolla il seguente script PLSQL
Declare
l_message varchar2(200);
Begin
PRD_VALIDATE_PAYMENT(P_CUSTOMER_ID => :P18_CUSTOMER_ID,
P_PAYMENT_TYPE => :P18_PAYMENT_TYPE,
P_MESSAGE => l_message);
return l_message;
End;

La procedura PRD_VALIDATE_PAYMENT non esiste e va compilata nel database
CREATE OR REPLACE PROCEDURE PRD_VALIDATE_PAYMENT(P_CUSTOMER_ID IN NUMBER,
P_PAYMENT_TYPE IN VARCHAR2,
P_MESSAGE OUT VARCHAR2)
IS
N NUMBER;
v_credit S_CUSTOMER.credit_rating%type;
BEGIN
IF P_PAYMENT_TYPE = 'CREDIT' THEN
SELECT credit_rating
INTO v_credit
FROM S_CUSTOMER
WHERE P_CUSTOMER_ID = id;
IF v_credit NOT IN ('GOOD', 'EXCELLENT') THEN
P_MESSAGE := 'Invalid Payment Type: select CASH';
END IF;
END IF;
END;
Salvataggio della testata dell’ordine
Per completare la gestione della testata dell’ordine è necessario far sì che il campo ID venga alimentato automaticamente dalla sequence di database S_ORD_SEQ.
Per fare questo è sufficiente impostare nella sezione Valore predefinito del campo PX_ID le seguenti proprietà:
- Tipo: Sequenza
- Sequenza: S_ORD_SEQ

Visualizzazione delle righe dell’ordine
Per visualizzare le righe dell’ordine di vendita nella nostra pagina di dettagli o dell’ordine possiamo usare diversi approcci.
Quello che faremo in questo tutorial è visualizzare le righe dell’ordine con un Interactive Report che interroga con una query una collection (APEX_COLLECTION).
Il vantaggio di questo approccio è che ci consente di manipolare le informazioni in una struttura dati virtuale e solo alla fine possiamo salvare le stesse informazioni sul database.
Tuttavia, nessuno vieta che si possano caricare i dati direttamente dalla tabella sorgente, come visto in altri esempi di questo tutorial.
Per inizializzare una collection esegui i seguenti passaggi:
- Dalla pagina Order – Details, clicca su Elaborazione e crea un nuovo Processo APEX

- Il processo che andrai a creare (dopo quello che APEX usa per inizializzare la testata dell’ordine) deve avere le seguenti caratteristiche:
- Nome: Inizializza Righe form Order – Details
- Linguaggio: PLSQL
- Codice: scrivere la seguente procedura che si occupa di inizializzare una APEX_COLLECTIONS di nome ITEMS
declare
cursor c_emp is
select ord_id, item_id, product_id, price, quantity,
quantity_shipped, s_product.name product_name,
s_product.short_desc product_desc
from s_item, s_product
where s_item.product_id = s_product.id
and ord_id = :p18_id;
begin
if not apex_collection.collection_exists('ITEMS') then
apex_collection.create_collection('ITEMS');
else
apex_collection.truncate_collection('ITEMS');
end if;
for c in c_emp loop
apex_collection.add_member(p_collection_name => 'ITEMS',
p_c001 => c.ord_id,
p_c002 => c.item_id,
p_c003 => c.product_id,
p_c004 => c.price,
p_c005 => c.quantity,
p_c006 => c.quantity_shipped,
p_c007 => c.product_name,
p_c008 => c.product_desc);
end loop;
end;
A questo punto puoi creare un Interactive Report per mostrare le righe dell’ordine.
- Accedi alla pagina Order – Details
- Crea una nuova regione, di nome Items

- Proprietà della regione Items:
- Nome: Items
- Tipo: Report Interattivo (Interactive Report)
- Query SQL: copia la query che trovi qui sotto
select
c001 as ord_id,
c002 as item_id,
c003 as product_id,
c004 as price,
c005 as quantity,
c006 as quantity_shipped,
c007 as product_name,
c008 as product_desc
from
apex_collections
where
collection_name = 'ITEMS'

In questo modo, al caricamento della pagina il sistema visualizzerà le righe presenti nella collection ITEMS che viene ogni volta inizializzata.
Nel prossimo paragrafo, vedremo come come manipolare il record della riga d’ordine caricato nella collection.
Creazione e Aggiornamento delle righe dell’ordine
Abbiamo completato la prima parte della maschera per gestire l’ordine di vendita.
Infatti siamo in grado di:
- salvare ed aggiornare la testata dell’ordine di vendita
- visualizzare le righe dell’ordine
Mancano ancora alcune cose importanti da fare:
- Gestire l’inserimento, l’aggiornamento e la cancellazione delle righe dell’ordine di vendita
- Collegare la maschera dell’ordine di vendita alla pagina di ricerca (Orders – Faceted Search)
- Definire nella pagina dell’ordine di vendita il Processo APEX che salva nel database le informazioni relative alle righe dell’ordine di vendita che sono gestite nella collection APEX.
Per gestire la modifica del record della riga d’ordine, creeremo una finestra modale che implementerà le seguenti funzioni:
- INSERIMENTO di un nuovo record nella collection ITEMS
- AGGIORNAMENTO delle informazioni del record della collection ITEMS
- CANCELLAZIONE di un record dalla collection ITEMS
Ti ricordo che tutte queste operazioni di manipolazione dei dati vengono eseguite sulla collection APEX e non a livello di database.
La sincronizzazione tra collection e tabella del database verrà fatta in un secondo momento con un PLSQL dedicato.
Creare pagina di dettaglio della riga dell’ordine
Per poter aggiungere, modificare o eliminare un record della collection, abbiamo bisogno di un semplice modulo per inserire o modificare i dati.
Quindi creeremo una pagina vuota con tutti gli elementi necessari per gestire queste operazioni.
Inoltre dovremo scrivere il codice PLSQL necessario per modificare, aggiungere o eliminare un record della collection nei Processi collegati ai 3 bottoni: “Aggiungi record”, “Aggiorna record” e “Elimina record”.
Segui i seguenti passaggi per creare da zero (senza wizard) una nuova pagina necessaria per aggiornare i dettagli della riga dell’ordine
- Clicca su App Builder e successivamente clicca sulla tua applicazione.
- Clicca il bottone Crea Pagina.
- Seleziona l’opzione Pagina Nuova (Blank Page) e clicca su Successivo (Next).
- Controlla le seguenti opzioni:
- Numero Pagina (Page Number): lascia il default
- Nome Pagina (Name): Item – Details
- Modalità pagina (Page Mode): Finestra di dialogo modale (Modal Dialog).
- Indicatore di percorso (Breadcrumb): Breadcrumb.

- Clicca su Successivo (Next).
- Preferenza di navigazione: Non associare questa pagina a una voce di menu di navigazione (Do not associate this page with a navigation menu entry).

- Clicca Successivo (Next) e poi Fine (Finish).
Adesso procediamo alla creazione della regione che contiene i campi editabili della riga dell’ordine.
- Nella pagina che abbiamo appena creato (Item – Details) vai alla sezione Content Body
- Crea una regione di tipo Contenuto Statico (Static Content) che chiamerai Items

- Nelle opzioni grafiche di questa regione seleziona i seguenti valori
- Modello Template: Standard

- Nelle opzioni modello:
- Generale: Usa impostazioni predefinite modello
- Header: Hidden
- Style: Remove Borders

Creare i campi
Ora possiamo creare i singoli campi.
Nome | Label | Tipo | Lista Valori |
---|---|---|---|
PX_ITEM_ID | Item ID | Number Field | |
PX_PRODUCT_ID | Product Id | Popup LOV | PRODUCTS_LOV |
PX_PRICE | Price | Number Field | |
PX_QUANTITY | Quantity | Number Field | |
PX_QUANTITY_SHIPPED | Quantity Shipped | Number Field | |
PX_SEQ_ID | Hidden | Number Field | |
PX_ORD_ID | Hidden | Number Field |
PX_SEQ_ID è un campo tecnico che ci serve per gestire le righe nella COLLECTION quando l’utente deve manipolare i dati (cancellare, aggiornare o modificare).
Ricordati, infine, di sostituire la “X” con il numero della tua pagina. Ad esempio, questo è il mio risultato:

Creare i Bottoni
Aggiungi 3 bottoni alla pagina di modifica della riga dell’ordine (Item – Details)
Name | Label | Action | Server-side Condition |
---|---|---|---|
DELETE | Delete | Submit Page | PX_SEQ_ID is NOT NULL |
SAVE | Save | Submit Page | PX_SEQ_ID is NOT NULL |
CREATE | Create | Submit Page | PX_SEQ_ID is NULL |
Dopo i dovuti aggiustamenti, dovresti ottenere un struttura della form fatta così:

Procediamo con le attività successive, ovvero creare le validazioni necessarie per garantire dati consistenti
Creare le validazioni
Ovviamente possono essere implementate diverse tipologie di validazioni dei dati.
Nel nostro caso ci limiteremo a rendere obbligatori i seguenti campi, che devono sempre essere specificati dall’utente prima di salvare.
Per rendere obbligatorio un qualsiasi campo in APEX, è sufficiente impostare la relativa proprietà Valore Obbligatorio che puoi trovare sotto la seziona Convalida.

Impostando questa proprietà, la tua applicazione chiederà sempre all’utente di inserire le informazioni richieste a seguito di qualunque evento che fa scatenare il Submit Page della pagina (ricordi i bottoni che abbiamo creato poco fa? Avevano come azione Submit Page)
Tuttavia è bello far vedere visivamente all’utente che quel campo è obbligatorio. Per fare questo puoi usare uno dei modelli predefiniti di Oracle APEX.
Clicca sul campo e vai alle sue proprietà.
Nella sezione Aspetto (Layout) seleziona una delle opzioni required tra l’elenco dei modelli di aspetto disponibili.
Ad esempio io userò il modello Required – Floating

Imposta questa proprietà sui seguenti campi: PX_ITEM_ID, PX_PRODUCT_ID, PX_PRICE e PX_QUANTITY
Definire i Processi APEX per salvare i dati
L’ultima cosa da fare è definire i Processi APEX che si occuperanno di eseguire l’aggiornamento del record nella collection.
Pertanto, per ciascuno dei bottoni che abbiamo precedentemente creato, dovrai creare un processo e richiamare al suo interno la relativa procedura PLSQL.
Dovranno essere creati 4 processi, che vedremo nel dettaglio nei successivi paragrafi:
- Create Item
- Edit Item
- Delete Item
- Aggiorna Griglia Righe Ordine
L’ultima Azione Dinamica serve per aggiornare automaticamente la griglia (Report Interattivo) che mostra le righe dell’ordine di vendita.
Ti consigliamo di crearla subito.
Aggiorna Griglia Righe Ordine
Per creare quest’ultima azione dinamica:
- Apri la definizione della pagina Order – Details
- Apri il tab Azioni Dinamiche
- Crea una nuova Azione Dinamica di nome Close Item Form Detail Window

- Proprietà dell’Azione Dinamica

- Proprietà dell’ Azione legata all’azione dinamica

Aggiungi Record
Definiamo il Processo APEX che gestisce la creazione di un record di riga ordine.
- Accedere al tab Elaborazione (Processing)
- Creare un nuovo Processo (Process)

- Proprietà del Processo Create Item
- Nome: Create Item
- Tipo: Esegui Codice
- Codice PLSQL: copia la procedura sotto riportata
declare
l_product_name varchar2(500);
l_product_descr varchar2(500);
l_item_id number;
begin
if apex_collection.collection_exists('ITEMS') then
begin
select name, short_desc
into l_product_name, l_product_descr
from s_product
where id = :p8_product_id;
exception
when others then
l_product_name := null;
l_product_descr := null;
end;
l_item_id := S_ITEM_SEQ.nextval;
apex_collection.add_member(p_collection_name => 'ITEMS',
p_c001 => :p8_ord_id,
p_c002 => l_item_id,
p_c003 => :p8_product_id,
p_c004 => :p8_price,
p_c005 => :p8_quantity,
p_c006 => :p8_quantity_shipped,
p_c007 => l_product_name,
p_c008 => l_product_descr,
p_c009 => null);
end if;
end;
Grazie a questo processo, il sistema aggiungerà un record nella collection APEX.
Grazie all’azione dinamica Close Item Form Modal Window creata precedentemente la visualizzazione delle righe nella griglia verrà aggiornata automaticamente.
Aggiorna Record
Definiamo il processo che permette di aggiornare un record di riga ordine.
Per poter modificare un record di una collection esistente, i dati devono essere caricati dalla collection nei campi della pagina tramite un processo che viene eseguito quando viene caricata la pagina.
Pertanto creiamo un processo che viene eseguito “After Header”, ovvero dopo la creazione dell’intestazione della pagina.
- Apri la definizione della pagina Item – Details e clicca sul nodo Dopo Intestazione (After Header)

- Il codice che il processo deve interrogare l’oggetto APEX_COLLECTION ed inizializzare i campi della pagina.
begin
if (nvl(:p8_seq_id,0) >0 ) then
select c002, c003, c004, c005, c006
into :p8_item_id, :p8_product_id, :p8_price, :p8_quantity, :p8_quantity_shipped
from apex_collections
where collection_name = 'ITEMS'
and seq_id = :p8_seq_id;
else
:p8_item_id := null;
:p8_product_id := null;
:p8_price := null;
:p8_quantity := null;
:p8_quantity_shipped := null;
end if;
end ;
La variabile P8_SEQ_ID viene valorizzata dinamicamente quando dalla pagina Order – Details viene aperta la pagina Item – Details; questo passaggio deve ancora essere implementato, lo vediamo tra poco.
A questo punto, possiamo implementare la logica nel processo legato al bottone Edit Item.
- Seleziona il Processo Edit Item della pagina Item Details

- Vai nella sezione Origine del Processo e scrivi il codice PLSQL che si occuperà di aggiornare il record nella collection.
- Per fare questo userò la procedura UPDATE_MEMBER della libreria APEX_COLLECTIONS. La procedura vuole come parametri, il nome della collection e il seq_id del record che vogliamo aggiornare
declare
l_product_name varchar(500);
l_product_descr varchar(500);
begin
if apex_collection.collection_exists('ITEMS') then
begin
select name, short_desc
into l_product_name, l_product_descr
from s_product
where id = :p8_product_id;
exception
when others then
l_product_name := null;
l_product_descr := null;
end;
apex_collection.update_member(p_collection_name => 'ITEMS',
p_seq => :p8_seq_id,
p_c001 => :p8_ord_id,
p_c002 => :p8_item_id,
p_c003 => :p8_product_id,
p_c004 => :p8_price,
p_c005 => :p8_quantity,
p_c006 => :p8_quantity_shipped,
p_c007 => l_product_name,
p_c008 => l_product_descr);
end if;
end;

Elimina Record
Infine creiamo il Processo che permette di cancellare una riga dalla collection.
A tal proposito utilizzeremo la procedura DELETE_MEMBER della libreria APEX_COLLECTION.
- Seleziona il Processo Delete Item della pagina Item Details

- Vai nella sezione Origine del Processo e scrivi il codice PLSQL che si occuperà di rimuovere il record dalla collection.
- Useremo la procedura DELETE_MEMBER della libreria APEX_COLLECTIONS. La procedura vuole come parametri, il nome della collection e il seq_id del record che vogliamo eliminare.
begin
if apex_collection.collection_exists('ITEMS') then
apex_collection.delete_member(p_collection_name => 'ITEMS',
p_seq => :p8_seq_id);
end if;
end;
Come richiamare la pagina Item – Details dalla pagina Order – Details
Per poter utilizzare correttamente la form modale Item – Details è necessario che venga richiamata dalla pagina Order – Details in due modalità:
- Creazione: in questo caso non viene inizializzato alcun record dalla collection
- Aggiornamento/Cancellazione: viene inizializzato un record dalla collection dopo aver cliccato su un bottone/link a livello di riga.

Ecco un esempio delle iterazioni:
- bottone Add Item: apre la maschera Item Detail in creazione

- link alla riga: : apre la maschera Item Detail in modifica

- bottone Apply Changes: salva i dati della collection nel database

Aggiungere un nuovo record
- Vai alla pagina Order – Details
- Seleziona la regione Items (di tipo Interactive Reports)
- Crea un nuovo pulsante e posizionalo nella barra di ricerca

- Nelle proprietà del bottone indica:
- Azione: Reindirizza alla pagina in questa applicazione
- Destinazione: la pagina Item – Details (nel mio progetto è la numero 8)

- Nelle proprietà del collegamento dovrai mettere i parametri da passare alla pagina Item Details.
- PX_ORD_ID: id dell’ordine di vendita
- PC_SEQ_ID: -1

Aggiornare o cancellare un record esistente
- Vai alla pagina Order – Details
- Seleziona la regione Items (di tipo Interactive Reports)
- Posizionati sull’item SEQ_ID

- Imposta il tipo a Collegamento

- Nelle proprietà del collegamento imposta i seguenti valori:
- Tipo: Pagina in questa applicazione
- Pagina: imposta la pagina Item – Details (nel mio progetto è identificata dal numero 8)
- Parametri:
- PX_SEQ_ID
- PX_ORD_ID
- PX_ITEM_ID

Salvataggio delle righe nel database PRD_CREATE_ITEM
Ora abbiamo finito di giocare con i nostri dati all’interno della collection ed è ora di salvarli nel database.
Quando lavori con le Collection l’approccio è sempre lo stesso: carichi i dati in una raccolta, li manipoli e alla fine, quando l’utente decide di archiviarli, puoi lanciare una store procedure PLSQL che si occupa di fare gli update ed insert in tabella.
Per salvare la nostra collection, userò la seguente procedura PLSQL.
create or replace procedure prd_create_item (
p_ord_id in number
) is
begin
if apex_collection.collection_exists(p_collection_name => 'ITEMS') then
delete from s_item
where
ord_id = p_ord_id;
insert into s_item (
ord_id,
item_id,
product_id,
price,
quantity,
quantity_shipped
)
select
c001 as ord_id,
c002 as item_id,
c003 as product_id,
c004 as price,
c005 as quantity,
c006 as quantity_shipped
from
apex_collections
where
collection_name = 'ITEMS';
apex_collection.delete_collection(p_collection_name => 'ITEMS');
commit;
end if;
end prd_create_item;
Nel paragrafo successivo vedremo come e dove richiamarla.
Creare in Processo APEX che esegue la procedura PRD_CREATE_ITEM al salvataggio
- Dalla struttura della pagina, clicca sul tab Elaborazione
- Clicca su Processi e con il pulsante destro del mouse seleziona Crea Processo

- Tieni a mente che il nuovo processo che crei deve sempre essere eseguito dopo quello che APEX ha creato in automatico, che dovrebbe chiamarsi Elabora form Order – Details (Process form Order): questo garantirà che la testata dell’ordine venga inserita o aggiornata prima di inserire nel database le righe dell’ordine di vendita.

- Completa la definzione del Processo APEX in questo modo:
- Nome: Elabora Righe form Order – Details
- Linguaggio: PLSQL
- Codice PLSQL: PRD_CREATE_ITEM (P_ORD_ID => :P1X_ID);

Parte 6: personalizzare l’applicazione Oracle Apex
Via via che migriamo ogni elemento indicato come “Applicabile” possiamo tracciare nel progetto di migrazione gli oggetti come “Completati“
Quando avremo raggiunto il 100% significa che avremo completato la migrazione di tutta la form in APEX.
Cosa? Hai finito? Complimenti!

Arrivati a questo punto possiamo raffinare la nostra applicazione per offrire all’utente un’esperienza di utilizzo migliore possibile.
Ecco quindi, alcuni spunti di miglioramento che possiamo implementare.
- Creare delle LOV Statiche per i campi validati (per intenderci, sto parlando dei classici menù a tendina)
- Aggiustare il layout delle form APEX.
- Personalizzare le pagine di tipo Faceted Search con nuovi filtri.
- Personalizzare le pagine con Interactive Report.
Vediamo queste funzionalità nel dettaglio.
Creare una LOV Statica per i campi da validare
Poiché la tabella S_CUSTOMER ha un vincolo sui valori che è possibile inserire nel campo CREDIT_RATING, creeremo una lista valori statica da usare nelle form che servono ad aggiornare i dati del cliente.

- Da App Builder selezionare l’applicazione
- Selezionare Componenti Condivisi (Shared Components)
- Selezionare Liste Valori
- Premere il bottone Crea
- Selezionare l’opzione Crea lista valori completamente nuova
- Inserisci le informazioni richieste:
- Nome: S_CUSTOMER.CREDIT_RATING
- Tipo: Static

- Specificare le entries della LOV
- Premere Crea Lista Valori

Nel paragrafo successivo vedremo come personalizzare la maschera per aggiornare i dati del cliente e vedremo come usare la lista valori appena creata.
Personalizzare una form APEX
Quando crei una pagina con la procedura guidata (wizard) viene creato automaticamente ogni elemento per ogni colonna della tabella.
A seconda del DATATYPE della colonna, Oracle APEX può creare un campo di testo (Text Field), un’area di testa (Text Area), un selettore di data (Date Picker) o un campo numerico (Numeric Field).
Una volta che la pagina è creata, puoi personalizzarne l’aspetto, aggiungere liste valori e raffinarla come meglio credi usando le funzionalità di drag & drop e il property inspector di ogni singolo elemento.
Per utilizzare la lista valori creata poco fa:
- seleziona il campo PX_CREDIT_RANGE (ricorda: X è il numero della pagina. Se ad esempio sto lavorando sulla pagina 3, dovrai selezionare l’item P3_CREDIT_RANGE)

- Nel pannello delle proprietà sotto la sezione Identificazione, imposta i seguenti valori:
- Tipo: Lista di Selezione

- Nel pannello delle proprietà sotto la sezione Lista di valori, imposta i seguenti valori:
- Tipo: Componente condiviso
- Lista di valori: S_CUSTOMER.CREDIT_RATING
- Salva

Ecco il risultato

Personalizzare la maschera di ricerca di tipo Faceted Search
Possiamo aggiungere dei nuovi filtri alla pagina di ricerca del cliente usando le proprietà del componente Faceted Search.
Per maggiori dettagli, leggi la guida su come modificare i filtri nel componente Faceted Search.
Personalizzare la maschera di ricerca di tipo Interactive Report
Puoi definire come gli utenti potranno utilizzare la machera di ricerca.
Come sviluppatore puoi creare viste primarie o alternative che saranno disponibili per tutti gli utenti.
Allo stesso tempo ciascun utente può creare e salvare le proprie viste private.
Per maggiori dettagli, leggi la guida su come personalizzare un Interactive Report.
Menù di Navigazione
Quando crei una nuova applicazione il sistema include sempre un menù di navigazione che puoi modificare nel modo che preferisci.

Per cambiare la struttura del menù di navigazione segui i seguenti passaggi:
- Clicca su App Builder e quindi clicca sulla tua applicazione.
- Clicca su Componenti Condivisi (Shared Components).
- Nella sezione Navigazione clicca su Menù di navigazione

- Clicca sul menù che vuoi modificare

- Nella sezione Dettagli Lista possiamo vedere tutte le voci di menù incluse

Usando le funzionalità messe a disposizione puoi riorganizzarle e strutturarle in sotto-menù come meglio credi.
Per maggiori dettagli leggi il tutorial su come gestire i menù in Oracle APEX.
Authentication Scheme
Lo Schema di Autenticazione di una applicazione Oracle APEX definisce come l’utente può autenticarsi all’interno dell’applicazione.
Ad esempio tramite username e password gestite direttamente da Oracle APEX oppure tramite Active Directory.
Puoi definire modalità di autenticazione totalmente custom. Per maggiori dettagli leggi il tutorial su come gestire l’autenticazione in un’applicazione Oracle APEX.
Personalizzazione dell’interfaccia utente tramite Theme Roller
Uno tema è un CSS che viene aggiunto al CSS di base.
Utilizzando la funzionalità Theme Roller puoi modificare e personalizzare l’aspetto della tua applicazione.
Ad esempio puoi cambiare i colori del tema usando quelli del tuo brand. Puoi allargare la barra laterale dei menù piuttosto che il colore delle intestazioni delle varie aree.
Per avviare il Theme Roller
- Esegui la tua applicazione come sviluppatore mentre sei connesso all’APEX Workspace.
- Nella parte inferiore della pagina, puoi trovare la barra degli strumenti per sviluppatori.
- Fare clic su Theme Roller.

- Accedi al pannello di controllo per modificare in tempo reale il CSS applicato

- Quando hai fatto puoi salvare il tema modificato ed impostarlo come default.
Il risultato finale
Bene, arrivati in fondo a questo tutorial avrai creato la tua applicazione Oracle APEX.
Io mi sono divertito un po’ ad abbellire quella alla quale ho lavorato. Se vuoi darci un occhio puoi raggiungerla da questo link usando queste credenziali:
- username: demoappin5minuti
- password: demoappin5minuti
Fammi sapere cosa ne pensi scrivendolo nei commenti!
ciao!
Lascia un commento