Creazione patch

Gestione videata

Videata di inserimento

Tipi di elementi che è possibile patchare

Questo riquadro permette di inserire un elenco d'oggetti da patchare. Questo elenco è identificato da un tipo di oggetto ed un nome. La definizione dei diversi tipi ed il significato del nome sono forniti qui di seguito. La colonna Range permette di conoscere l'ordine nel quale si presentano i tipi di elementi nella patch (vedere paragrafo qui in basso). Gli elementi che hanno il range 100 nel riquadro vengono sempre posizionati alla fine della patch (nell'ordine alfabetico dei codici degli elementi).

Osservazioni importanti

Trasferimento totale dei dati di una tabella

Il codice TAB permette di trasferire i dati della tabella, ricaricandola nel database con la sua struttura ed i suo dati. In compenso, non si creano gli elementi del dizionario che riguardano questa tabella, cosa che può non apparire come visibile. Questo codice è utile quando si desidera ricaricare una tabella già creata nei dossier da patchare e che non ha cambiato di struttura. Se non è questo il caso, bisogna mettere due righe nella definizione della patch: la prima riguarda la definizione della tabella (ATB XXXXX), la seconda il suo contenuto (TAB XXXXX). Anche se non si inseriscono in questo ordine, la funzione di patch le sistemerà in questo ordine. All'integrazione della patch, la tabella sarà creata nel dizionario e nel database se non esiste (altrimenti, la sua struttura sarà aggiornata se è cambiata). Poi avverrà il ricaricamento della tabella con i dati.

Trasferimento parziale dei dati di una tabella

La possibilità di trasferire il contenuto parziale di una tabella è ottenuta indicando nella colonna tipo l'abbreviazione della tabella ed indicando nella colonna Nome una condizione logica che sarà utilizzata per l'estrazione dal dossier di partenza e per l'integrazione nel dossier di destinazione. E' importante notare che i dati così estratti potranno modificare dei dati esistenti con le stesse chiavi o crearne di nuovi. Però, per ragioni di sicurezza, in nessun caso, ci sarà cancellazione di dati al momento dell'integrazione della patch. Così, ad esempio, se si considera la seguente situazione, per la tabella dei paesi (di abbreviazione TCY):

Se nella patch si indica una riga con TCY e la condizione CRY="AL", la patch conterrà solo la riga corrispondente al paese Albania e l'integrazione della patch nel dossier di destinazione riscriverà AL, Germania per sostituirla con AL, Albania.

Se nella patch si indica una riga con TCY e la condizione pat(CRY,"A*"), la patch conterrà le 4 righe AD, AE, AF e AR. All'integrazione, si creerà la scheda AE, Emirati Arabi Uniti, la scheda AR, Argentina, si sostituirà AL, Germania con AL, Albania e si manterrà A, Afghanistan, e AU, Australia, che non erano stati consegnati, ma esistevano già nel dossier di destinazione.

Se nella patch si indica una riga con TCY e la condizione find(CRY,"AD","AE","AL"), il risultato sarebbe stato lo stesso, salvo per quello che riguarda AR, Argentina, che non sarebbe stato trasferito.

La sola maniera di cancellare dei dati consiste:

• Sia nel sostituire globalmente il contenuto di una tabella completa (patch di tipo TAB)
• Sia nel consegnare un programma con il codice EXE (vedere qui sotto). Per esempio, si volesserro conservare nell'elenco dei paesi che cominciano per A solo i paesi di codice AD, AE, AL, si sarebbe consegnato un programma (chiamato per esempio MAJPATCHnnn) contenente le righe descritte nell'esempio qui di seguito.

Esecuzione di un programma

Un caso particolare deve essere menzionato: il codice EXE, che permette di dare il nome di un programma da eseguire. Questo programma viene eseguito a fine integrazione di patch (può già esistere o essere consegnato nella patch stessa, poichè l'esecuzione non si fa che alla fine dell'integrazione).

Tale programma deve integrare un sotto-programma PATCH, con un argomento che è il codice dossier. E' questo sotto-programma che sarà eseguito. Così, per il caso sopracitati, si otterrebbe il programma seguente:

Subprog PATCH(NOMDOS)
Value Char NOMDOS
Local File =NOMDOS+".TABCOUNTRY" [TCU]
Trbegin [TCU]
Delete [TCU] Where pat(CRY,"A*")=1 & find(CRY,"AD","AE","AL")=0
Commit
End

Così come lo si vede qui sopra, è dunque necessario dichiarare le tabelle in questo sotto-programma tenendo chiaramente conto del fatto che devono essere dichiarate su un dossier che non è necessariamente il dossier corrente (è la sintassi a sintassi Local File = NOMDOS + ".NOMTABLE" che l’assicura)

Programmi generici da eseguire

Quando si effettuano delle patch su elementi modello dell'interfaccia utente (videate modello utilizzate per creare delle finestre di transazione), è necessaria una rivalidazione delle videate in questione.

Tale rivalidazione può essere eseguita dichiarando, nella manutenzione, l'esecuzione del programma appropriato. Qui avanti vengono presentati i programmi standard da lanciare secondo il tipo di elemento patchato:

E' importante notare che questo tipo di funzionalità è realizzabile anche in specifico (è sufficiente aggiungere il sottoprogramma PATCH così come indicato nel paragrafo precedente).

Patch di documentazione

La struttura dei dati della documentazione è un po' particolare. Infatti, in creazione o rivalidazione di dossier, si applicano di default le regole seguenti:

• testi e file della documentazione (tabelle ADOCBLB e ADOCCLB) sono alimentati nel dossier supervisore e non vengono trasferiti nel dossiers dipendente (ma è possibile creare dei testi di help locali ad un dossier che verranno allora salvati in locale).
• la struttura della documentazione (legami di documentazione, che sono praticamente degli elementi del dizionario, e struttura dei paragrafi) viene memorizzata in ogni dossier e copiata nei dossier situati sotto in caso di rivalidazione (con il rispetto di codici attività verticali o specifici che avrebbero potuto essere definiti in un dossier figlio).

Così, quando si integra una patch di documentazione (tipo ADO), il principio è il seguente:

• la struttura della documentazione è integrabile in tutti i dossier elencati in fase di applicazione della patch, indipendentemente dal tipo di patch (in funzione dell'elenco dei dossier fornito all'integrazione).
• testi e file sono integrati solamente nel dossier supervisore se il tipo di patch è Supervisore (ciò che avviene per le patch di documentazione standard). Se il tipo di patch è diverso, testi e file possono essere integrati in tutti i dossier.
• la patch di tipo ADF (legami) è integrabile in tutti i dossier, anche se la patch è di tipo Supervisore.

Nomi dei file di patch

L'integrazione di patch verifica la sequenzialità di passaggio dei file di patch, nel momento in cui questi contengono una sequenza numerica nel loro nome. Si consiglia di chiamare i file di patch utilizzando un nome definito sotto la forma X_yyyy_zzz.dat, con i seguenti significati:

• X è un carattere (diverso da P, perchè P è utilizzato per le patch standard) che identifica il tipo di patch
• yyyy è un numero sequenziale (che comincia in principio con 0001).
• zzz è un identificativo della versione da integrare.

Se si applica questa norma, al momento dell'integrazione di un insieme di file di patch in una directory, saranno effettuati i seguenti controlli :

• non si mescolano in una stessa integrazione dei file generati da versioni diverse
• non si salta il numero sequenziale se delle patch identificate dallo stesso carattere e dallo stesso numero di versione sono già stati integrati. Così, per esempio, se la patch Z_0005_150.dat è stata integrata e se si tenta di integrare la patch Z_0007_150.dat senza avere prima integrato la patch Z_006_150.dat, un errore sarà segnalato all’integrazione.

Ordine degli elementi in un file di patch

Quando si crea un file di patch, la norma vuole che si faccia in modo che gli elementi che vi si trovano formino un tutto la cui applicazione lasci un dossier in una situazione coerente. In particolare, se si crea una nuova funzione con patch, e questa funzione è definita da un'azione, una finestra, una videata, una tabella e due programmi, appare logico che l'insieme di questi elementi sia presente nella patch.

Quando un insieme di elementi viene utilizzato per formare un file di patch, la funzione di creazione sistema tali elementi in un ordine preciso di tipi, allo scopo non avere errori all'integrazione. Infatti, se ad esempio si integra una finestra prima delle videate che la compongono, si otterrà un errore Videata inesistente durante la sua validazione. Così, si integrano prima di tutto i tipi di dati prima di videate e tabelle, le videate prima delle finestre, e così via.

L'ordine utilizzato in fase di generazione della patch corrisponde alla posizione fornita nel riquadro sopra. E' anche l'ordine proposto che appare nella funzione di patch automatica.

Occorre tuttavia osservare che non è possibile risolvere tutti i possibili conflitti. Infatti, per prendere un esempio, un tipo di dati può far riferimento ad un'azione, che può far riferimento ad una finestra, che può far riferimento ad una videata, che può far riferimento a questo tipo di dati. Per risolvere questo tipo di conflitto (raro), può essere necessario scomporre il file patch in due file (il primo contenente tutti gli elementi con un tipo di dati che non fa riferimento all'azione, il secondo contenente il tipo di dati che integra l'azione, ad esempio).

Elementi del dizionario non patchati

Quando si installa una patch contenente degli elementi del dizionario, bisogna notare che alcuni campi, considerati come elementi parametrizzabili del dizionario, vengono rispettati nonostante eventuali protezioni con codice attività di cui potrebbero beneficiare. E' il caso ad esempio di una destinazione di default in una stampa.

Si troverà in un allegato tecnico il dettaglio dei campi rispettati.

Formato particolare degli elementi AAA

Una patch di tipo AAA corrisponde ad una riga proveniente da un modello di parametrizzazione. Utilizza un formatto particolare per il codice dell'elemento. Tale formato è uno dei due seguenti formati:

MODELLO~COD_LEG~COD_TRS~='FORMULA_SELEZIONE'

MODELLO~COD_LEG~COD_TRS~CHIAVE~SOTTO_CHIAVE~SOTTO_SOTTO_CHIAVE...

In queste righe:

• MODELLO corrisponde al modello di dati utilizzato per descrivere le tabelle da estrarre
• COD_LEG corrisponde al codice legislazione, che può essere vuoto (si avranno allora due ~ successivi)
• COD_TRS corrisponde al codice transazione, che può anch'esso essere vuoto
• FORMULA_SELEZIONE è una condizione di filtro. Ogni stringa di testo deve essere espressa "tra doppi apici", poiché la formula è delimitata 'da singoli apici'.
• CHIAVE~SOTTO_CHIAVE~SOTTO_SOTTO_CHIAVE (dove il numero di sotto-chiavi è variabile) corrisponde al caso particolare in cui si vuole semplicemente selezionare un valore di chiave corrispondente alla tabella principale del modello. Questo tipo è possibile solo quando si richiama un modello (codice AAA) dalla creazione patch, e quando si apre la finestra che permette di conseguenza di selezionare il modello ed indicare la chiave per ricerca diretta.

Stampe

Di default, le seguenti stampe sono associate alla funzione :

 PRTSCR : Stampa Videata

Ma ciò lo si può modificare tramite parametrizzazione.

Job batch

Questa funzione può essere lanciata in batch. Il job standard ZPATCHC è previsto per questo.

Bottoni specifici

Messaggi di errore

Oltre ai messaggi generici, i seguenti messaggi d'errore possono apparire al momento dell'inserimento :

…. : directory inesistente

Il percorso d'accesso al file patch non esiste

Tipo oggetto errato

Il tipo di oggetto non corrisponde né ad un tipo di oggetti predefiniti, né all'abbreviazione di una tabella esistente.

Dizionario ... XXX scheda inesistente

Si è tentato di estrarre un oggetto dal dizionario che non esiste

Valore errato

La condizione di estrazione associata all'estrazione dei dati di una tabella è sintatticamente errata.

Tabelle utilizzate

Riferirsi alla documentazione di Implementazione