Oracle eBusiness Suite (eBS)
Oracle Applications - R12

Oracle Enterprise Business Suite (eBS) e' l'ERP (Enterprise Resource Planning) sviluppato e mantenuto dalla Oracle Corporation. Il nome storico e' Oracle Applications, che indica la presenza di molteplici moduli applicativi. Si tratta di un prodotto funzionalmente molto completo e complesso. La sfida di questo documento e' quella di presentare l'architettura dell'ultima versione (R12) di eBS in modo semplice ma al tempo stesso in modo completo e corretto!

Nonostante i miei sforzi nel semplificare gli argomenti, questa pagina e' comunque un documento tecnico. Se pensate che un Package PL/SQL sia un pacchetto regalo e che gli Apache siano solo una tribu' di indiani e' meglio che non proseguiate nella lettura!
Oracle eBusiness Suite si basa sui due principali prodotti di Oracle: il database Oracle RDBMS e l'application server Oracle Application Server (OAS) sfruttandone appieno le funzionalita' (eg. Forms, PL/SQL). E' necessaria una conoscenza di base su tali argomenti per approcciarsi ad eBS.

Dal punto di vista funzionale EBS contiene centinaia di moduli (eg. GL: General Ledger, PER: Human Resources, BOM: Bill of Materials, ...) tipici di tutti gli ambienti ERP. La maggioranza delle applicazioni, in particolare quelle di data entry, sono realizzate con Forms. Con molta fantasia i report sono realizzati con... Oracle Reports! Sono presenti centinaia di Package PL/SQL, applicazioni Java, script, ...

Un progetto Oracle EBS completo prevede, al termine della fase di disegno dell'architettura tecnologica e della sua installazione, un'ampia fase di configurazione e personalizzazione applicativa ed, eventualmente, sviluppi di specifiche funzionalita' per il cliente. Tali argomenti esulano dallo scopo di questo documento... ma e' comunque importante ricordare che tutte le personalizzazioni e sviluppi "ad Hoc" vanno sempre effettuati seguendo le linee guida di Oracle. In caso contrario la manutenzione e l'aggiornamento di EBS diverranno molto onerosi (complessi lo sono gia' per conto loro).
Per aiutare i capi progetto ed i progettisti nella conduzione di progetti EBS Oracle ha sviluppato una specifica metodologia di project management: Oracle Application Implementation Methodology (AIM). L'AIM fornisce un insieme molto ampio di template di documenti che guidano nell'implementazione del progetto. La versione di AIM 3.0 prevede oltre 200 template ma la scelta su quali utilizzare dipende dall'ampiezza del progetto. La versione piu' recente di AIM (3.1) e' web based.

Architettura

I componenti di EBS sono molteplici... descriverli in dettaglio tutti non e' utile in un testo introduttivo come questo. Pertanto ci limiteremo a descrivere i principali cercando di fornire un'idea d'insieme delle funzionalita' presenti. La versione cui facciamo riferimento negli esempi e' Oracle E-Business Suite R12.1, nei capitoli sucessivi riporteremo alcuni elementi relativi a versioni precedenti.

EBS si basa sui due principali prodotti tecnologici di Oracle il database Oracle RDBMS e l'application server Oracle OAS sfruttandone appieno le funzionalita'.

La figura a lato mostra l'architettura dell'RDBSM Oracle. Un'istanza dell'RDBMS Oracle prevede un certo numero di processi di background dedicati a compiti specifici (eg. DB Writer), la SGA: un'area di memoria condivisa (eg. DB buffer) ed un listener in attesa delle connessioni dei client. Per ogni sessione di connessione alla base dati viene attivato un processo utente oracle. Le tabelle e gli indici contenenti i dati vengono salvati su opportuni datafile mentre le transazioni vengono garantite grazie ad un sofisticato meccanismo di doppia scrittura su file di log.
Si tratta dell'architettura piu' semplice, per gli ambienti di produzione spesso si utilizzano configurazioni RAC o in failover cluster. Per una descrizione piu' completa dell'RDBMS Oracle si puo' partire da questo documento.

Nel database vengono mantenuti, oltre alle tabelle con i dati ed alle configurazioni, i package applicativi in PL/SQL. L'utente principale e' APPS su cui sono presenti un migliaio di tabelle e sopratutto 50.000 tra trigger e packages. Altro utente importante e' APPLSYS che mantiene le circa 800 tabelle di sistema. Inoltre ogni prodotto o modulo ha un suo schema dati con le relative tabelle (eg. oltre 300 per BOM). In totale si hanno oltre duecento utenti con circa 40.000 tabelle. Dati ed indici sono ospitati una serie di tablespace predefinite (nella versione 11 erano previsti due tablespace per utente, con la versione R12 vengono utilizzate 8 tablespace APPS_TS_%). Alcune tabelle sfruttano il Partitioning, altre la Spatial Option.

Per EBS R12.1 la versione di riferimento e' la 11.1.0.7, ma sono certificate tutte le versioni dalla 10gR2 sia come single instance che in RAC.

Oracle Application Server (OAS) e' l'Application Server J2EE di Oracle. Ogni installazione attiva di OAS prende il nome di OAS Instance. E' tipicamente presente un'istanza di infrastruttura (che fornisce servizi quale l'autenticazione) ed una o piu' istanze Mid Tier (che ospitano le applicazioni). L'insieme dell'istanza di infrastruttura e di tutte le istanze di Mid Tier ad essa associate prendono il nome di OAS Farm.

La figura a lato riporta una configurazione di esempio con una Farm OAS distribuita su due server. Sono presenti due istanze OAS, una di Mid Tier e la seconda di Infrastructure. L'HTTPD Server e' Apache. Sono indicati anche alcuni componenti applicativi come Portal, il Forms Server ed un OC4J contenente applicazioni Java. Oltre alla base dati per i Metadati e' indicata un'istanza contente dati applicativi. L'OPMN si occupa di attivare e controllare tutti i processi necessari ad un'istanza OAS.
Si tratta solo di una delle molteplici topologie supportate, per gli ambienti di produzione spesso si utilizzano configurazioni ridondate con cluster e con Load Balancer. Per una descrizione piu' completa si puo' partire da questo documento.

Una Fresh Install di EBS R12.1 nella configurazione di default, installa un'istanza OAS Mid Tier Standalone (senza Infrastructure) in versione 10.1.3.4 con Apache ed OC4J. I componenti installati relativi al Forms Server sono in versione 10.1.2.2. Con l'installazione di default si puo' scegliere se il server che ospita la parte applicativa sia quello gia' utilizzato come DB Server oppure essere un nuovo server dedicato (Primary Application Server). E' altrimenti possibile effettuare l'installazione di EBS su una infrastruttura OAS e con un RDBMS Oracle gia' presenti, si tratta tuttavia di una procedura molto piu' complessa.

Quando un'utente si collega con il proprio browser ad EBS utilizza inizialmente un'applicazione web. Le varie richieste vengono elaborate dall'Application Server (da Apache e dall'OC4J richiamato) e restituite all'utente con il protocollo HTTP. Nella versione attuale di EBS molte fuzionalita' sono state implementate in questo modo.

Se l'utente richiama un'applicazione Forms, il browser attivata una JVM (JRE SUN, JInitiator Oracle) per eseguire l'Applet che fornisce l'interfaccia grafica delle applicazioni Forms. L'OC4J:forms si occupa di lanciare il processo Forms frmweb per ogni sessione utente. Lo scambio di dati tra l'Applet ed il processo Form avviene con il protocollo HTTP, mentre l'accesso ai dati da parte del processo Server avviene con il protocollo TNS (il "solito" SQL*Net o NetX).
I browser certificati (Doc ID 285218.1, 389422.1) sono Microsoft Internet Explorer, Mozilla Firefox ed Apple Safari, ma occorre fare attenzione alle versioni sia del browser che del Plug-in Java (Jinitiator o JDK) che debbono supportare le Netscape Plug-in Application Programming Interface (NPAPI) plug-ins [NdA dal 2017-04 su EBS 12.1.3 e 12.2 e' disponibile la differente tecnologia Java Web Start (Doc ID 2188898.1) supportata dai browser piu' recenti].

Quando invece sono richieste attivita' non interattive (eg. esecuzione di una stampa, elaborazione di un bilancio, ...) EBS utilizza un sofisticato meccanismo di schedulazione per la gestione concorrente delle attivita': il Concurrent Processing.

I servizi servizi resi disponibili dall'RDBMS e dalle istanze OAS sono raggiungibili su specifiche porte socket. La tabella a fianco riporta le assegnazioni principali. Valori utilizzati nelle versioni precedenti sono 7000 per il Report Server e 9000 per il Forms Server (in R12 di default i Forms vengono richiamati in Servlet Mode ovvero via AJP, e' comunque possibile passare alla modalita' Socket Mode). E' possibile utilizzare numeri di porte differenti, in questo caso tutti i numeri di porta vengono variati delle stessa quantita' (eg. +10: Listener 1631, SSL 4453, Web 8010, ...). L'insieme di porte utilizzate viene indicato come Port Pool. L'utilizzo dei Port Pool e' fondamentale per risolvere eventuali conflitti e per ospitare sullo stesso sistema piu' intallazioni di EBS.

Principali componenti

EBS e' costituito da centinaia di moduli. I componenti comuni sono chiamati SHARED, gli altri componenti vengono scelti dal cliente e sono definiti INSTALLED (o LICENSED). Tra i componenti comuni: Applications DBA (AD), Application Utilities (AU), Grants Accounting (GMS), Payroll (PAY), ...
Sono moltissimi i moduli licensed: Assets (OFA), General Ledger (GL, SQLGL), Bill of Materials (BOM), Inventory (INV), ... European Localization (JE), Regional Localization (JG), Customer Care (CSC), Marketing (AMS), Sales online (ASF), Human Resources (PER), Automotive (VEA), Cash Management (CE), Oracle Internet Expenses (OIE), Receivables (AR), iPayment, Credit Management, Procurement Modules Purchasing (PO), iProcurement, Projects Modules Projects Management, Projects Costing & Projects Billing, Manufacturing Modules Work In Process (WIP), Quality (QA), Flow Manufacturing (FLM), Warehouse Management (WMS), ...
Anche le configurazioni piu' complete raramente utilizzano tutti i moduli. In ogni caso tutti i componenti (file, directory, ...) sono sempre presenti in ogni installazione.

Per ogni modulo e' presente una variabile d'ambiente _TOP (eg. BOM_TOP per Bill of Materials) che punta alla directory in cui e' mantenuto il modulo. I contenuti dipendono dai programmi presenti ma sono comunemente suddivisi in directory come:

admin    forms    html     log      media    out      reports  xml
flash    help     java     mds      mesg     patch    sql

Per la gestione delle attivita' non interattive EBS utilizza i Concurrent Manager. L'idea e' semplice: sono presenti una serie di processi che raccolgono le varie richieste (Concurrent Request) e le elaborano seguendo un preciso workflow di esecuzione che prevede fasi e stati. Le richieste hanno metodi di esecuzione diversi (eg. Report, PL/SQL, ...) e possono essere schedulate periodicamente. I Concurrent Manager della versione R12 prevedono alcuni processor di sistema (FND%) piu' altri presenti a seconda delle esigenze:

I Concurrent Manager utilizzano un'ampia serie di tabelle dell'utente APPLSYS: FND_CONCURRENT_PROGRAMS, FND_CONCURRENT_PROCESSES, FND_CONCURRENT_REQUESTS, ... La gestione delle richieste prevede un flusso con una serie di fasi e stati... anziche' descriverli in dettaglio ecco un paio di query SQL con la decodifica dei valori:

SELECT DECODE(fcr.phase_code, 'P', 'Pending', 'R', 'Running', 'C', 'Completed', 'I', 'Inactive', fcr.phase_code) Phase,
  DECODE(fcr.status_code, 'A', 'Waiting', 'B', 'Resuming', 'C', 'Normal', 'D', 'Cancelled', 'E', 'Errored', 'F', 'Scheduled',
    'G', 'Warning', 'H', 'On Hold', 'I', 'Normal', 'M', 'No Manager', 'Q', 'Standby', 'R', 'Normal', 'S', 'Suspended',
    'T', 'Terminating', 'U', 'Disabled', 'W', 'Paused', 'X', 'Terminated', 'Z', 'Waiting', fcr.status_code) Status,
  count(*) count
FROM applsys.fnd_concurrent_requests fcr
  group by phase_code, status_code
  order by phase_code, status_code;

SELECT DECODE (fcpg.execution_method_code,
    'A', 'Spawned', 'B', 'Request Set Stage Function', 'F', 'Flexsql', 'H', 'Host', 'I', 'PL/SQL', 'L', 'SQL*Loader',
    'J', 'Java Stored', 'K', 'Java', 'P', 'Oracle Rpt', 'Q', 'SQL*Plus', 'R', 'SQL*Report', 'S', 'Immediate',
    'X', 'FlexRpt', fcpg.execution_method_code) Program_type,
  count(*) count
FROM applsys.fnd_concurrent_programs fcpg
  group by fcpg.execution_method_code
  order by fcpg.execution_method_code;

Licensing

Le politiche di licensing di EBS non sono oggetto di questo documento... si tratta comunque di un aspetto molto importante.
Tipicamente EBS viene licenziato per Application User con un costo per ogni singolo modulo acquistato.

Per maggiori dettagli e' opportuno fare riferimento al listino ufficiale.

Installazione

L'attivita' di installazione, se si tratta di una installazione da zero rivolta ad un ambiente di test o di sviluppo, non e' complessa anche se richiede un po' di tempo. Se invece e' rivolta ad un ambiente di produzione... beh o sapete quello che state facendo, oppure chiamate un esperto (NdE per esempio noi ;-).
Le attivita' piu' onerose sono la verifica delle certificazioni e la determinazione dei componenti da installare prima, e poi, effettuata l'installazione, l'applicazione delle patch necesarie al corretto funzionamento.

I pacchetti da scaricare sono di grandi dimensioni (indicativamente 50GB), vanno decompressi ed appoggiati su un'area di stage. E' molto opportuna la disponibilita' di una connessione Internet ad alta velocita'! In ogni caso il download e l'unzip richiedono ore.
EBS non e' scaricabile da OTN e non ha una licenza "unlimited evaluation". Il software va scaricato dal Sito Oracle E-Delivery che richiede una registrazione differente da quella OTN o Metalink (My Oracle Support). L'accesso a My Support e' una necessita': l'elenco dei prerequisiti, delle certificazioni, ... sono fondamentali.

I prerequisiti... sono tantissimi! Ma analoghi a quelli dell'RDBMS e di OAS. Possiamo ipotizzare un sistema QuadCore, 2GB RAM, 500GB Disk, RHEL 5.4, ... ma se raddoppiamo tutto e' molto meglio.
Bisogna creare di due utenti con lo stesso GID: oraSID (utente proprietario della base dati) applSID (utente proprietario della parte applicativa). Bisogna installare tutti i pacchetti richiesti con rpm -i. Sono una decina e bisogna fare molta attenzione alle versioni ed alla piattaforma (eg. 32/64bit)... Una cosa banale ma importante: il file /etc/hosts deve contenere il nome del sistema con il dominio come primo alias.

Pronti? Via!
Spostarsi nell'area di stage, quindi:

Parte l'applicazione X di installazione... come in altri casi si tratta di un wizard con semplici domande. Scegliere installazione (non Express, non Upgrade), si puo' saltare la parte OCM, va scelto un Port Pool, ... si arriva alla configurazione del Database. Sono possibili due tipi di installazioni:

• Vision Demo Install: un'installazione che crea un ambiente completo con alcuni dati di prova su un'ipotetica azienda. Utile come ambiente di test e per provare tutti i componenti.
• Fresh Install: un'installazione senza dati di prova e che richiede la configurazione di tutti i componenti adatta ad un'installazione di produzione.

Con una Fresh Install e' necessario indicare il tipo di licensing (Site/Component), eventuali prodotti aggiuntivi (eg. Trade Magement), le localizzazioni (Italy - IT ovviamente), ...
Quindi, con entrambe le tipologie di installazione, si arriva alla videata di configurazione dell'application server (primario) in cui vanno solo controllati i valori suggeriti. Ora vengono eseguiti i controlli e, con un po' di conferme, se tutto va bene, l'installazione e' terminata.

E' ora possibile connettersi ad EBS con l'utenza di amministrazione (SYSADMIN/SYSADMIN) come si vede nella figura a lato.

Come passi di post installazione vanno aggiornati i .profile e gli script di startup/shutdown.
Ma in realta', se si tratta di una installazione propedeutica ad un utilizzo di produzione, e' a questo punto necessaria l'applicazione di tutte le patch consigliate.

Spesso terminata un'installazione e la relativa configurazione si procede al cloning per disporre di altri ambienti di test, sviluppo, ... tutti allineati tra loro. Ma questo lo vedremo poi!

Amministrazione

EBS fornisce un'interfaccia di amministrazione per tutti i comandi dell'instrastruttura tecnologica utilizzata. In questo modo la gestione risulta semplificata, anche se in caso d'errore le competenze di DBA e sistemistiche risultano comunque fondamentali.

Supponendo di aver installato su dbserv01 ed apserv01 gli utenti oraXXX ed appXXX... ecco un esempio dei principali comandi di amministrazione:

# Per effettuare lo SHUTDOWN dell'Application Server (NB impiega un po'... attendere la fine)
[appXXX@apserv01 ~]$ $ADMIN_SCRIPTS_HOME/adstpall.sh
# Per effettuare lo shutdown del DB (si puo' anche fare con i comandi standard)
[oraXXX@dbserv01 ~]$ $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME/addlnctl.sh stop XXX
[oraXXX@dbserv01 ~]$ $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME/addbctl.sh stop immediate

# Per effettuare lo STARTUP di tutto
[oraXXX@dbserv01 ~]$ $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME/addlnctl.sh start XXX
[oraXXX@dbserv01 ~]$ $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME/addbctl.sh start
[appXXX@apserv01 ~]$ $ADMIN_SCRIPTS_HOME/adstrtal.sh apps/apps

# Per controllare lo stato dei servizi (il solito opmnctl)
[appXXX@apserv01 ~]$ $ADMIN_SCRIPTS_HOME/adopmnctl.sh status
# Per controllare i Concurrent Processors
[appXXX@apserv01 ~]$ $ADMIN_SCRIPTS_HOME/adcmctl.sh status apps/apps

# Menu di amministrazione
[appXXX@apserv01 ~]$ adadmin

Un compito importante dell'amministratore e, rispetto ad altri prodotti, piuttosto frequente e' l'apertura di chiamate al supporto (SR: Service Request). Il mantenimento del supporto e' fondamentale con eBS (come con tutti gli ERP).

Utilizzo

Effettuato il login, tutti gli utenti hanno menu personalizzati con accesso ad applicazioni differenti, a seconda delle loro abilitazioni. Il menu principale viene chiamato Navigator e consente di scegliere la responsabilita' (a destra) e quindi l'applicazione desiderata. L'applicazione Oracle Application Manager, tipicamente riservata agli amministratori, e' molto completa e permette un controllo diretto della configurazione di tutto il sistema e delle attivita' in corso:

Molte applicazioni (anche se meno rispetto alle precedenti versioni) sono realizzate con Forms. Il tipo di applicazione si riconosce dall'icona . Selezionando un'applicazione Forms, il browser attivata la JVM e, in una finestra specifica, parte la versione Forms del navigatore. Infine si attiva la maschera richiesta:

La gestione della GUI di Forms e' sempre la stessa con menu, EXEC QUERY, Master-Detail, ... Occorre fare un po' di pratica ma poi risulta di uso veloce ed efficiente:

Anche se ovviamente la grafica e' molto cambiata nel tempo, cosi' come sono cresciute funzionalita' ed i prodotti disponibili (eg. il navigatore nelle versioni 11i, 12, 12.1.3):

Patch

Basta pensare alle continue variazioni della legislazione fiscale, che non possono essere tutte risolte con un solo aggiornamento di parametri, per capire l'importanza dell'aggiornamento di un ERP. Su EBS il rilascio di patch e' frequente ed e' assolutamente necessario mantenere aggiornato il sistema rinnovando il canone di manutenzione ed utilizzando una completa politica di gestione.
Il sito ufficiale su cui tutte le patch sono rese disponibili e' Oracle MOS (My Oracle Support).

E' stato da tempo introdotta la modalita' di AutoPatch che, leggendo le informazioni su un file di comando .drv effettua tutte le operazioni necessarie. Ogni patch riporta nelle istruzioni il nome del file da applicare con l'AutoPatch. Il comando interattivo adpatch si occupa di eseguire tutti i passi necessari su ogni componente dell'architettura coinvolto dalla patch, e viene tipicamente lanciato sul Primary Application Server.

Prima di eseguire una patch e' necessario porre il sistema in Manteniance Mode con il menu di adadmin. Per aggirare il controllo e' possibile utilizzare il parametro: options=hotpatch (non fatelo se non siete sicuri). Vi sono molteplici opzioni disponibili in adpatch... se si debbono applicare piu' patch, per evitare la compilazione, e' utilizzata l'opzione nocompiledb. Naturalmente i vari package vanno comunque compilati al termine dell'applicazione di tutte le patch.
Poiche' l'applicazione delle patch richiede spesso la ricompilazione di centinaia di package, di Form, ... e' prevista un'elaborazione in parallelo. Il livello di parallelismo e' richiesto interattivamente ed e' indicato come numero di Worker.
In alternativa e' possibile usare lo script admsi.pl che lancia il Patch Application Assistant (e' un'applicazione X: richiede l'impostazione del DISPLAY).

Nel caso di versioni nazionalizzate, ovviamente normale per i clienti italiani, dopo avere effettuato la patch per la lingua inglese, va effettuata quella per la lingua italiana. Se sono presenti piu' lingue, la patch va applicatata per ogni lingua.

Nella versione R12.2 e' stato introdotto un nuovo strumento per la gestione delle patch che effettua l'installazione online: ADOP.

L'applicazione delle patch e' un'attivita' frequente e che deve essere svolta con attenzione. E' molto importante verificare tutti i prerequisiti. Per le patch significative e' opportuno effettuare un clone dell'ambiente di produzione, applicare la patch sul clone e, solo terminata positivamente un'ampia serie di test su tale ambiente, si puo' pianificare l'applicazione della patch in produzione.

Cloning

Una normale installazione di EBS presso un cliente prevede la presenza di piu' ambienti. Oltre all'ambiente di produzione, su cui operano gli utenti finali, sono tipicamente presenti un ambiente di sviluppo, in cui vengono personalizzate le applicazioni o sviluppate eventuali integrazioni ed un ambiente di test, in cui vengono provate tutte le modifiche prima di un passaggio all'ambiente di produzione.
Come gia' riportato, la presenza di piu' ambienti e' molto importante per effettuare le necessarie verifiche in caso di applicazione di patch o di upgrade. Ed e' ovviamente fondamentale se si sviluppano applicazioni personalizzate.

Una normale esigenza e' quella di ribaltare un ambiente su un altro (eg. allineare il test con la produzione per verificare un problema occorso). Per effettuare una clonazione i principali passi sono:

• Prerequisiti
  Oltre alle verifiche sugli ambienti, sulla presenza dei prerequisiti, ... e' necessario applicare le ultime patch di Applications DBA, Autoconfig e Rapid Clone. Vanno quindi eseguiti gli script di AutoConfig sugli Application e, sincronizzato l'appsutil, vanno eseguiti sul DB. Infine va eseguito da menu, su ogni Application, il comando "Maintain snapshot information".
• Preparazione
  Sul DB Server spostarsi nella directory $ORACLE_HOME/appsutil/scripts/[CONTEXT_NAME] e quindi lanciare il comando perl adpreclone.pl dbTier
  Sull'Application Server spostarsi nella directory $INST_TOP/admin/scripts/[CONTEXT_NAME] e quindi lanciare il comando perl adpreclone.pl appsTier
• Copia
  Spegnere e copiare tutto! Prima l'Application, poi il DB. Va copiato proprio tutto, compresi link simbolici e file nascosti. Al termine della copia DB ed Application possono essere riavviati.
• Configurazione
  Sul TARGET DB Server spostarsi nella directory $ORACLE_HOME/appsutil/scripts/[CONTEXT_NAME] e quindi lanciare il comando perl adcfgclone.pl dbTier
  Sul TARGET Application Server spostarsi nella directory $INST_TOP/admin/scripts/[CONTEXT_NAME] e quindi lanciare il comando perl adcfgclone.pl appsTier
  Le utility sono interattive e chiedono i necessari parametri per la configurazione: SID, Port Pool, ...
• Post-clone
  Vi sono una serie di passi che dipendono dalla configurazione utilizzata e dall'utilizzo dell'istanza clonata e che quindi non sono strettamente necessari. Come la modifica dei file di profile, l'eventuale configurazione SSL, ...

Naturalmente sono possibili innumerevoli variazioni sul tema: in caso di topologie differenti, se la clonazione serve ad aggiungere un nuovo nodo Application, con versioni precedenti di EBS, con piattaforme differenti, ...
Ovviamente bisogna fare sempre riferimento alle note ufficiali su Metalink/My Oracle Support: Cloning Oracle Applications Release 12 with Rapid Clone [ID 406982.1].

Upgrade

L'upgrade tra versioni di EBS non e' banale. In generale e' necessario passare da una versione alla versione terminale prima di cambiare release e quindi applicare le patch correnti (eg. EBS 11.5.7 -> 11.5.10.2 -> 12.1.1 -> 12.1.3). Ogni cambio di release di EBS puo' comportare l'upgrade di OAS e di RDBMS. Vanno controllati tutti i prerequisiti e le matrici di certificazione per ogni componente, perche' cambiano per ogni release e tutti i passaggi debbono essere sempre certificati. Anche i prerequisiti sul sistema possono variare ed e' quindi spesso necessario adeguare anche il sistema operativo ospite.
Terminata questa fase di preparazione, l'attivita' di upgrade consiste generalmente nell'applicazione di una serie di patch con una sequenza prestabilita. Il processo puo' essere molto lungo e richiedere diversi giorni. Naturalmente se tutto e' stato preparato con attenzione e non vi sono errori: in caso contrario si e' costretti ad interrompere l'upgrade ed a ripartire dal principio.

Un'alternativa e' quella di preparare l'ambiente finale ed effettuare una migrazione applicativa con le API fornite da Oracle e script custom.

Oltre agli impatti applicativi gli upgrade introducono spesso variazioni significative nell'architettura e nella gestione. Ad esempio nel recente passaggio dalla versione 12.1 alla 12.2 viene utilizzato un nuovo Application Server (Web Logic) al posto del precedente (IAS); la modalita' di patch cambia ed al posto di adpatch si utilizza adop che consente l'online patching; la struttura di directory cambia e sono presenti file system doppi...

Common problems and workaround

Con un'architettura cosi' varia, con un numero cosi' grande di applicazioni e programmi, ... non e' facile parlare dei problemi piu' comuni e come evitarli!
Un ERP e' il sistema nervoso di un'azienda. Un blocco puo' essere gravissimo. Quindi provero' comunque a riportare qualche elemento utile.

La miglior cura e' sempre la prevenzione. Anziche' risolvere un problema e' meglio evitarlo.

• Sovradimensionate!
  Dimensionate l'architettura senza SPOF, con server generosi ed in grado di sostenere un carico molto piu' ampio del previsto. Per ridurre il costo del licensing e' meglio utilizzare processori piu' veloci ma con meno core sia per la componente DB che per gli AS. Il maggior costo HW/SW iniziale e' notevolmente inferiore al danno generato da un componente sottodimensionato.
  Per evitare SPOF (Single Point of Failure) e' ad esempio possibile utilizzare due o piu' Application Server in load balancing. Mentre per la componente database si puo' utilizzare un RAC oppure un cluster failover.
  Per un dimensionamento di massima si puo' considerare una oacore per 100 utenti ed una CPU per oacore. In realta' il carico dipende molto dalla tipologia di accessi e dall'utilizzo di form. Le modifiche custom introducono spesso rallentamenti poiche' non hanno lo stesso grado di affidabilita' delle componenti di prodotto.
• Piu' ambienti!
  Con un ERP e' necessario disporre di piu' ambienti (eg. sviluppo, test, produzione) utilizzati con regole precise. Gli ambienti vanno allineati tra loro periodicamente con il cloning.
• Siate pignoli!
  Patch, test dei programmi, gestione degli spazi, ... Sono attivita' che richiedono impegno costante, ma non vanno sottovalutate. La selezione e l'applicazione delle patch e' un'attivita' che richiede una certa attenzione, se non conoscete molto bene EBS e' meglio rivolgersi ad un esperto. Il test dei programmi e' molto importante: spesso si hanno problemi semplicemente perche' non sono stati svolti i test previsti. Il costante controllo degli spazi sul sistema operativo e sulla base dati permettono di evitare anomalie con effetti spesso molto problematici.
• Non invecchiate!
  La stabilita' e' importante ed un upgrade e' un'attivita' molto impegnativa... ma periodicamente bisogna aggiornare gli ambienti. E' importante mantenere il livello del sistema allineato alle certificazioni dei fornitori e disporre cosi' del necessario supporto.

Nonostante tutte le attenzioni alcuni problemi possono comunque presentarsi...

• Un tipico problema per le applicazioni Forms e' quello dei lock. Nella maggior parte dei casi non si tratta di errori di programma o di problemi del sistema: si tratta del semplice fatto che due utenti vogliono effettuare un'operazione di modifica sugli stessi dati. In qualche caso una sessione non viene chiusa e cosi' un lock impedisce di terminare le attivita' alle altre sessioni. Queste query identificano gli estremi delle sessioni che mantengono un lock e stanno provocando un attesa ad altre sessioni:
  SELECT l.sid, l.type, decode(l.lmode, 0, 'WAITING', 1,'Null', 2, 'Row Share', 3, 'Row Exclusive', 4, 'Share', 5, 'Share Row Exclusive', 6,'Exclusive', l.lmode) lock_mode, decode(l.request, 0,'HOLD', 1,'Null', 2, 'Row Share', 3, 'Row Exclusive', 4, 'Share', 5, 'Share Row Exclusive', 6,'Exclusive', l.request) request, count(*) lock_id FROM gv$lock l GROUP BY l.sid, l.type, l.lmode, l.request ORDER BY l.sid, l.type, l.lmode, l.request; SELECT a.object_id, b.object_name, sid||','||serial# session_id, username, command, schemaname, osuser, machine, terminal FROM gv$locked_object a, dba_objects b, gv$session WHERE a.object_id = b.object_id AND a.session_id = sid; ALTER system kill session 'sid,serial#'; REM Last Resort !!! SELECT sid, pid FROM v$session, v$process WHERE paddr=addr AND sid=XXX; # kill pid # kill pid # kill -9 pid
• Report ed attivita' non interattive vengono gestiti mediante i Concurrent. In caso di ritardo nell'esecuzione e' necessario controllare le code di richieste e l'eventuale blocco di uno dei processi di gestione. I log da controllare sono in $INST_TOP/logs/appl/conc/log. Tra questi il file principale e' SID_mesegiorno.mgr che contiene i messaggi di piu' alto livello. Nel caso in cui sia necessario i Concurrente Manager possono essere riavviati con il comando adcmctl.sh.

Storia

A mia memoria (e purtroppo sono vecchio) ricordo Oracle Applications dalla versione 10 ed era un'insieme di applicazioni Client/Server. Nel 1998 esce la versione NCA (Network Computing Architecture), la versione 11 (11.0), che ha avuto una notevole diffusione, e' del 1999.
Nel 2000 va in produzione la 11i (11.5.1) con interfaccia web. La versione 11i resistera' per oltre un decennio con uno stack tecnologico basato su 9iAS (1.0.x), Forms 6.0 e sull'RDBMS Oracle 8i. Dal punto di vista funzionale le differenze rispetto alle release precedenti sono notevoli. Si tratta della versione di Oracle EBS piu' diffusa. Nel tempo si arricchisce di nuovi moduli e prodotti ed aggiorna in parte lo stack tecnologico (mantiene pero' sempre Forms 6.0 e 9iAS 1.0). La release terminale e' la 11.5.10.2.
Nel 2007 viene rilasciata la versione R12 che rappresenta un'evoluzione naturale della 11i dal punto di vista funzionale. Lo stack tecnologico e' invece rinnovato e prevede Oracle AS 10gR2/R3 ed Oracle RDBMS 10gR2 o superiore. L'ultima release rilasciata (NdE alla data 2010-08 ed e' ancora l'ultima al 1Q 2013) e' la 12.1.3.

Sono molto importanti anche le acquisizioni svolte dalla Oracle Corporation nell'area ERP e CRM. Nel tempo sono stati acquisiti infatti: PeopleSoft/JD Edwards (2005), Siebel (2006), Agile (2007), Hyperion (2007), ... Cosi come nell'area Middleware nel 2008 e' stata acquisito un leader di mercato (BEA) e nel 2009, con l'acquisizione di SUN, addirittura il linguaggio Java e di MySQL!
L'integrazione tra i prodotti e' lenta ma procede a tutti i livelli: da quello tecnico (con integrazioni e razionalizzazioni di prodotti), a quello commerciale (con listini comuni ed offerte complementari).

Nelle seguente tabelle sono riassunte le ultime versioni disponibili di eBS e lo stack tecnologico (Source: Your server stinks!):

/etc

Le applicazioni Forms richiedono una JVM specifica (Oracle JInitiator o SUN JRE) certificata per il browser (Internet Explorer, Firefox o Safari) ed per il SO client utilizzato. I pop-up debbono essere abilitati oppure l'Application Server deve essere incluso nella white list... Altrimenti non funziona nulla!

Password di default: SYSADMIN/SYSADMIN APPS/APPS
Utenti demo (Vision Demo Install): MFG OPERATIONS SERVICES MRC HRMS /welcome
Utente di login: guest/[oracle|guest] (utente senza profilo associato)

I riferimenti per la connessione alla base dati sono contenuti nel file $INST_TOP/appl/fnd/12.0.0/secure/SID.dbc.

Documentazione? Link utili? Nulla di tecnico in italiano tranne... il documento che state leggendo!

• Steve Chan - Blog Il blog ufficiale, sempre aggiornato [NdE ma ora reindirizzato su https://blogs.oracle.com/ebstech/]
• Oracle - E-Business Suite Home Page Home page ufficiale Oracle - EBS R12 Documentation Library quasi 500 manuali, tutti spessi...
• Solution Beacon - Pocket Guides [NdE non piu' disponibile]
• ORACLENERD - Installation Guide [NdE non piu' aggiornato]
• oracle-base - Brief Installation Guide [NdE non piu' aggiornato]

Sono fondamentali i documenti contenuti su Metalink/My Oracle Support. E' impossibile elencarli tutti, quello che segue e' una prima guida (sono riportati solo i titoli dei documenti poiche' l'accesso richiede un'utenza autorizzata):

• Oracle E-Business Suite Release 12 Additional Configuration and Deployment Options [ID 380483.1]
• Oracle E-Business Suite R12 Configuration in a DMZ [ID 380490.1]
• Cloning Oracle Applications Release 12 with Rapid Clone [ID 406982.1]
• Descriptive Checklist for performing Rapid Clone with 11i/R12 [ID 811715.1]

Un'ultima cosa importante a proposito di eBS... Buona fortuna!

Titolo: Oracle Enterprise Business Suite (eBS) / Oracle Applications - R12
Livello: Avanzato (3/5)
Data: 31 Giugno 2010
Versione: 1.0.8 - 14 Febbraio 2022
Autore: mail [AT] meo.bogliolo.name