Toolbox

Openbravo 2.50 presenta il nuovo concetto di Modularità: la capacità per gli sviluppatori di costruire, impacchettare e distribuire Moduli di Estensione e per gli utenti di installare, disinstallare e modificare i Moduli di Estensione.

Un Modulo di Estensione è un pezzo di funzionalità addizionale che può essere deployato opzionalmente e indipendentemente su Openbravo ERP. Esempi di moduli sono : reports addizionali , finestre addizionali, connettori, pacchetti di contenuti (traduzioni, carrello dei conti, lista di codici di tasse , categorie di prodotti , etc).

Gli obbiettivi della modularità sono :

Facilitare il contributo a Openbravo ERP permettendo lo sviluppo distribuito e disaccoppiato e la manutenzione di aspetti opzionali.
Fornire alla Community un vasto insieme di estensioni per incontrare i loro unici requisiti di business senza gonfiare il progetto core.
Abbrevviare i cicli di implementazione abilitando gli integratori di sistema per sviluppare template micro-verticali.

Questo documento contiene il manuale dello sviluppatore per costruire moduli per Openbravo ERP.

Prima di iniziare

Requisiti di Sistema

Per sviluppare un modulo è richiesto l'utilizzo di Openbravo 2.50 o superiore. Attualmente è disponibile 2.50 alpha1 stabilization branch.

Configurare la propria istanza

Ci sono alcuni nuovi requisiti nella 2.50 quando si configura l'ambiente. Consultare la documentazione Development Stack Setup prima di procedere.

Concetti

Prima di iniziare è anche richiesto capire alcuni nuovi concetti. Questi concetti sono descritti in dettaglio nelle seguenti sezioni in questo documento.

Artefatti in un Modulo di Estensione

Ci sono 4 tipi di artefatti che possono essere inclusi in un Modulo di Estensione:

Componenti dell'Application Dictionary: Metadata che descrivono Openbravo ERP come ad esempio Windows, Tabs, Fields, Messages, etc.
Risorse Software: I componenti Openbravo ERP non espressi metadata come definizione xml di oggetti di schema database, classi java, librerie jar , files XML , etc.
Dati di Riferimento: Informazione di Business riferite da transazioni e che tendono a non cambiare spesso come Carrello dei Conti, Codici Tasse , banche, categorie prodotti, etc. Si possono definire a livello system, client o organizzazione.
Script di Configurazione: Cambi nei componenti dell' Application Dictionary applicati a altri moduli per supportare un insieme specifico di processi di business, come campi o schede Hide / show , processi standard , etc. Sono permessi solo cambi significativi.

La piattaforma Openbravo non può essere modificata attraverso i moduli. In particolare non è possibile modificare codice wad (codice della src-wad ) in un module. Non dovrebbe essere un limite visto che la piattaforma è progettata per essere estensibile.

Tipi di Moduli di Estensione

Ci sono tre tipi Moduli di Estensione:

Moduli: Base content container. Entro un Module si può includere tutti i tipi di artefatti ma Scripts di Configurazione : Componenti di Application Dictionary, risorse Software e dati Reference. Moduli sono il modo di aggiungere nuovi elementi a Openbravo ERP. In un Modulo non si può modificare elementi di altri moduli -incluso il core-. La ragione di ciò è evitare dipendenze incrociate fra moduli vari.
Packs: un Pack è una collezione di moduli e non altro. Si intendono per semplificare il deployment e incoraggiare moduli fine grained . Packs speciali sono packs di localizzazione e di verticalizatione .
Templates Industry: una combinazione di un Pack e un script configurazione che è capace di modificare il comportamento di components AD in Modules inclusi nel Pack.

Tre di essi sono genericamente definiti come moduli.

Packaging e files .obx

Tutto il contenuto di un modulo -codice, file di utility , dati- è impacchettato tutto insieme in una cartella isolata per ogni modulo. Tutto il contenuto in quella cartella è connesso solo a quel modulo. C'è una nuova cartella nella cartella principale di Openbravo chiamata moduli dove si trovano tutti i moduli che sono stati installati o sviluppati . Per ogni modulo c'è una cartella identificata dal modulo con nome java. In quella cartella la struttura del codice sorgente di openbravo (config, src, src-db, lib, etc.) è replicato come richiesto per memorizzare il contenuto di quel modulo.

Moduli sono distribuiti come files .obx che sono file compressi della cartella del modulo . Si possono direttamente decomprimere usando un tool zip per esplorarne il contenuto.

Console dell'Amministratore dei Moduli (Module Manager Console=MMC)

Questa è una nuova finestra in Openbravo ERP dove i System administrators possono vedere i Moduli di Estensione installati nelle loro istanze, e dove possono installarne nuovi e disinstallarne gli esistenti o modificare quelli già installati.

Repository Centrale

Il Repository Centrale è un sistema incorporato nel Forge di Openbravo per fornire servizi correlati ai Moduli di Openbravo ERP per sviluppatori e utenti :

Sviluppatori:
- Registrare un modulo: uno sviluppatore registra un nuovo modulo nel Repository Centrale per ottenere identificatori unici globali che gli sviluppatori usano (è altamente consigliato registrare un modulo prima di iniziare lo sviluppo del modulo).
- Pubblicare una nuova versione di un modulo: un modulo può avere diverse versioni nel suo ciclo di vita. Per ogni versione i proprietari del modulo necessitano di modificare l'informazione nel Repository Centrale per rendere questa nuova versione disponibile agli utenti.

Utenti:
- Ricerca moduli: dal MMC gli utenti possono fare delle richieste al Repository Centrale per ottenere una lista di moduli che rispondono alla richiesta utente.
- Ricerca modifiche di una lista di versioni di modulo: dal MMC gli utenti possono fare delle richieste al Repository Centrale se ci sono modifiche disponibili (versioni più recenti) per tutti i moduli installati nelle lore istanze (o solo per uno di essi).
- Recuperare il codice di una versione di un modulo ( per essere installato ): per entrambi installare nuovi moduli e modificare quelli correnti è necessario ottenere il file compresso (file .obx) che memorizza codici di modulo.

Introduzione al processo di sviluppo di un Modulo

Il processo di sviluppo di un Modulo comprende 3 passi principali :

Registrazione del Modulo nell'Application Dictionary e nel Repository Centrale.
Sviluppo degli artefatti inclusi nel Modulo. In funzione delle specifiche funzionali e del disegno tecnico del modulo può essere incluso solo un tipo di artefatto o una combinazione di essi. Nelle seguenti sezioni ogni tipo di artifatto è descritto in dettaglio.
Estrazione del file .obx del Modulo e pubblicazione nel Repository Centrale.

I passi 1 e 3 sono comuni a tutti i tipi di modulo e diretto. Il passo 2 dipende dai requisiti del modulo. Non ci sono cambiamenti sostanziali nel modo di sviluppare codice Openbravo ERP rispetto alle releases precedenti alla 2.50 ma pochi dettagli che bisogna sapere e che sono descritti successivamente in questo documento. In particolare i task di sviluppo (crea/modifica database, build e compile il system, etc.) sono stati leggermente modificati per adattarli al paradigma della Modularità.

Bisogna essere consapevoli che da ora ogni pezzo di codice di Openbravo ERP appartiene a un modulo, incluso il core Openbravo ERP stesso. Si dovrebbero fare tutti i nuovi sviluppi tramite moduli, incluse le customizzazioni. Si può ancora fare cambiamenti direttamente in altri moduli -incluso il core di Openbravo ERP - ma è vivamente consigliato di non farlo . La manutenzione sarà notevolmente semplificata se si mantengono le modifiche isolate incorporandole nei moduli.

Le seguenti sezioni descriveranno ogni passo in dettaglio.

Registrare un Modulo

La prima cosa da fare è creare una nuovo record per il Modulo nella finestra Modulo nell'Application Dictionary :

Ci sono alcuni dettagli a cui bisogna stare attenti:

Ogni modulo ha il proprio linguaggio nativo (base). Nelle seguenti sezioni il processo di traduzione è descritto, da ora bisogna solo scegleire il linguaggio in cui si preferisce sviluppare la UI del modulo. Naturalmente se si sceglie l'inglese sarà più facile disseminare (trovare persone che lo traducono in altri linguaggi).
Nome, descrizione e help sono le proprietà usate per spiegare nel Repository Centrale che modulo è. Scriverli in stile naturale usando il linguaggio di default scelto .
Numero di Versione è composto da 3 numeri separati da 2 punti to match the Openbravo template per i numeri di versione. In questo campo bisogna mettere la versione corrente su cui si sta lavorando (ci potrebbero essere versioni multiple del modulo). Più in là Numeri di Versione sono spiegate in dettaglio.
Il package java è un identificatore unico del modulo e deve corrispondere con le regole di denominazione dei packaging Java come descritte nelle specifiche Java (names e package names). Bisogna impostare questo valore attentamente perchè una volta registrato il modulo sul Repository Centrale non è possibile cambiarlo. Se il modulo include files java che devono essere impacchettati dentro il package java del modulo o in subpackages all'interno del modulo. Esempi di packages java per un modulo sono org.openbravo.examples.helloworld, com.yourcompany.yourPackage, org.yourfoundation.yourPackage.yourSubpackage, etc.
Scegliere il Tipo (Module, Pack, Template) come descritto nella sezione dei Concetti
In sviluppo è una proprietà booleana per lasciare sapere al sistema che quel modulo è in fase di sviluppo. Solo i moduli in sviluppo verrà esportato dai tools di sviluppo e il System solleva un errore se si prova a modificare qualche componente su un modulo che non è in sviluppo
Benchè si possa avere più di un modulo in sviluppo si può settare quello che si è scelto per default quando si sviluppa. Questo è solo un modo di settare come valore di default per il modulo quando si modifica l'Application Dictionary
Alcuni moduli non avranno UI (ad esempio un connettore a sistema di banking o un web service) così non c'è bisogno di tradurli
Se il modulo è un modulo traduzione di un altro modulo bisogna spuntare questo flag per permettere agli utenti di cercare le traduzioni. Più in là in questo documento c'è una piena descrizione di come creare un modulo traduzioni.
Se il modulo ha Carrello dei Conti bisogna spuntare questo flag per permettere al System di usarli durante i processi Initial Client/Organization Setup. Più in là in questo documento c'è una descrizione di come aggiungere un Carrello dei Conti al modulo.
Se il modulo ha Dati Reference standard bisogna spuntare questo flag per permettere al System di usarli durante i processi Initial Client/Organization Setup. Più in là in questo documento c'è una descrizione di come aggiungere Dati Reference Standard a un modulo.
Bisogna anche scegliere la licenza che si sta usando per distribuire il modulo. Scegliere un tipo di licenza dalla lista drop-down e scrivere lì accordo di licenza che verrà mostrato all'utente quando si installa o modifica il modulo. Openbravo NON SUPERVISIONA il contenuto del modulo nè la licenza scelta. Ognuno è responsabile di impostare questa informazione nel modo appropriato.
L' autore del modulo verrà mostrato all'utente quando esplora il Repository Centrale e quando lo installa . Anche l'utente potrà navigare da lì al modulo url
Se si sta lavorando su una nuova versione del modulo si può spiegare quali sono i cambiamenti che questa nuova versione include (bugs risolti in versioni minori, nuove funzionalità in quelle maggiori) nel campo "Informazione di Modifica".

Il tab Include è inteso solo per Packs e Industry Templates. In questo tab si includono tutti i moduli che fanno parte del Pack. Si può solo scegliere da quelli che si è installato nella tua istanza. Bisogna fornire il Numero di Versione per ognuno di essi seguendo il template Openbravo come descritto. In una sezione successiva c'è una descrizione di come il sistema gestisce Numeri di Versione di Includes (per Packs and Industry Templates) e per Dipendenze (per Moduli).

Il tab Dipendenza è intenso solo per i Moduli. In questo tab si dichiarano tutti i Moduli da cui il Modulo dipende. E' di estrema importanza dichiararli correttamente cosi che il sistema controllerà quelle dipendenze siano soddisfatte quando l'utente installa o modifica il modulo. E' anche importante dichiararli appena si conoscono perchè alcuni tools e processi nel processo di sviluppo tengono in conto dipendenze e il risultato può essere sbagliato se non sono dichiarati quando si sviluppa il modulo. Si dichiarano le dipendenze tra i moduli che sono stati installati nella propria istanza. Tipicamente un modulo dipenderà dal core (Version no. 2.50.0000 o superiore) e eventualmente in altri moduli. Bisogna fornire il Numero di Versione per ogni Modulo che dipende dal seguente template Openbravo. Opzionalmente si può fornire un secondo Numero di Versione (superiore al precedente) per esprimere che il Modulo dipende da un Numero di Versione di quel modulo fra i due forniti. Più in là in questo documento c'è una spiegazione completa di Numeri di Versione.

Non c'è alcun bisogno di modificare il tab Traduzione. E' un tool per traduttori e verrà descritto nella sezione traduzioni.

Se il Modulo include una tabella nell'Application Dictionary allora bisogna registrare uno (o più) packages nel Modulo. Per una piena descrizione di come i packages siano usati vedere DAL developers manual. Per ogni package bisogna settare le seguenti proprietà:

Nome, che verrà usato nelle entità xml delle tabelle assegnate a esso
Descrizione, usata per spiegare lo scopo del package
Nome Java, che deve corrispondere alle regole dei nomi per packaging Java come descritte nelle specifiche Java (names e package names). Dovrebbe essere uguale al nome del package del Modulo (se c'è un solo package) o un subpackage dello stesso.

Se il Modulo include un oggetto di schema di database (una table, una stored procedure, etc.) o un AD message allora bisogna definire il DB_Prefix. Questa è una stringa di sette caratteri. Tutti i nomi di oggetti di oggetti di schema di database devono iniziare con questo prefisso così come deve rispondere ai requisiti di denominazione di Oracle e PostgreSql (maiuscole e minuscole e memorizzato in maiuscolo, caratteri alfanumerici e simbolo di sottolineatura ("_") , inizia con un carattere alfabetico). Si può solo registrare un DB_Prefix, solo al Modulo Openbravo core è permesso averne più di uno. DB_Prefix è necessario per garantire che non ci siano conflitti di nomi quando si installano i moduli.

Una volta completato il set up del Modulo bisogna registrarlo nel Repository Centrale. E' necessario per assicurare che il DB_Prefix e il package java package non sia già registrato da altri Moduli. Si può fare attraverso il pulsanteRegistra Modulo nella scheda principale della finestra Module. Verrà inviato al Repository Centrale le informazioni del Modulo. Se il DB_Prefix e il nome del package java non sono già registrati verranno registrati e restituito un messaggio di successo e il Modulo nella propria istanza verrà marcato come registrato. Se c'è un conflitto allora il processo proporrà un altro DB_prefix o nome di package.

Completata la registrazione del modulo si può partire a sviluppare gli artefatti!

Sviluppo di artefatti del Modulo

Come detto nella sezione Concetti ci sono quattro tipi di artefatti: Componenti dell'Application Dictionary, Risorse Software, Dati Riferimento e Script di Configurazione. I requisiti del modulo e il suo design tecnico definiranno gli artifatti necessari per costruire un modulo. Questo documento spiega i dettagli di cui si ha bisongno per essere cosciente di ogni tipo di artefatto , uno per uno, legati alla modularità. Non si spiega come usarli insieme per costruire soluzioni, viene descritto nel Openbravo Developers manual. Alla fine di questo documento c'è una spiegazione di un numero di semplici esempi "Hello World" che coprono tutti i diversi tipi di soluzioni.

Componenti dell'Application Dictionary (Componenti AD)

La maggiore parte dei componenti AD possono essere inclusi in un modulo ma vi sono poche eccezioni che sono spiegate più in là in questa sezione. La regola generale per descrivere come i componenti di Applications Dictionary siano inclusi nel modulo è semplice : settare il campo modulo di quel componente con il nome del modulo. Se si ha un solo modulo in sviluppo o si sta lavorando sul modulo di default questo passo verrà fatto automaticamente dal sistema.

Solo i moduli segnati come "in sviluppo" sono disponibili quando si edita un componente AD . Se si cambia una proprietà in un componente AD che non è in sviluppo il sistema segnalerà un errore per evitare di eseguire cambi non programmati.

Le traduzioni sono gestite in modo particolare e non c'è bisogno di preoccuparesene in fase di sviluppo . C'è una descrizione dettagliata sul processo di traduzione nella sezione Translations. Si ricordi che il modulo ha un linguaggio nativo (base) language così che i componenti UI (Windows, tabs, fields, elements, messages, textInterfaces, etc.) che si sviluppano devono essere creati in quel linguaggio.

Informazione di accesso non sono incluse nei moduli cosi si può dimenticarsene in fase di sviluppo. In una sezione successiva verrà spiegata come includere una particolare configurazione per openbravo rbac (role based access control).

Ci sono alcuni dettagli in cima alla regola generale che sarebbe opportuno capire per avere un miglior controllo del contenuto del modulo. Vale la pena di riesaminare ogni tipo di componente AD.

Tabella e Colonna

Registrare tabelle nell' AD è la prima eccezione alla regola generale . Tabelle non sono assegnate direttamente a un modulo ma al package in un modulo. È necessario da DAL per gestire propriamente packaging delle entità generate e il naming xml. Solo packages di moduli "in sviluppo" sono disponibili quando si modifica una tabella. Il modulo di una tabella è il modulo del package di una tabella.

Colonne sono assegnate per default al modulo della loro tabella. Ma si può volere aggiungere nel modulo una colonna entro una tabella in un modulo differente (eg. aggiungere una nuova colonna alla tabella M_Product nel modulo core ). Per far ciò bisogna usare una regola di denominazioneper quella colonna : il suo nome fisico (proprietà ColumnName) deve cominciare dal prefisso "EM_XXX_" dove "XXX" è il DB_Prefix del modulo. "EM" sta per External Module. Il processo Crea Colonne da DB tiene in conto tutte queste regole quando si importano colonne dal database.

Finestra, Scheda e Campo

Finestra, Scheda e Campo segue la regola generale. Tre di questi sono collegati a un modulo. Per default quando aggiungi una scheda alla finestra, verrà collegata al modulo della sua finestra e quando si aggiunge un campo a una scheda , verrà collegato al modulo della sua scheda. Questò è vero ma quando la finestra o i moduli di scheda tab non sono in sviluppo. Allora il modulo di default verrà proposto. Il processo Crea campi tiene in conto tutte queste regole quando si creano campi dalle colonne di tabelle.

Quando si modifica la sequence del campo il sistema garantirà che non venga cambiata il numero di sequence dei campi che non sono nel modulo, cosi se si aggiunge un nuovo campo in una scheda di un altro modulo il numero di sequence dei campi originali non verrà modificato. Se si modifica manualmente questa informazione bisogna sapere che non si puà modificare informazioni in un modulo che non è in sviluppo. Si applica anche se si sta aggiungendo una scheda addizionale a una finestra in un altro modulo.

La classe scheda e il mapping è automaticamente gestito dal sistema e non c'è bisogno di preoccuparsene. oltre verrà spiegato come Classe e Mapping sono gestite e cosa si può fare per aggiungere entrate addizionali .

Riferimento

Ci sono 4 tipi di riferimento : Data type, List validation, Search validation e Table validation. In Openbravo 2.50 solo List validations e Table validations possono essere incluse in un modulo diverso dal Openbravo core. Data types e Search validations saranno supportate in moduli in releases future (al momento si richiede di modificare Openbravo WAD).

Tutti i valori inclusi in una List validation sono inclusi nel modulo dove la List validation è definita. In Openbravo 2.50 nel proprio modulo non si possono aggiungere nuovi valori alla List validation in un modulo differente nè modificare i valori inclusi in esso.

Report e Processo

Reports e Processi seguono la regola generale. Si può dichiarare un nuovo processo o report nel tuo modulo creando una nuova riga nella finestra Report e Process e collegando quella riga al modulo. Tutti i parametri in un Report o Process verranno inclusi nel modulo dove il Report o Processo è dichiarato.

Form

I Forms seguono la regola generale. Si può dichiarare un nuovo form nel modulo creando una nuova riga nella finestra Form e collegando quella riga al modulo.

Messaggio

I Messagi seguono la regola generale con un dettaglio in più che bisogna tenere presente. Si può dichiarare un nuovo messaggio nel modulo creando una nuova riga nella finestra Message e collegando quella riga al modulo, e la chiave di ricerca del messaggio deve iniziare dal db prefix del modulo (per evitare conflitti fra messaggi di diversi moduli). Significa che non si può includere nel modulo un messaggio con una chiave di ricerca numerica che possa essere sollevata da un oggetto pl/sql con la funzione RAISE_APPLICATION_ERROR.

Interfaccia di Testo

La finestra Interfaccia di Testo di solito non è editata manualmente ma righe sono automaticamente generate dal processo di traduzione quando analizza files da tradurre. Questo processo tiene in conto di fare il package del file da tradurre e la riga di Interfaccia di Testo viene propriamente assignata al modulo. Questo processo dovrebbe essere trasparente per gli sviluppatori ma si può esplorare le righe che i sviluppi manuali hanno creato e modificarle.

C'è una descrizione dettagliata del processo di traduzione nella sezione Traduzioni .

Elemento

Gli Elementi sono di solito generati automaticamente generati dal processo Synchronize terminology quando si creano nuove colonne. Questo processo tiene conto del nome delle colonne che sono state incluse nel modulo e cerca nel modulo e nei moduli da cui dipende il modulo stesso un elemento con quel nome di colonna. Se viene trovato la colonna verrà collegata a quell elemento, se no un nuovo elemento verrà creato nel modulo. Questo processo dovrebbe essere trasparente per gli sviluppatori ma si può esplorare gli elementi inclusi nel modulo e modificarli.

Categoria Campo, Input Ausiliare, Callouts e Validazioni

Questi 4 componenti dell' Application Dictionary seguono la regola generale. Si può dichiarare un nuovo componente fra questi nel modulo creando una nuova riga nella finestra e collegandola al modulo.

Modello - Mapping dell'Implementazione

Modello - Mapping dell'Implementazione è una generalizzazione del Modello-Concetto di Oggetto che era presente nelle precedenti releases. Si può vedere una descrizione dettagliata nella spiegazione del Modello - Concetto di Implementazione.

Attraverso questa nuova finestra si può includere nel modulo le righe che servono per aggiungere al file web.xml del contesto Openbravo.

Modello - Mapping dell'Implementazione segue la regola generale. Si può dichiarare una nuova riga creando un record nella finestra di Modello - dell'Implementazione e collegarla al modulo. Tutti i mappings e i parametri assegnati a esso verranno inclusi nel modulo dove il Modello - Mapping dell'Implementazione è dichiarato.

Risorse Software

Per sviluppare il modulo si può richiedere di includere alcune risorse software. Risorse Software sono componenti Openbravo ERP non espresse come metadata come definizioni xml di oggetti di schema di database, classi java , librerie jar, files XML, etc. Tutto ciò che è necessario aggiungere al modulo deve essere impacchettato nella cartella del tipo openbravoMainFolder/modules/yourModuleJavaName (eg. per il modulo org.openbravo.examples.helloworld il packaging è /home/user/src/openbravo/modules/org.openbravo.examples.helloworld in ambiente linux o c:\openbravo\modules\org.openbravo.examples.helloworld in ambiente windows). In questa cartella ci sono le cartelle standard di openbravo per gestire le risorse software (src, src-db, lib, etc). Vedere l'immagine Packaging e files .obx per dettagli.

Il processo di build di Openbravo è stato modificato per tenere in conto la nuova struttura del codice sorgente che ora è divisa in moduli. Questo concetto è completamente differente dal srcClient che Openbravo usave in precedenti releases: non è permesso sovrascrivere fisicamente un file nella distribuzione Openbravo core. Il packaging delle risorse software dovrebbe essere messo in com.yourCompany.xxx o org.yourCompany.xxx cosi non si userà org.openbravo.xxx per impacchettare il proprio codice altre volte.

Come per i componenti AD, benchè questa regola generale per packaging viene applicata a tutte le risorse software ci sono alcuni dettagli per ogni tipo di risorsa software (Oggetti di schema di Database, classi java, librerie jar , contenuto web statico , etc.) di cui si ha necessità quando si sviluppa un modulo.

Oggetti dello schema di Database

Il tipico flusso di aggiungere un nuovo oggetto di schema di database (tabella, colonna, constraint, indice, trigger, view, stored procedure, funzione) o modificarlo in Openbravo ERP è il seguente :

uno sviluppatore usa il suo tool preferito come database client per sviluppare in Oracle o PostgreSql
usando scripts sql o tools GUI crea o modifica l'oggetto dello schema di database nel database seguendo gli standards Openbravo ( guardare Manuale dello sviluppatore di Openbravo per i dettagli).
Se l'oggetto dello schema di database è mappato con un Application dictionary (Tabelle&Colonne, Reports&Processi) allora lo sviluppatore importa il nuovo oggetto dal database nell'Application Dictionary. Questo processo aggiunge alcune nuove linee nelle tabelle AD. Dopo che lo sviluppatore di solito corregge le informazionie importate -eg. eseguendo il processo synchronize terminology - e completa informazione AD per descrivere pienamente la soluzione che si è proposto. Può anche richiedere di creare codice Openbravo (files java , files xsql, etc.) per completare la soluzione
Una volta che la soluzione è pienamente descritta lo sviluppatore builda il sistema per testare che funziona come desiderato
L'ultimo processo è di esportare the database to xml files through DBSourceManager. Questo tool esporta ogni oggetto di schema di database in un file xml che usa una sintassi comune sia per Oracle che PostgreSql così si può avere diversi ambienti di sviluppo che impegnano la stessa linea di codice . Application Dictionary data è anche esportata in questo processo. Così ci sono diversi tipi di file xml esportati da DBSourceManager: modello (oggetti di schema di db) e sourcedata (Application Dictionary metadata).

Da una prospettiva di modularità non c'è alcun bisogno di fare attività addizionali per occuparsi dei metadata dell'Application Dictionary poichè è gestito dal system come descritto nella precedente sezione Componenti Application Dictionary . Per evitare conflitti di nomi nel database e permettere DBSourceManager di conoscere il modulo di oggetti di schema non mappati, è richiesto di seguire la seguente regola di naming per oggetti schema di database :

Tutti gli oggetti principale (tabelle, triggers, views, funzioni, stored procedures) devono iniziare col db_prefix del modulo seguito dal simbolo underscore ("_") (eg. MYMOD_MYTABLE, MYMOD_MYPROCEDURE, etc.).
Sottoparti degli oggetti principali (colonne , constraints, indici) si suppongono appartenere al modulo della parte principale eccetto se il loro nome inizia con "EM_" + db_prefix + "_" (eg. EM_MYMOD_MYCOLUMN, EM_MYMOD_MYCONSTRAINT, etc.). EM sta per External Module. Si può usare nomi di colonna standard nelle tue tabelle (eg. C_BPARTNER_ID, M_PRODUCT_ID, NAME, etc.) ma se si vuole aggiungere nel modulo una "parte" (colonna, constraint, indice) a una tabella in un altro modulo bisogna usare il prefisso "EM_" + db_prefix + "_" per il nome di quella parte.

Seguendo questa semplice regola si può includere nel modulo tanti oggetti di schema database quanti si vuole. Ma bisogna sapere che non si può modificare oggetti di schema di database in altri moduli come se si volesse spezzare la regola principale : "un modulo non può modificare componenti in altri moduli".

Quando DBSourceManager esporta il database terrà in conto solo i moduli "in sviluppo", gli altri non verranno esportati. I file xml esportati si troveranno entro la cartella src-db/database nella cartella del modulo . Vedere packaging per vedere un esempio.

Alla fine ci sono alcuni esempi spiegati che mostrano come includere nel modulo ogni tipo di oggetto di schema di database. Si può usarli come riferimentoper sviluppare un modulo.

Classi Java, altre cose di Openbravo MVC librerie jar

Classi Java , altre cose Openbravo MVC (files html, xml e xsql) e librerie jar seguono la regola generale di aggiungere risorse software nel modulo. Bisogna fare il package di questo codice nella cartella src che si trova nella cartella del modulo. Quando Openbravo ERP builda il sistema aggiunge dinamicamente al suo progetto java tutte le cartelle src entro tutti i moduli installati come risorse java del progetto. Usa una locazione intermedia, cartella di build, di generare codice dai files xsql e compilare tutte le risorse java e metterli insieme . Si può includere nel modulo librerie jar fatte da se o da terze parti e usarli nel codice . Tutte le librerie jar incluse nella cartella lib sono aggiunte al classpath a compilation time e infine deployate nel contesto openbravo.

Dopo la generazione di codice e il processo di compilazione il processo di build deploya tutto il contenuto nel contesto di openbravo nel container della servlet . Ci sono due modi di deployare -classi e war- che sono spiegate più tardi nella sezione Concetti Avanzati.

Contenuto Web Statico (files css, immagini, javaScript)

Se c'è bisogno di aggiungere alcuni contenuti statici (css, immagini e javaScript) al modulo bisogna mettere queste risorse nella cartella web del modulo , entro una cartella chiamata come il package java del modulo per evitare conflitti di files quando si deployano risorse da diversi moduli.

Quando il system è buildato tutti i files nella cartella web del modulo sono copiati in WebContent e da lì viene deployato nel contesto openbravo in modo standard così queste risorse possono essere accedute dalle pagine nel modulo referenziandole. Tenere in conto che xmlEngine esegue una traduzione automatice di urls attraverso una sostituzione di "../../../../../web" (parametro replaceWhat) da "@actual_url_context@/web" (parametro replacWith), essendo "@actual_url_context@" il path assoluto nel contesto openbravo (eg. http://localhost:8880/openbravo).

Il modulo Solitaire è disegnato per dimostrare come includere contenuto web statico nel modulo. Attraverso questo esempio è semplice capire come funziona. Per esempio, questo è uno di Solitaire.html con riferimento al file solitaire.js che si trova nella cartella web/org.openbravo.examples.solitaire del modulo Solitaire :

<script language="JavaScript" src="../../../../../web/org.openbravo.examples.solitaire/solitaire.js" type="text/javascript"></script>

A execution time, una volta che il contesto openbravo è deployato e caricato si può avere la libreria javascript solitaire.js da @actual_url_context@/web/org.openbravo.examples.solitaire/solitaire.js. Quando la pagina principale del modulo Solitaire è rilasciata , xmlEngine sostituisce "../../../../../web" con "@actual_url_context@/web" e cosi referenzia propriamente alla risorsa disponibile.

Certo si può anche far riferimento a altre risorse web statiche incluse nel core o altri moduli. In quel caso bisogna dichiarare esplicitamente dichiara la dipendenza di quel modulo.

Files Config

Può anche essere necessario includere alcuni files di configurazione nella cartella config del modulo. Questi files saranno copiati in WebContent/WEB-INF quando il sistema è costruito e deployato nel contesto di openbravo.

Per esempio , nel modulo HelloWorldService c'è un file org.openbravo.examples.webservice-provider-config.xml entro la cartella config. Questo file è copiato nel contesto openbravo e da questo la classe che implementa la Webservice è dichiarata.

Per evitare conflitti di files deployati da diversi file di moduli entro la cartella config dovrebbe essere prefissato con il PackageName del modulo.

Dati Riferimento

La Modularità supporta i Dati di Riferimento: informazione di business riferite dalle transazioni e che tende a non cambiare frequentemente come Carrelli dei conti, codici tasse, banche, categorie prodotto, etc. Possono essere definite a livello di system, client o organizzazione. Ci sono tre tipi di dati riferimento supportati: Traduzioni , Carrello dei Conti e Dati Riferimento standard.

Traduzioni

Carrello dei conti (CoA)

Dati Riferimento Standard

Script di Configurazione

Tasks di sviluppo

Tutti i tasks di sviluppo sono stati riorganizzati in Openbravo 2.50 e i moduli sono propriamente gestiti cosi da poter modificare il database o compilare il sistema tenendo conto solo dei cambiamenti in un dato modulo. Leggere questo documento per ottenere una completa spiegazione di tutti i tasks di sviluppo disponibili.

Pubblicare il file .obx di un Modulo

Creare il file .obx del Modulo e pubblicarlo.

Concetti Avanzati

Questa sezione spiega in dettaglio alcuni concetti avanzati della Modularità in Openbravo . Non è strettamente necessario leggere tutti i dettagli ma sarebbe meglio farlo , aiuterà a evitare errori quando si creano moduli.

UUID's

Come identificare le dipendenze del modulo

Numeri di Versione e come dipendenze e inclusioni sono gestite

Traduzione On-line

Modello - Concetto di Implementazione

AD_Model_Object è una tabella nell'Application Dictionary per collegare i componenti dell'Application Dictionary e la classe (servlet) che implementa quell'oggetto. Così questa tabella è una mappatura fra il lato logico (componenti AD) e il lato fisico (classi). E' utile per due ragioni principali:

Permette di implementare in un modo generico regole che si applicano a tutti i componenti AD come sicurezza, navigazione e altri.
E' il meccanismo per popolare automaticamente il file web.xml dove le classi (servlets) sono dichiarate. AD_Model_Object_Mapping è una utility per creare le entrate di mappatura nel file web.xml.

Ci sono poche eccezioni a questa descrizione: alcune servlets che sono deployate nel contesto Openbravo ma non sono collegate a un componente AD, come il DataGrid o le servlets AuditInfo. Queste sono richiamate da componenti manuali o standard (windows, forms, etc.) attraverso http requests con hardcoding il suo url-mapping nella request. Può essere interpretato ancora come una mappatura di classi effettive che implementano una funzionalità che non è descritta nel modello corrente di Openbravo, anche se può essere in futuro.

Il Progetto Modularità mira a permettere attraverso moduli il deployment di ogni tipo di contenuto opzionale in una instanza Openbravo, incluse entrate addizionali nel file web.xml del contesto openbravo. Viene fatto attraverso la tabella AD_Model_Object. Gli sviluppatori possono creare entrate in questa finestra non collegate a un componente AD. Per supportare un tipo di contenuto web.xml (servlet, listeners, filters, etc.) una nuova colonna è aggiunta a AD_Model_Object per rappresentare il tipo entrata web.xml che lo sviluppatore aggiunge . Possono anche dichiarare un set di mappature per l'entrata e un set di parametri se necessario.

Il modulo di un'entrata AD_Model_Object è calcolato con la seguente regola : se è collegata a un componente AD allora il modulo è quello assegnato a quel componente AD, altrimenti il modulo è quello assegnato al record stesso del AD_Model_Object .

Con questa estensione il file web.xml nel contesto openbravo sarà pienamente estensibile attraverso i moduli.

Modi di deployment: class and war

Master data e Sample data

Tool di Export/Import

Un esempio 'Hello World'

Retrieved from "http://wiki.openbravo.com/wiki/Projects:Modularity/Developers_Guide/it"

This page has been accessed 10,302 times. This page was last modified on 8 June 2012, at 05:28. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.

Categories: WorkInProgress | Templates | Italian