JD Edwards EnterpriseOne

Oracle JD Edwards EnterpriseOne (JDE) e' un ERP (Enterprise Resource Planning) distribuito dalla Oracle Corporation. Storicamente e' stato sviluppato dall'azienda di sviluppo ERP JD Edwards, che e' stata acquisita da PeopleSoft nel 2003, a sua volta acquisita da Oracle nel 2005.

Si tratta di un prodotto funzionalmente molto completo e complesso che contiene funzionalita' arricchite nel corso di venti anni di sviluppo. Si distingue da altri prodotti ERP (tra cui EBS di Oracle e SAP) per la minor complessita', per un'evoluta interfaccia utente e per un TCO tipicamente inferiore. Caratteristiche che rendono EnterpriseOne particolarmente apprezzato anche da aziende di media grandezza.

La sfida di questo documento e' quella di presentare l'architettura dell'ultima versione (9.1) di JDE 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 Java sia un solo un tipo di caffe' e che gli Apache siano solo una tribu' di indiani e' meglio che non proseguiate nella lettura!

EnterpriseOne si basa su tecnologie database, su web server, su Java Application Server, ... E' necessaria una conoscenza di base su tali argomenti per approcciarsi ad JDE.

Dal punto di vista funzionale JDE contiene centinaia di componenti suddivisi in moduli (eg. CRM: Customer Relationship Management, SCM: Supply Chain Management, ...) tipici di tutti gli ambienti ERP. L'interfaccia delle applicazioni e' web in modo nativo. JDE e' stato il primo ERP con tutte le funzionalita' disponibili da Apple iPad.

Un progetto JDE 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 JDE diverranno molto onerosi.

Architettura

I componenti di JDE 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 nella descrizione e' Oracle JDE 9.1.

Il software JDE puo' essere eseguito su piattaforme differenti che possono interagire tra loro in intranet/internet permettendo una grande flessibilita' con vantaggi sia per la scalabilita' che nel riutilizzo di componenti e delle infrastrutture aziendali.
Gli elementi funzionali, organizzati in suite applicative (eg. ALM: Asset Lifecycle Management, CRM: Customer Relationship Management) sono indipendenti dalle opzioni tecnologiche scelte e si presentano all'utente con le stesse modalita'.
La componente Tool rappresenta lo strato di integrazione ed ha un suo versioning specifico.
Dal punto di vista dell'infrastruttura sono molteplici le scelte disponibili per l'implementazione della soluzione JDE.

Un componente fondamentale di JDE e' la base dati, naturalmente un Oracle RDBMS e' la scelta suggerita per le ultime versioni.
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. Quella descritta e' l'architettura piu' semplice, per gli ambienti di produzione spesso si utilizzano configurazioni RAC o in failover cluster.
JDE utilizza l'istanza Oracle mediante la stringa di connessione (eg. ovsorcl con una express install). JDE utilizza gli schema JDE* (eg. JDECTL910, JDEDATA910, ...) che comprendono circa 5000 tabelle. JDE non utilizza funzionalita' specifiche di Oracle quali: trigger, package PL/SQL, job, ... JDE utilizza semplicemente un grande numero di tabelle (F0006: Business Unit Master, F0005: User Defined Code Values, F0902: Account Balances, ...) e i relativi indici. Per JDE 9.1 la versione Oracle di riferimento e' la 11gR2.

Quando un'utente si collega con il proprio browser a JDE utilizza un'applicazione web con una classica architettura a piu' livelli. Il primo server ad essere contattato e' il JDE Web Server, le richieste piu' complesse vengono elaborate dall'Application Server JDE Enterprise Server e restituite all'utente con il protocollo HTTP. Quando sono richieste attivita' non interattive (eg. esecuzione di una stampa, elaborazione di un bilancio, ...) JDE utilizza un proprio Job Scheduler che presenta un'interfaccia web per la gestione.
Nell'architettura completa sono disponibili diversi Application Server, alcuni dei quali opzionali, tutti basati sul WebLogic: HTML Server, BI Publisher Server, Mobile Server, AIS Server, Server Manager.

I diversi servizi utilizzano porte socket specifiche (tipicamente configurabili nel file JDE.INI). Ecco le principali:

Per l'applicazione delle patch e per il package build si utilizza il Deployment Server (su MS Windows). Il Deployment Server utilizza un'istanza Oracle locale 11gR2.

Gli utenti finali accedono al sistema dal loro browser. I browser certificati sono praticamente tutti i piu' recenti e diffusi: Microsoft Internet Explorer per Windows, Mozilla Firefox per Linux, Apple Safari per Mac OS e Google Chrome per tablet Android.
Gli utenti sviluppatori utilizzano invece una workstation che e' un'installazione dell'ambiente di sviluppo su MS Windows.

Principali componenti

L'elenco seguente riporta i principali moduli disponibili (tra parentesi alcuni esempi dei singoli componenti licenziabili):

• Customer Relationship Management - CRM (Advanced Pricing, Case Management, CRM Foundation, Customer Self Service, Fulfillment Management, In-Memory Sales Advisor, Sales Force Automation, Sales Order Management, One View Reporting for Sales Order Management, Service Management, One View Reporting for Service Management, Service Management Foundation)
• Manufacturing and Supply Chain Management - SCM (Advanced Stock Valuation, Agreement Management, Apparel Management, ...)
• Supply Chain Planning (Oracle Advanced Planning Command Center, Oracle Advanced Supply Chain Planning, ...)
• Supply Management - SM (Buyer Workspace, Operational Sourcing, Procurement and Subcontract Management, ...)
• Asset Lifecycle Management - ALM (Advanced Real Estate Forecasting, Capital Asset Management, ...)
• Project Management - PM (Advanced Contract Billing, Contract and Service Billing, Project Costing, ...)
• Financial Management Solutions - FMS (Expense Management, Financials, Option: Environmental Accounting and Reporting, One View Reporting for Financials, System Foundation)
• Health, Safety and Environment - HSE (Health and Safety Incident Management, One View Reporting for Health and Safety Incident Management)
• Human Capital Management - HCM (Human Resources, Payroll, ...)
• Tools & Technology (Adapter for MQ Series, Adapter for MSMQ, Core Tools and Infrastructure, Oracle Technology Foundation for JD Edwards EnterpriseOne, Oracle Technology Foundation for JD Edwards EnterpriseOne Upgrade)
• One View Reporting - OVR
• Application Management
• Application Testing
• Application Integration Architecture

Licensing

Le politiche di licensing di JDE non sono oggetto di questo documento... si tratta comunque di un aspetto molto importante.
Tipicamente JDE viene licenziato per Application User con un costo per ogni singolo modulo acquistato. Sono inoltre acquistabili gli UPK (User Productivity Kit).

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

Installazione

JDE e' disponibile in ambiente multi piattaforma e sono possibili diverse modalita' di deploy sia su macchine fisiche che su macchine virtuali. E' pertanto impossibile fornire una guida univoca per l'installazione. La documentazione ufficiale riporta le diverse modalita' di installazione tra cui la Express Installation (utilizzando VM template di OVM) e le installazioni complete su Linux o su Microsoft Windows.

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. In questi casi si utilizza tipicamente l'installazione JDE Standalone che crea su un'unica macchina un database Oracle E1Local, installa tutto il software e fornisce un ambiente DEMO.

Se invece e' rivolta ad un ambiente di produzione... la fase di progettazione diventa determinante. Le attivita' piu' determinanti sono prima la verifica delle certificazioni e la scelta dei componenti da installare, e poi, effettuata l'installazione, l'applicazione delle patch. I passi per un'installazione completa sono:

• Installazione del Deployment Server
• Installazione del Platform Pack (Enterprise Server e Database Server)
• Definizione dell'Installation Planner
• Esecuzione dell'Installation Workbench
• Installazione del HTML Web Server
• Installazione delle workstation gli amministratori e per gli sviluppatori

La maggioranza dei passi indicati viene eseguita con wizard (eg. OUI: Oracle Universal Installer) ma il tempo necessario per una configurazione completa e' significativo e richiede competenze specifiche.
Il software va scaricato dal Sito Oracle E-Delivery. Anche l'accesso al MOS (My Oracle Support) e' una necessita': l'elenco dei prerequisiti, delle certificazioni, ... sono fondamentali.

Tra le diverse possibilita' JDE puo' essere installato anche su sistemi Oracle Engineered come l'ODA. Nel deployment su ODA viene utilizzata la configurazione Virtualized (OVM) utilizzando il dominio ODA_BASE per l'RDBMS Oracle. Vengono invece utilizzate VM installate da template per il JDE Deployment Server, il JDE Web Server ed il JDE Enterprise Server. Il Deployment Server e' su SO Microsoft Windows, tutti gli altri ambienti sono su Oracle Linux. E' consigliabile utilizzare un bundle 2.8 o successivo a causa del limite del local repository (cfr. Best practices for deploying JD Edwards EnterpriseOne on Oracle Database Appliance ID 2120907)

Un ultimo consiglio per l'installazione: usate nomi di server in minuscolo, brevi (<13 caratteri) e senza l'indicazione del dominio.

Utilizzo

Effettuato il login, tutti gli utenti hanno menu personalizzati con accesso ad applicazioni differenti, a seconda delle loro abilitazioni.

L'interfaccia e' web con un menu' principale chiamato EnterpriseOne Menu da cui sono disponibili tutte le funzionalita' applicative.
L'interfaccia, sopratutto rispetto ad altri ERP, e' particolamente evoluta e consente l'accesso anche da Apple iPad e da tablet Android (dalla Tools release 9.1.4). Particolarmente utili sono i recenti aggiornamenti della release 9.1 che ha introdotto le EnterpriseOne Page (che consentono di integrare pagine web ed applicazioni esterne) e il Carousel Navigation (che consente di spostarsi facilmente tra le attivita' aperte).

Amministrazione

JDE fornisce un'interfaccia di amministrazione per tutti i comandi dell'infrastruttura tecnologica utilizzata. Ad esempio la gestione dei tablespace Oracle non deve essere effettuata direttamente ma da EnterpriseOne con l'application P96717. In questo modo la gestione risulta semplificata, anche se in caso d'errore le competenze di DBA e sistemistiche risultano comunque fondamentali.

Il JDE Object Management Workbench Configuration program (OWM) automatizza la maggioranza della gestione del software. Con il programma OWM (P98220) si configurano:

• Constants
• SAR System Integration
• Logging System
• Object Action Notification
• Notification Setup
• Activity Rules
• User Roles
• Allowed Actions
• Save Locations

Con il programma Work With Servers (P986116) si gestiscono i Server jobs ed i JD Edwards EnterpriseOne subsystems. L'amministratore utilizza questo programma per gestire le attivita' correnti in esecuzione su JDE. Anche gli utenti hanno accesso allo stesso programma, ma possono visualizzare e gestire i soli job associati al loro UserId.

JDE fornisce un avanzato job scheduling per sottomettere attivita' particolamente pesanti o ripetitive. Per la sua gestione si utilizzano: Work With Scheduled Jobs (W91300B), Report Management (GH9111), Job Scheduler (GH9015), Schedule Jobs (P91300); Scheduling Advanced Options (W91300I).

I piu' comuni comandi per l'avvio/fermo degli ambienti sono:

Un compito importante dell'amministratore e' l'apertura di chiamate al supporto (SR: Service Request). Il mantenimento del supporto e' fondamentale con JDE (come con tutti gli ERP).

Patch

Basta pensare alle continue variazioni della legislazione fiscale per capire l'importanza dell'aggiornamento di un ERP. Su JDE il rilascio di patch e' frequente ed e' assolutamente necessario mantenere aggiornato il sistema rinnovando il canone di manutenzione e seguendo una completa procedura di gestione dei rilasci.

Vi sono diversi tipi di patch/update: ESU (Electronic Software Update), ASU (Application Software Update), SP (Service Pack). Mentre una Tools Release e' relativa al codice JDE foundation (System).
Per l'applicazione delle ESU e' necessaria la presenza del Deployment Server che e' quindi necessario per gli ambienti di produzione (per un'installazione demo non e' tecnicamente necessario il Deployment Server). Il Change Assistant e' un tool java che semplifica la ricerca e l'installazione delle patch.

Il sito ufficiale su cui tutte le patch sono rese disponibili e' Oracle MOS (My Oracle Support).

Upgrade

L'upgrade tra versioni di JDE non e' banale. 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 passi 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.

Cloning

Una normale installazione di JDE 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. In realta', per essere precisi, JDE definisce le diverse tipologie di ambiente come produzione (PD910), pristine (PS910 un ambiente senza customizzazioni), deployment (DEP910), development (DV910), ...
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 la verifica delle differenze tra ambienti e' molto utile il Data Dictionary Compare report (RD969200NA). Ovviamente bisogna fare sempre riferimento alle note ufficiali su MOS (My Oracle Support): How To Create a Mirror / Clone Image of one Environment to Another [ID 626143.1].

Sono possibili innumerevoli variazioni sul tema: in caso di topologie differenti, se la clonazione serve ad aggiungere un nuovo server, con versioni precedenti di JDE, con piattaforme differenti, ...

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.
• 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.
• 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 JDE 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 Oracle 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 v$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 v$locked_object a, dba_objects b, v$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 -9 pid
• Un tipico problema di JDE e' sugli UDC (user-defined codes). In caso di errori nella definizione (dovuti ad una conversione o ad una modifica diretta dei dati) e' infatti possibile bloccare il funzionamento di applicazioni con sintomi diversi.
  La tabella che contiene gli UDC e' la F0005. Se una tabella di business contiene valori non riportati nella tabella F0005 allora e' presente un errore di integrita' degli UDC. Per la verifica e' possibile agire direttamente sulla base dati:
  SELECT DISTINCT MCRP29 FROM F0006 WHERE MCRP29 NOT IN ( SELECT DISTINCT SUBSTR(DRKY,8,3) FROM F0005 WHERE DRSY = '00' AND DRRT = '29' )
  Il campo DRKY e' lungo 10 mentre la maggioranza dei codici sono lunghi 3: ecco la ragione della substr(). Come fare a trovare le descrizioni delle tabelle e dei campi? Utile puo' essere questa pagina.

Storia

Oracle JD Edwards EnterpriseOne (JDE) e' un ERP (Enterprise Resource Planning) sviluppato da JD Edwards ed ha una storia quasi ventennale di continua evoluzione. JDE e' utilizzato sia da aziende di media grandezza (che ne apprezzano il TCO limitato) che da aziende internazionali con problematiche di valute diverse, regimi fiscali diversi, lingue diverse, installazioni multi sito, ...
Nel 2003 JD Edwards viene acquisita da PeopleSoft, a sua volta acquisita da Oracle Corporation nel 2005. Sono molto importanti anche le altre acquisizioni svolte dalla Oracle Corporation nell'area ERP e CRM. Nel tempo sono stati acquisiti infatti: Siebel (2006), Agile (2007), Hyperion (2007), ... Cosi come nell'area Middleware nel 2008 e' stata acquisito un leader di mercato (BEA con il prodotto WebLogic) e nel 2009, con l'acquisizione di SUN, addirittura il linguaggio Java e di MySQL!

Nelle seguente tabelle sono riassunte le ultime versioni disponibili di JDE (Source):

/etc

Le password di default (in una installazione Express):

• OS: root/ovsroot oracle/oracle jde900/ovsjde900E1
• Oracle RDBMS: sys system dbsnmp sysman/ovsadminE1
• WebLogic: weblogic/ovsadminE1
• EnterpriseOne: JDE/JDE

Altro prodotto molto importante di JD Edwards e' JD Edwards World. Si tratta sempre di ERP realizzato per gli ambienti IBM Power Systems, System i.

Sono fondamentali i documenti contenuti su Oracle My Oracle Support (MOS).

Un'ultima cosa importante proposito di JDE: Buona fortuna!

Titolo: Oracle JD Edwards EnterpriseOne (JDE)
Livello: Avanzato (3/5)
Data: 1 Agosto 2014
Versione: 1.0.1 - 15 Agosto 2014
Autore: mail [AT] meo.bogliolo.name