2021-03-16T09:07:51Z

Mwadmin: Created page with "Quando si crea una fattura di acquisto si può andare in picking dal browser "Selezione ricevimenti" (oggetto PT1) Il browser "Selezione ricevimenti" è gestito dai sorgente..."

File:FILGAUSUP.jpg

2021-03-16T09:06:15Z

Mwadmin:

Filtro righe ricevimenti in picking fattura acquisto

File:PTH Situazione riga.gif

2021-03-16T08:51:05Z

Mwadmin:

Situazione riga di un ricevimento

GESAFC

2021-03-01T21:28:01Z

Mwadmin: /* Dizionario funzioni */

== Dizionario funzioni ==

=== Opzioni ===

Nel riquadro Opzioni è possibile specificare uno o più codici opzione.
Questi codici poi saranno utilizzabili nella parametrizzazione delle [[GESFAP|abilitazioni]] dei profili funzione.

Esempio presente a standard è la funzione GESITM,che presenta due opzioni, Listino e Costo:

[[File:SD_Opzioni_funzione_GESITM.png]]

Qui vedi dove usarle:

[[File:SD_Opzioni_funzione_GESITM_abil_funz.png]]

Se è attiva l'autorizzaione per sito come in GESITF:

[[File:SD_Funzione_Aut_Sito_GESITF.png]]

l'opzione si può dare sito per sito.

[[File:SD_Opzioni_funzione_HELP.png]]

In pratica il sistema carica queste variabili globali:
GNBAUZ numero di siti presenti
GUSRFCY(1..GNBAUZ) nomi dei siti
GUSRAUZ(i) opzioni attive sull'i-esimo sito

Aggiungiamo per esempio un'opzione 'm' ad una funzione.
AAA: inserire il codice attività se la funzione è standard!
AAA: usare una lettera minuscola, come specificato nell'Help.

Supponiamo di voler attivare/disattivare un bottone, pertanto ci posizioniamo nella SETBOUT.
Nel sorgente specifico, il cosiddetto SPE, dovrai inserire un pezzo di codice simile:

<pre>
$SETBOUT
#nel campo [M]FCY ci sia il sito dell'oggetto corrente
#recupero l'indice del sito relativo all'oggetto corrente:
ISITE = find([M]STOFCY,GUSRFCY(1..GNBAUZ))
If ISITE
#recupero autorizzazioni per quel sito:
AUZ = GUSRAUZ(ISITE)
#verifico l'autorizzazione
If instr(1,AUZ,'m')=0
# quello che vuoi:
# Call VIREBOUT(CHAINE,...) From GOBJET
Endif
Endif
Return
</pre>

Se non è attiva l'autorizzazione per sito allora tutti i siti hanno le stesse opzioni,
basta quindi fare la verifica su GUSRFCY(1).

[[File:SD_Var_global_GUSRFCY.png]]
[[File:SD_Opzioni_funzione_GUSRAUZ_calc.png]]

File:SD Var global GUSRFCY.png

2021-03-01T20:52:04Z

Mwadmin: Definizione Variabile globale GUSRFCY

== Summary ==
Definizione Variabile globale GUSRFCY

File:SD Funzione Aut Sito GESITF.png

2021-03-01T20:51:31Z

Mwadmin: Opzioni funzione [GESAFC] con autorizzaione per sito: esempio di GESITF (Articolo sito)

== Summary ==
Opzioni funzione [GESAFC] con autorizzaione per sito: esempio di GESITF (Articolo sito)

File:SD Opzioni funzione GESITM.png

2021-03-01T20:50:55Z

Mwadmin: Opzioni funzione [GESAFC]: esempio di GESITM

== Summary ==
Opzioni funzione [GESAFC]: esempio di GESITM

File:SD Opzioni funzione GUSRAUZ calc.png

2021-03-01T20:50:35Z

Mwadmin: Opzioni funzione [GESAFC], variabile globale GUSRAUZ, esempio con calcolatrice

== Summary ==
Opzioni funzione [GESAFC], variabile globale GUSRAUZ, esempio con calcolatrice

File:SD Opzioni funzione HELP.png

2021-03-01T20:50:01Z

Mwadmin: Opzioni funzione [GESAFC] l'help in linea

== Summary ==
Opzioni funzione [GESAFC] l'help in linea

File:SD Opzioni funzione GESITM abil funz.png

2021-03-01T20:49:35Z

Mwadmin: Opzioni funzione [GESAFC] usate nelle abilitazioni funzionali : esempio di GESITM

== Summary ==
Opzioni funzione [GESAFC] usate nelle abilitazioni funzionali : esempio di GESITM

Regole sviluppo

2021-02-19T16:38:03Z

Mwadmin:

[[File:Help modello oggetto.png|Help modello oggetto.png]]

[[File:Help modello oggetto 2.png|Help modello oggetto 2.png]]

[[File:Help modello oggetto 3.png|Help modello oggetto 3.png]]

[[File:Help regole sviluppo .png||]]

ATTENZIONE: testo copiato dall'HELP di Sage X3 per comodità

Quando si devono realizzare degli sviluppi specifici, bisogna organizzarsi affinchè questi siano più perenni possibili a fronte dei cambi di versione. La prima parte di questo documento dettaglia i modi di agire.

Indipendentemente da questo primo punto, è possibile che ci si ponga una domanda di organizzazione tecnica dei dossier in cui gli sviluppi vengono fatti. Questo quesito viene affrontato nella seconda parte della documentazione.

== Protezione delle modifiche fatte ==

Il software permette di inglobare degli sviluppi specifici all'interno dello standard, principalmente modificando ad un livello di dettaglio alcuni elementi dello standard per rispondere ad esigenze che lo standard non copre.

Per facilitare la manutenzione di questi specifici perennizzandoli finc quando è possibile, vanno rispettate un certo numero di regole. Queste regole sono 5 e sono riportate qui sotto. Il loro rispetto permetterà di limitare al massimo i problemi in caso di patch o di aggiornamento.

Ma prima di cominciare, occorre sapere che esistono dei limiti insuperabili. A prescindere dalla sofisticazione del sistema dei codici attività, vi sono degli sviluppi che è meglio realizzare riscrivendoli invece che con modifica di un oggetto standard. Così, se una videata è stata modificata così pesantemente (in particolare se i blocchi sono stati modificati) che diventa difficile da mantenere per differenza con la videata standard, è forse meglio crearne una nuova. Lo stesso se una funzione standard è modificata in modo radicale, è forse meglio riscrivere una funzione specifica, basandosi su sotto-programmi standard documentati da ADONIX.

Si tratta di un elemento da considerare prima di ogni sviluppo specifico: è meglio riscrivere o modificare gli elementi forniti dallo standard?

Una volta somposta questa domanda caso per caso, le regole di perennizzazione sono le seguenti:

=== Regola numero 1: Non modificare mai un sorgente standard ===

Il non rispetto di questa regola è il modo migliore per ottenere un dossier impossibile da mantenere.

Infatti, il fatto che un sorgente standard sia consegnato non significa che questo sorgente debba essere modificato. I sorgenti standard consegnati sono per fini di consultazione.

Questo limite non è pertanto un limite che crea disturbo. Infatti, nella maggior parte dei casi, si chiama un programma specifico dedicato, quando questo esiste. E' generalmente il caso:

* in gestione oggetto, a lato del programma SUBXXX, dove XXX è il codice dell'oggetto, esiste un programma SPEXXX per gestire lo specifico.

* in consultazione, a lato del programma standard (chiamato in generale CNSXXXSTD, dove XXX è il codice della consultazione), è possibile indicare il nome di un programma specifico (in generale CNSXXXSPE).

* nel dizionario delle azioni, se l’azione è di tipo Programma standard e il nome del programma comincia per SUB, si può anche utilizzare il programma equivalente che comincia per SPE; se il nome del programma (TRAITE per esempio) non comincia per SUB, il programma specifico associato si chiama XYTRAITE e permette quindi di realizzare degli specifici senza toccare il codice di origine.

* nel dizionario delle azioni, se l’azione è di tipo Inserimento finestra, la finestra principale si chiama per esempio FENETRE, un programma specifico, di nome XWFENETRE, permette di realizzare degli specifici senza toccare il codice di origine.

Inoltre se, per intervenire, uno specifico ha bisogno della modifica di un programma standard, l'unica maniera ammissibile per risolvere i problemi di perennizzazione consiste nel richiedere un entry point ad ADONIX.
=== Regola numero 2: utilizzare strettamente le regole per battezzare tutti gli elementi aggiunti ===

Per evitare eventuali collisioni con versioni future del software, è obbligatorio chiamare gli elementi aggiunti con nomi che cominciano con X, Y o Z. Per elemento si intende tutto ciò che si trova nel seguente riquadro:

{| class="wikitable"
|+ Caption text
|-
! Funzione di definizione !! Descrizione
|-
| GESATY|| Tipi di dati
|-
| GESATB||Tabelle
|-
| GESACV||Codici attività
|-
| GESAMK||Videate
|-
| GESAWI (*)||Finestre
|-
| GESAOB||Oggetti
|-
| GESACN||Consultazioni
|-
| GESACT||Azioni
|-
| ADOTRT||Programmi
|-
| GESARP||Stampe
|}

(*) Fatta eccezione per le finestre che cominciano per O, che sono associate ad un oggetto il cui nome comincia con X, Y o Z.

Per alcuni elementi esistono delle regole per dare un nome. Infatti:

* vanno per forza aggiunti dei parametri specifici in capitoli dedicati, il cui codice deve cominciare per X, Y, o Z.

* vanno per forza aggiunti dei messaggi specifici nei capitoli il cui numero è compreso tra 160 e 169.

* i menù locali specifici e le tabelle diverse specifiche devono utilizzare le porzioni di numerazione comprese tra 1000 e 1999.

Infine, il nome dei campi aggiunti in tabelle o videate standard devono cominciare con X_, Y_, o Z_.
=== Regola numero 3: proteggere con un codice attività, ma al livello più di dettaglio possibile ===

Il rispetto delle regole per dare un nome non basta a perennizzare degli elementi. Occorre anche proteggerli con un codice attività che cominci con X, Y o Z. Ma si consiglia di proteggere solo le modifiche fatte a livello di dettaglio più sottile, per beneficiare al massimo delle evoluzioni apportate sugli altri elementi di un elemento del software. Così è possibile proteggere:

* Una videata intera o una tabella intera. In questo caso, ogni modifica apportata sulla videata o sulla tabella da una patch verrà ignorata. Questo tipo di protezione viene consigliato solo per le nuove videate o tabelle o in caso di modifica totale di una videata o di una tabella. Diventa allora inutile mettere un codice attività specifico ai livelli sottostanti, salvo si desideri servirsi di un codice attività per disporre di varianti nella videata o nella tabella.

* Il blocco di una videata. In caso di patch non viene modificato nessuno dei campi del blocco. Anche qui si tratta di un livello abbastanza alto di protezione, poiché tutti i campi del blocco non vengono più modificati in caso di patch. Bisogna quindi proteggere in modo più sottile quando ciò è possibile. Resta il fatto che si tratta dell'unico livello accettabile se si modifica il posizionamento di un blocco standard, o se si cerca di rendere configurabile alla gestione di dossier il numero di righe di un riquadro che altrimenti sarebbe fisso.

* Il campo di una videata o il campo di una tabella o l'indice di una tabella. E' il livello da utilizzare nel caso in cui si modifichino le caratteristiche di un campo (formato, tipo, descrizione, lunghezza...). Questo livello di protezione è molto sottile, sapendo che il solo conflitto potenziale in caso di patch verte sui campi protetti.

* Una tabella collegata, un folder, una lista di selezione in un oggetto (è preferibile ad una protezione globale dell'oggetto).

* Un'opzione, una variabile associata ad una funzione (è preferibile ad una protezione globale della funzione).

Alcuni elementi non possono essere protetti in modo dettagliato (è il caso delle stampe). In questo caso, l'unica soluzione è quella di proteggere globalmente la stampa, installando il file con estensione rpt a livello del dossier di produzione, sapendo che sarà anche possibile decidere di rinominarlo.

C'è tutta una serie di casi in cui i codici attività non sono utili, soprattutto sui campi delle videate:

* Se si vuole aggiungere un controllo supplementare su un campo e se questo controllo può essere definito da una tabella di controllo, è meglio implementarlo così: si tratta infatti di una parametrizzazione che non ha bisogno di essere protetta.

* Lo stesso se si vuole limitare l'accesso al campo in funzione di un utente: le assegnazioni di codici di accesso consistono parametrizzazione.

* Lo stesso se si vuole cambiare interamente gli attributi del tipo di dati associato al campo, è meglio modificare il tipo di dati e proteggerlo da un codice attività: la protezione del campo è allora inutile.

* Se si vogliono aggiungere delle azioni dette « specifiche » (chiamate SPE o SPX), occorre sapere che queste azioni rimangano invariate in caso di patch, anche se il campo non è protetto. Quindi non è utile aggiungere un codice attività sul campo se non sono state fatte altre modifiche. Se delle azioni specifiche impongono di aprire una finestra, queste azioni devono essere catalogate nel dizionario delle azioni. D'altronde, non appena il codice dell'azione comincia per X, Y o Z, questa è protetta allo stesso modo senza che sia necessario proteggere il campo. In compenso è necessario proteggere l'azione con un codice attività (sarà richiamata solo se il codice è Attivo).

* Se si vuole cancellare un'azione standard su un campo, è più semplice completarla con un'azione chiamata SPX invece che cancellarla (così, la protezione tramite codice attività non sarà necessaria sul campo).
=== Regola numero 4: Attenzione agli inserimenti su dei sotto elementi esistenti ===

Gli inserimenti di sotto elementi in un elemento non permettono, in alcuni casi, la perennizzazione. Questo riguarda i seguenti casi:

* aggiungere un indice in una tabella standard deve essere fatto alla fine dell'elenco degli indici e soprattutto non all'inizio di tale elenco (il primo indice è l'indice di default). In compenso non vi sono vincoli sui campi. Si consiglia comunque di non chiamarli in modo consecutivo nel formato ABBRn, dove ABBR è l'abbreviazione della tabella e n il numero di riga (infatti è possibile che un'evoluzione dello standard necessiti dell'aggiunta di un indice standard).

* i blocchi di una videata sono conosciuti solo tramite il loro numero. Così, se si desidera aggiungere un blocco in una videata, occorre sempre metterlo alla fine (giocare sulle posizioni di inserimento). Nemmeno qui vi sono vincoli sui campi.

* lo stesso vale per i folder di una tabella, le liste di selezione di un oggetto (in versione 140 si differenzia l'ordine del loro ordine di apparizione, poiché esiste una campo rank).
=== Regola numero 5: Prima dell'installazione di ogni patch o di ogni versione, utilizzare il tester di patch ===

Questo strumento è stato realizzato per permettere di evidenziare i potenziali conflitti al momento dell'installazione di patch. Infatti, legge la testata dei file di patch presenti in una data directory e visualizza in una traccia l'elenco degli elementi presenti in questa lista e che sono oggetto di specifici. Se l'elenco in questione è vuoto, non vi è rischio di conflitti. Al contrario, l'elenco degli elementi in conflitto è generalmente scarso e basta allora esaminare in dettaglio i pochi elementi che vi si trovano.

Quando si installa una versione tramite un CD, (in una directory dipendente dal software, sulla versione 130 di ADONIX X3 ad esempio, si trovano nella directory X3Patch\X3V130_technical) vi sono una serie di cartelle chiamate in funzione delle versioni intermedie del software (P131, P132, P133…), che contengono dei file chiamati List_nnn.dat. Questi file contengono solo la testata degli elementi contenuti nelle patch consecutive che permettono di passare da una versione all'altra. E' quindi possibile utilizzare questi file nello stesso modo con il tester di patch, per assicurarsi dei potenziali conflitti (si partirà dalla lista seguendo la lista corrente installata sul dossier da aggiornare).
== Organizzazione dei dossier in due o tre livelli ==

Al momento dell'esecuzione del software, il motore adonix carica ed esegue dei file che contengono un codice intermedio (il p-code) indipendente dall'ambiente. Questi file possono essere dei programmi, delle descrizioni di videate, la descrizione delle tabelle (per fare una consultazione sulla tabella in questione). Questi file vengono cercati nel dossier in corso di esecuzione. Ma se un file non esisten nel dossier, il motore adonix lo cercherà nel dossier padre di primo livello, poi nel dossier di secondo livello... Il motore adonix può così risalire una gerarchia di 8 dossier successivi, ma per ragioni pratiche, ci si limita a 3 livelli (la gestione di dossier ne gestisce solo 3).

La conseguenza di questa struttura è la seguente: un dossier utente creato nel software dipenderà sia dal dossier supervisore, sia da un dossier che dipende esso stesso dal dossier supervisore. Infatti, se ciò non avvenisse, non sarebbero più accessibili gli elementi indispensabili al funzionamento del dossier e della sua parametrizzazione, che sono presenti solo nel dossier supervisore. I due schemi possibili per un dossier di produzione sono i seguenti:

Il dossier di riferimento intermedio è in generale chiamato dossier di sviluppo, perché una delle possibili implementazioni delle gerarchie di dossier consiste nell'installarvi gli sviluppi specifici.

La gerarchia a 3 livelli è pesante da mantenere. Infatti, l'esistenza di questa gerarchia a tre livelli ha delle conseguenze pratiche: trasferire un dossier di produzione da un server ad un altro presuppone che, affinché il dossier trasferito possa funzionare, la gerarchia sia stata anch'essa trasferita. Nel caso di una gerarchia a due livelli, nessun problema, poiché il dossier supervisore è forzatamente presente in un ambiente in cui è installato il software. In compenso, nel caso di una gerarchia a 3 livelli, occorre anche trasferire il dossier di sviluppo.

Il principio di eredità, se permette di trasferire semplicemente degli sviluppi fatti tramite rivalidazione del dossier di produzione, presenta comunque degli effetti particolari, nella misura in cui l'eredità è immediata se si modifica un programma nel dossier di sviluppo... ma differita per tutti gli elementi del dizionario, che saranno trasferiti solo in caso di rivalidazione. Quindi si rischia di ritrovarsi con delle incoerenze temporanee nel dossier di produzione, dato che si lavora in un dossier di sviluppo.

Questa gerarchia è quindi consigliata solo nei seguenti casi:

* il cliente finale vuole sviluppare i propri specifici e si desidera che lo faccia in modo ben isolato nel dossier di produzione; sapendo che si vogliono degli sviluppi fatti da un partner ADONIX nel dossier intermedio.

* ci si trova in un ambiente di sviluppo di verticali e si desiderano utilizzare dei dossier di produzione a dei fini di test.

In tutti gli altri casi, si consiglia di utilizzare una gerarchia a due livelli. In questo caso, occorre utilizzare un dossier di test a fianco del dossier di produzione, se si desiderano realizzare degli sviluppi in corso di gestione e testarli prima di installarli (tramite copia o patch) nel dossier di produzione. L'utilizzo della funzione di patch è spesso preferibile: infatti permette di creare dei « packages » applicativi dal dossier di sviluppo e di integrarli in blocco nel dossier di produzione. Inoltre, la versione 130 integra una nuova funzione di creazione di una patch incrementale. Infatti è possibile creare una patch che contiene tutto ciò che è stato modificato su un dossier da una determinata data. Questo permette molto facilmente di isolare gli sviluppi e le parametrizzazioni realizzate tra due fasi di un'implementazione.

Regole sviluppo

2021-02-19T16:36:43Z

Mwadmin: Created page with "File:Help modello oggetto.png| File:Help modello oggetto 2.png| File:Help modello oggetto 3.png| | Quando si devono realiz..."

[[File:Help modello oggetto.png|Help modello oggetto.png]]

[[File:Help modello oggetto 2.png|Help modello oggetto 2.png]]

[[File:Help modello oggetto 3.png|Help modello oggetto 3.png]]

[[File:Help regole sviluppo .png||]]

Quando si devono realizzare degli sviluppi specifici, bisogna organizzarsi affinchè questi siano più perenni possibili a fronte dei cambi di versione. La prima parte di questo documento dettaglia i modi di agire.

Indipendentemente da questo primo punto, è possibile che ci si ponga una domanda di organizzazione tecnica dei dossier in cui gli sviluppi vengono fatti. Questo quesito viene affrontato nella seconda parte della documentazione.

== Protezione delle modifiche fatte ==

Il software permette di inglobare degli sviluppi specifici all'interno dello standard, principalmente modificando ad un livello di dettaglio alcuni elementi dello standard per rispondere ad esigenze che lo standard non copre.

Per facilitare la manutenzione di questi specifici perennizzandoli finc quando è possibile, vanno rispettate un certo numero di regole. Queste regole sono 5 e sono riportate qui sotto. Il loro rispetto permetterà di limitare al massimo i problemi in caso di patch o di aggiornamento.

Ma prima di cominciare, occorre sapere che esistono dei limiti insuperabili. A prescindere dalla sofisticazione del sistema dei codici attività, vi sono degli sviluppi che è meglio realizzare riscrivendoli invece che con modifica di un oggetto standard. Così, se una videata è stata modificata così pesantemente (in particolare se i blocchi sono stati modificati) che diventa difficile da mantenere per differenza con la videata standard, è forse meglio crearne una nuova. Lo stesso se una funzione standard è modificata in modo radicale, è forse meglio riscrivere una funzione specifica, basandosi su sotto-programmi standard documentati da ADONIX.

Si tratta di un elemento da considerare prima di ogni sviluppo specifico: è meglio riscrivere o modificare gli elementi forniti dallo standard?

Una volta somposta questa domanda caso per caso, le regole di perennizzazione sono le seguenti:

=== Regola numero 1: Non modificare mai un sorgente standard ===

Il non rispetto di questa regola è il modo migliore per ottenere un dossier impossibile da mantenere.

Infatti, il fatto che un sorgente standard sia consegnato non significa che questo sorgente debba essere modificato. I sorgenti standard consegnati sono per fini di consultazione.

Questo limite non è pertanto un limite che crea disturbo. Infatti, nella maggior parte dei casi, si chiama un programma specifico dedicato, quando questo esiste. E' generalmente il caso:

* in gestione oggetto, a lato del programma SUBXXX, dove XXX è il codice dell'oggetto, esiste un programma SPEXXX per gestire lo specifico.

* in consultazione, a lato del programma standard (chiamato in generale CNSXXXSTD, dove XXX è il codice della consultazione), è possibile indicare il nome di un programma specifico (in generale CNSXXXSPE).

* nel dizionario delle azioni, se l’azione è di tipo Programma standard e il nome del programma comincia per SUB, si può anche utilizzare il programma equivalente che comincia per SPE; se il nome del programma (TRAITE per esempio) non comincia per SUB, il programma specifico associato si chiama XYTRAITE e permette quindi di realizzare degli specifici senza toccare il codice di origine.

* nel dizionario delle azioni, se l’azione è di tipo Inserimento finestra, la finestra principale si chiama per esempio FENETRE, un programma specifico, di nome XWFENETRE, permette di realizzare degli specifici senza toccare il codice di origine.

Inoltre se, per intervenire, uno specifico ha bisogno della modifica di un programma standard, l'unica maniera ammissibile per risolvere i problemi di perennizzazione consiste nel richiedere un entry point ad ADONIX.
=== Regola numero 2: utilizzare strettamente le regole per battezzare tutti gli elementi aggiunti ===

Per evitare eventuali collisioni con versioni future del software, è obbligatorio chiamare gli elementi aggiunti con nomi che cominciano con X, Y o Z. Per elemento si intende tutto ciò che si trova nel seguente riquadro:

{| class="wikitable"
|+ Caption text
|-
! Funzione di definizione !! Descrizione
|-
| GESATY|| Tipi di dati
|-
| GESATB||Tabelle
|-
| GESACV||Codici attività
|-
| GESAMK||Videate
|-
| GESAWI (*)||Finestre
|-
| GESAOB||Oggetti
|-
| GESACN||Consultazioni
|-
| GESACT||Azioni
|-
| ADOTRT||Programmi
|-
| GESARP||Stampe
|}

(*) Fatta eccezione per le finestre che cominciano per O, che sono associate ad un oggetto il cui nome comincia con X, Y o Z.

Per alcuni elementi esistono delle regole per dare un nome. Infatti:

* vanno per forza aggiunti dei parametri specifici in capitoli dedicati, il cui codice deve cominciare per X, Y, o Z.

* vanno per forza aggiunti dei messaggi specifici nei capitoli il cui numero è compreso tra 160 e 169.

* i menù locali specifici e le tabelle diverse specifiche devono utilizzare le porzioni di numerazione comprese tra 1000 e 1999.

Infine, il nome dei campi aggiunti in tabelle o videate standard devono cominciare con X_, Y_, o Z_.
=== Regola numero 3: proteggere con un codice attività, ma al livello più di dettaglio possibile ===

Il rispetto delle regole per dare un nome non basta a perennizzare degli elementi. Occorre anche proteggerli con un codice attività che cominci con X, Y o Z. Ma si consiglia di proteggere solo le modifiche fatte a livello di dettaglio più sottile, per beneficiare al massimo delle evoluzioni apportate sugli altri elementi di un elemento del software. Così è possibile proteggere:

* Una videata intera o una tabella intera. In questo caso, ogni modifica apportata sulla videata o sulla tabella da una patch verrà ignorata. Questo tipo di protezione viene consigliato solo per le nuove videate o tabelle o in caso di modifica totale di una videata o di una tabella. Diventa allora inutile mettere un codice attività specifico ai livelli sottostanti, salvo si desideri servirsi di un codice attività per disporre di varianti nella videata o nella tabella.

* Il blocco di una videata. In caso di patch non viene modificato nessuno dei campi del blocco. Anche qui si tratta di un livello abbastanza alto di protezione, poiché tutti i campi del blocco non vengono più modificati in caso di patch. Bisogna quindi proteggere in modo più sottile quando ciò è possibile. Resta il fatto che si tratta dell'unico livello accettabile se si modifica il posizionamento di un blocco standard, o se si cerca di rendere configurabile alla gestione di dossier il numero di righe di un riquadro che altrimenti sarebbe fisso.

* Il campo di una videata o il campo di una tabella o l'indice di una tabella. E' il livello da utilizzare nel caso in cui si modifichino le caratteristiche di un campo (formato, tipo, descrizione, lunghezza...). Questo livello di protezione è molto sottile, sapendo che il solo conflitto potenziale in caso di patch verte sui campi protetti.

* Una tabella collegata, un folder, una lista di selezione in un oggetto (è preferibile ad una protezione globale dell'oggetto).

* Un'opzione, una variabile associata ad una funzione (è preferibile ad una protezione globale della funzione).

Alcuni elementi non possono essere protetti in modo dettagliato (è il caso delle stampe). In questo caso, l'unica soluzione è quella di proteggere globalmente la stampa, installando il file con estensione rpt a livello del dossier di produzione, sapendo che sarà anche possibile decidere di rinominarlo.

C'è tutta una serie di casi in cui i codici attività non sono utili, soprattutto sui campi delle videate:

* Se si vuole aggiungere un controllo supplementare su un campo e se questo controllo può essere definito da una tabella di controllo, è meglio implementarlo così: si tratta infatti di una parametrizzazione che non ha bisogno di essere protetta.

* Lo stesso se si vuole limitare l'accesso al campo in funzione di un utente: le assegnazioni di codici di accesso consistono parametrizzazione.

* Lo stesso se si vuole cambiare interamente gli attributi del tipo di dati associato al campo, è meglio modificare il tipo di dati e proteggerlo da un codice attività: la protezione del campo è allora inutile.

* Se si vogliono aggiungere delle azioni dette « specifiche » (chiamate SPE o SPX), occorre sapere che queste azioni rimangano invariate in caso di patch, anche se il campo non è protetto. Quindi non è utile aggiungere un codice attività sul campo se non sono state fatte altre modifiche. Se delle azioni specifiche impongono di aprire una finestra, queste azioni devono essere catalogate nel dizionario delle azioni. D'altronde, non appena il codice dell'azione comincia per X, Y o Z, questa è protetta allo stesso modo senza che sia necessario proteggere il campo. In compenso è necessario proteggere l'azione con un codice attività (sarà richiamata solo se il codice è Attivo).

* Se si vuole cancellare un'azione standard su un campo, è più semplice completarla con un'azione chiamata SPX invece che cancellarla (così, la protezione tramite codice attività non sarà necessaria sul campo).
=== Regola numero 4: Attenzione agli inserimenti su dei sotto elementi esistenti ===

Gli inserimenti di sotto elementi in un elemento non permettono, in alcuni casi, la perennizzazione. Questo riguarda i seguenti casi:

* aggiungere un indice in una tabella standard deve essere fatto alla fine dell'elenco degli indici e soprattutto non all'inizio di tale elenco (il primo indice è l'indice di default). In compenso non vi sono vincoli sui campi. Si consiglia comunque di non chiamarli in modo consecutivo nel formato ABBRn, dove ABBR è l'abbreviazione della tabella e n il numero di riga (infatti è possibile che un'evoluzione dello standard necessiti dell'aggiunta di un indice standard).

* i blocchi di una videata sono conosciuti solo tramite il loro numero. Così, se si desidera aggiungere un blocco in una videata, occorre sempre metterlo alla fine (giocare sulle posizioni di inserimento). Nemmeno qui vi sono vincoli sui campi.

* lo stesso vale per i folder di una tabella, le liste di selezione di un oggetto (in versione 140 si differenzia l'ordine del loro ordine di apparizione, poiché esiste una campo rank).
=== Regola numero 5: Prima dell'installazione di ogni patch o di ogni versione, utilizzare il tester di patch ===

Questo strumento è stato realizzato per permettere di evidenziare i potenziali conflitti al momento dell'installazione di patch. Infatti, legge la testata dei file di patch presenti in una data directory e visualizza in una traccia l'elenco degli elementi presenti in questa lista e che sono oggetto di specifici. Se l'elenco in questione è vuoto, non vi è rischio di conflitti. Al contrario, l'elenco degli elementi in conflitto è generalmente scarso e basta allora esaminare in dettaglio i pochi elementi che vi si trovano.

Quando si installa una versione tramite un CD, (in una directory dipendente dal software, sulla versione 130 di ADONIX X3 ad esempio, si trovano nella directory X3Patch\X3V130_technical) vi sono una serie di cartelle chiamate in funzione delle versioni intermedie del software (P131, P132, P133…), che contengono dei file chiamati List_nnn.dat. Questi file contengono solo la testata degli elementi contenuti nelle patch consecutive che permettono di passare da una versione all'altra. E' quindi possibile utilizzare questi file nello stesso modo con il tester di patch, per assicurarsi dei potenziali conflitti (si partirà dalla lista seguendo la lista corrente installata sul dossier da aggiornare).
== Organizzazione dei dossier in due o tre livelli ==

Al momento dell'esecuzione del software, il motore adonix carica ed esegue dei file che contengono un codice intermedio (il p-code) indipendente dall'ambiente. Questi file possono essere dei programmi, delle descrizioni di videate, la descrizione delle tabelle (per fare una consultazione sulla tabella in questione). Questi file vengono cercati nel dossier in corso di esecuzione. Ma se un file non esisten nel dossier, il motore adonix lo cercherà nel dossier padre di primo livello, poi nel dossier di secondo livello... Il motore adonix può così risalire una gerarchia di 8 dossier successivi, ma per ragioni pratiche, ci si limita a 3 livelli (la gestione di dossier ne gestisce solo 3).

La conseguenza di questa struttura è la seguente: un dossier utente creato nel software dipenderà sia dal dossier supervisore, sia da un dossier che dipende esso stesso dal dossier supervisore. Infatti, se ciò non avvenisse, non sarebbero più accessibili gli elementi indispensabili al funzionamento del dossier e della sua parametrizzazione, che sono presenti solo nel dossier supervisore. I due schemi possibili per un dossier di produzione sono i seguenti:

Il dossier di riferimento intermedio è in generale chiamato dossier di sviluppo, perché una delle possibili implementazioni delle gerarchie di dossier consiste nell'installarvi gli sviluppi specifici.

La gerarchia a 3 livelli è pesante da mantenere. Infatti, l'esistenza di questa gerarchia a tre livelli ha delle conseguenze pratiche: trasferire un dossier di produzione da un server ad un altro presuppone che, affinché il dossier trasferito possa funzionare, la gerarchia sia stata anch'essa trasferita. Nel caso di una gerarchia a due livelli, nessun problema, poiché il dossier supervisore è forzatamente presente in un ambiente in cui è installato il software. In compenso, nel caso di una gerarchia a 3 livelli, occorre anche trasferire il dossier di sviluppo.

Il principio di eredità, se permette di trasferire semplicemente degli sviluppi fatti tramite rivalidazione del dossier di produzione, presenta comunque degli effetti particolari, nella misura in cui l'eredità è immediata se si modifica un programma nel dossier di sviluppo... ma differita per tutti gli elementi del dizionario, che saranno trasferiti solo in caso di rivalidazione. Quindi si rischia di ritrovarsi con delle incoerenze temporanee nel dossier di produzione, dato che si lavora in un dossier di sviluppo.

Questa gerarchia è quindi consigliata solo nei seguenti casi:

* il cliente finale vuole sviluppare i propri specifici e si desidera che lo faccia in modo ben isolato nel dossier di produzione; sapendo che si vogliono degli sviluppi fatti da un partner ADONIX nel dossier intermedio.

* ci si trova in un ambiente di sviluppo di verticali e si desiderano utilizzare dei dossier di produzione a dei fini di test.

In tutti gli altri casi, si consiglia di utilizzare una gerarchia a due livelli. In questo caso, occorre utilizzare un dossier di test a fianco del dossier di produzione, se si desiderano realizzare degli sviluppi in corso di gestione e testarli prima di installarli (tramite copia o patch) nel dossier di produzione. L'utilizzo della funzione di patch è spesso preferibile: infatti permette di creare dei « packages » applicativi dal dossier di sviluppo e di integrarli in blocco nel dossier di produzione. Inoltre, la versione 130 integra una nuova funzione di creazione di una patch incrementale. Infatti è possibile creare una patch che contiene tutto ciò che è stato modificato su un dossier da una determinata data. Questo permette molto facilmente di isolare gli sviluppi e le parametrizzazioni realizzate tra due fasi di un'implementazione.