Gestione log di processo e impostazioni predefinite¶
Memorizzazione impostazioni predefinite su una maschera¶
Nelle funzioni di visualizzazione potrebbe essere comodo poter memorizzare ad esempio filtri predefiniti, richiamabili successivamente dallo stesso utente o da altri.
L'operazione in se non e' difficoltosa ma potrebbe essere onerosa in termini di lavoro: per ciascun filtro presente nella maschera si dovrebbe memorizzare un'informazione in una apposita tabella.
Si potrebbe invece usare screens per "preparare" tutti i dati necessari; nel singolo programma lo sviluppatore dovrebbe semplicemente richiamare una funzione che esegue tutte le operazioni necessarie allo scopo, passandogli un'area di working contenente tutti i campi previsti (potenzialmente tutti i campi della maschera, per tutte le maschere, anche quelle di gestione).
Il tutto richiamabile con un tasto funzione o con una voce di menu abilitata appositamente nella funzione abilitata.
Nome ipotetico della voce di menu: Impostazioni predefinite.
Linee guida di realizzazione: * Su screens definire quali campi di una maschera devono essere esclusi da questa possibilita' * Durante la generazione maschera, generare un gruppo di dati, chiamato ad esempio "TM-INTERFACE" al di sotto dei quali creare automaticamente le variabili associate ai controlli * Creazione tabella che potra' contenere l'elenco delle impostazioni predefinite per ciascuna funzione prevista; per ciascuna ci sara': * Testata * Funzione * Progressivo * Descrizione * Flag pubblica/privata * Dettaglio * Chiave testata * progressivo informazione (in modo che sia possibile riconoscere a quale campo e' associato) * contenuto informazione * Abilitazione * Chiave testata * Operatore * Abilitato S/N * Default S/N * Realizzazione della funzione di gestione, che avra' in linkage un'area dati generica sufficiente a contenere l'insieme dei campi al di sotto di TM-INTERFACE; le operazioni potranno essere * "SALVA": permettera' di salvare il contenuto corrente in una nuova impostazione predefinita * "CARICA-DEFAULT": permettera' di aprire automaticamente l'impostazione predefinita di default per l'operatore corrente * "SELEZIONA": apre l'elenco delle impostazioni predefinite configurate e definite come pubbliche
NB: considerare la possibilita' di modifica della maschera!! Di conseguenza le impostazioni gia' memorizzate dovranno tenerne conto....
Definizione campi all'interno delle impostazioni¶
Ogni funzione (programma) ha al suo interno un insieme di controlli, ai quali sono associati campi il cui contenuto va memorizzato nelle impostazioni predefinite.
Il nome controllo attribuito in screens al campo rappresenta l'identificativo univoco che si potra' usare per riconoscere il campo (quindi nella tabella di dettaglio).
La dimensione (Caratteri) e il progressivo di informazione (Progr.) definiti in screens permetteranno alla funzione di gestione di suddividere l'area passata dalla funzione chiamante nei singoli dati da memorizzare o da restituire.
Gestione log di processo¶
Descrizione procedura Alcune procedure dell'applicazioni scrivono dei log piu' o meno dettagliati che possono servire sia all'assistenza per capire il flusso delle operazioni che stanno alla base di una procedura, che all'utente quando questi log contengono ad esempio esiti di ricostruzione. Tutti questi log finora venivano scritti in documenti in formato testo all'interno della cartella "log" configurata (generalmente una sottocartella della cartella dove sono memorizzati gli archivi). Di conseguenza diventava difficile in alcuni casi (soprattutto in ambito cloud) recuperare questi log, aprirli, e scorrerne il contenuto. Inoltre questo generava una miriade di documenti all'interno della cartella "log" che di tanto in tanto e' necessario pulire. Quindi ora e' stata implementata una nuova modalita' di gestione dei log di procedura, che registra il log in un vero e proprio registro eventi, consultabile attraverso una apposita funzione. Le funzioni che scrivono questi log verranno man mano migrate a questa nuova modalita'.
Contenuto di una registrazione di log Il dettaglio di una singola registrazione e' descritto nella documentazione del programma di consultazione Consultazione log di processo. Tra le colonne disponibili c'e' anche la Procedura su cui vale la pena soffermarsi.
Procedure La procedura racchiude generalmente tutti gli eventi generati da un singolo programma/funzione durante una elaborazione che si apre e chiude al proprio interno. La procedura e' un campo alfanumerico che generalmente (potrebbe essere diverso in casi specifici) e' composto da: PROGRAMMA-DATA-ORA Durante la consultazione del log processi e' possibile, filtrando su questa informazione, ottenere solo gli eventi che corrispondono ad una determinata procedura. In alcuni casi per portare a compimento un processo, un programma ne puo' invocare altri che apriranno a loro volta un'altra procedura, e la chiuderanno al loro termine. Questa "sottoprocedura" verra' collegata a quella da cui e' stata invocata, che diventera' quindi la procedura padre. Questa iterazione potrebbe arrivare a diversi livelli di procedura incastonati uno all'interno dell'altro. Nella funzione di consultazione e' presente infatti un componente tree-view con cui viene mostrato il collegamento tra le varie procedure.
Note tecniche La tabella su cui viene memorizzato questo registro eventi si chiama LOGPROG, ed e' memorizzata nella cartella "log" con architettura VISION 5. Il processo di memorizzazione del log, se si accorge di problemi sulla tabella principale indicizzata, inizia a memorizzare tutte le registrazioni in nuovo archivio parallelo in formato sequenziale, chiamato LOGPROC.TXT. Successivamente quando il file principale ritorna on-line, i log saranno scritti nuovamente qui. Il processo temporizzato che si occupa della cancellazione dei log vecchi, verifica anche l'esistenza del file in formato sequenziale: se viene trovato e il log principale e' disponibile, tentera' di recuperarlo, e se questo procedimento va a buon fine verra' cancellato. Se durante l'operazione di ripristino succede qualche inconveniente, il file sequenziale sara' rinominato come "LOGPROC_data-ora._TXT".
Configurazioni interessate
| Gruppo | Parametro | Note |
|---|---|---|
| cogesys | giorni-log-processo | Permette di decidere per quanti giorni i log di processo rimarranno memorizzati prima di essere cancellati |
Funzioni di gestione Consultazione log di processo Questa funzione permette di consultare il contenuto del registro log di processo.
Caratteristiche di un log di processo Un singolo processo potrebbe comprendere l'elaborazione effettuata da piu' programmi, che agiscono insieme per ottenere un determinato risultato. Quindi, tutti i log registrati a fronte di un processo potrebbero essere identificati dall'id del processo server (fornito dal pc) e dalla data/ora elaborazione. Nella tabella di gestione ho previsto anche un tipo/chiave documento principale collegato. Potrebbe essere utile quando si vuole poter richiamare da un programma di gestione, ad esempio di un documento di uscita, un elenco degli eventi collegati ad esso.
Questa gestione nasce con l'intento di centralizzare e raggruppare tutto quello che attualmente invece viene gestito dai vari file sequenziali di log presenti nella cartella EXT-LOG-DIR; soprattutto quelli che generano miriadi di piccoli files, uno per ciascuna elaborazione. Ad esempio: * Importazione interventi
Gestione procedura Ogni programma che puo' scrivere un evento, lo fara' nel contesto di una procedura, che potrebbe banalmente essere identificata da programma-datainizio-orainizio. Per meglio tracciare quello che puo' succedere, i singoli programmi potranno eseguire la sequenza: 1. Apertura procedura 2. elaborazione - notifica eventi 3. Chiusura procedura
Se nell'ambito di una elaborazione sono interessati dei sottoprogrammi, possono esserci due casi: 1. Sottoprogrammi "slave": sono sottoprogrammi che non aprono una procedura autonoma, quindi non eseguiranno le operazioni di apertura/chiusura procedura 2. Sottoprogrammi indipendenti: sono sottoprogrammi che possono essere anche richiamati autonomamente, quindi apriranno e chiuderanno una procedura autonoma. In questo caso, se richiamati con una procedura attiva, questa diventera' la procedura padre.
Programmi interessati * GESLPRC - Aggiornamento log processi: programma di memorizzazione. Sara' richiamato quando necessario tracciare una determinata elaborazione. * Consultazione log di processo * CLEARLOG - cancellazione schedulata log archivi
Tabelle interessate * LOGPROC - Log segnalazioni su programmi/procedure
Note per i programmatori¶
La gestione del registro eventi viene effettuata tramite la subroutine GESLPRC - Aggiornamento log processi. Ciascun programma che deve registrare dei log dovrebbe effettuare le seguenti chiamate in sequenza a GESLPRC: * Operazione: "APRI-PROCEDURA" (generalmente una volta per ciascun programma all'inizio; se necessario indicare un nome procedura specifico, altrimenti lasciare vuoto: verra' generato dalla subroutine) * Operazione: "SCRIVI": tante volte quanto necessario, passando il messaggio da registrare e il tipo di segnalazione (I/W/E) * Operazione: "CHIUDI-PROCEDURA": generalmente una volta al termine del programma. * Operazione: "CONSULTA-PROCEDURA": solo se necessario, per permettere ad un utente di consultare il risultato dell'elaborazione, passando il codice della procedura creata.
Sostituzione log precedenti Molti programmi attualmente usano LOGFILE per la scrittura di file di log. Quando possibile, questi programmi possono essere migrati alla nuova modalita' con le seguenti operazioni (vedi ad esempio SWA005): 1. Rimuovere la definizione di LOGFILE all'interno del programma (FD,CPY e DECLARATIVES) 2. Rimuovere makelog.cpy al termine del programma 3. Aggiungere in working LOG-LINE x(300) (questo permette di usare tutta la logica gia' presente) 4. Aggiungere la perform write-logfile-dynamic: conterra' la chiamata all'operazione SCRIVI di GESLPRC, passando LOG-LINE al messaggio da memorizzare 5. Aggiungere all'inizio del programma la APRI-PROCEDURA 6. Aggiungere alla fine del programma la CHIUDI-PROCEDURA
Questo dovrebbe essere sufficiente per usare la nuova modalita'. Se necessario (ad esempio nei programmi che al termine eseguono gia l'apertura del file di log con NOTEPAD), aggiungere la chiamata CONSULTA-PROCEDURA.
Pulizia log Il programma CLEARLOG inizialmente pensato per la pulizia automatizzata dei log su tabella, ora esegue anche la pulizia di log di processo, con una chiamata specifica a GESLPRC. Quindi su ciascuna installazione e' necessario aggiungere la schedulazione di questo programma, tramite Z-CRON o all'interno del processo COGSKP.
Tipi documento utilizzati¶
| Tipo documento | Descrizione | Chiave documento |
|---|---|---|
| AI | Intervento di assistenza | ACIT-CHIA1 |
| AC | Chiamate di assistenza | ACHT-CHIA1 |
| DMC | Documenti di magazzino a cliente | TES-CHIA3 |
Questi tipi documento sono all'interno della copy costanti-tipi-documento.cpy
Programmi di gestione tabella¶
Saranno rilasciati man mano dei programmi di gestione tabella, che permettono la consultazione del contenuto delle tabelle, e, con occhio di riguardo, anche la modifica dei dati.
Esecuzione Questi programmi saranno eseguibili da programmi di sistema: il nome di ciascun programma e' identico al nome della tabella, ma con la prima lettera sostituita con una "Y" (non era possibile usare lo stesso nome di tabella perche' in alcuni casi il nome era gia' occupato). Ad esempio, il programma di gestione di COGMERCI sara' "YOGMERCI". Inoltre e' possibile innescarli premendo F6 dai programmi di gestione nomi files (ad esempio da COGE01).
Versioni La versione attuale dei programmi di gestione e' 10. Per ciascuna versione riepilogo qui l'elenco delle funzionalita' principali disponibili.
| Versione | Funzionalita' |
|---|---|
| 3 | Consultazione record in griglia (max 99 colonne). NB: gli aggiornamenti vengono consolidati premendo F3 |
| 4 | |
| 5 | Filtri ottimizzati in funzione degli indici della tabella |
| 6 | Gestione lookup: possibilita' di aprire una finestra di lookup sui campi che lo prevedono. Per il momento non e' possibile selezionare un valore da riportare sul campo di origine |
| 7 | Gestione dipendenze |
| 8 | Gestione log archivi - Possibilita' di collegarsi al log aggiornamenti del record, se configurato per la tabella |
| 9 | Tabelle Postgres - Possibilita' di gestire tabelle su db Postgres, collegate ai due db |
| 10 | Importazione da Excel - I manutentori di questa versione sono associati ad un profilo standard di import/export, chiamato come la tabella stessa. Nel profilo esiste la possibilita' di associare una colonna ad uno specifico dato del record. Premendo S-F8 sara' possibile acquisire il contenuto della tabella da un foglio generico di Excel |
| 11 | Condivisione informazioni - Da questa versione i dati utilizzati per la gestione della griglia vengono esportati in copy utili nel caso in cui sia necessario estrarre dati formattati dal file da un programma esterno. Vedi COGZ6B |
Istruzioni per creazione/aggiornamento dei programmi di gestione
Rigenerazione XFD La costruzione del programma usa le XFD, che dovranno quindi essere aggiornate. Eseguire quindi la compilazione di un programma che usa il file con l'opzione per la generazione delle XFD.
Inizio Partendo da screens, indicare il pacchetto (sempre EUROCOGE) e il nome del programma di gestione, che deve essere il nome della tabella con la "Y" al posto della prima lettera; ad esempio, il programma di gestione di COGMERFO sara' YOGMERFO. A questo punto apparira' un messaggio informativo: "Gestione tabella"
Nuovo programma Se il programma da costruire non esiste ancora (e' la prima volta che viene costruito), apparira' un nuovo messaggio che richiede Programma non esistente in RELEASE. Lo genero? a cui si dovra' rispondere "Si". Questa operazione aggiungera' quindi il programma Yxxxxxxx su RELEASE.
Creazione/aggiornamento form Ora si prosegue con la generazione della screen in modo normale. Si arriva ad un nuovo messaggio che informa: "Nuovo programma di gestione tabella. Genero la form.". Si aprira' il programma di duplicazione form, che proporra' come programma di partenza il programma F-TEMPL, che altro non e' che un template di creazione della versione corrente dei programmi di gestione tabella. Proseguire quindi premendo invio finche' la creazione non viene ultimata. Questa fase avverra' solo se: * Il programma e' nuovo * Se la versione del programma di gestione e' inferiore a quella attuale.
Verifica struttura file Nella gestione della form e' possibile vedere la simulazione della form, ma non e' necessario effettuare nessuna modifica. Entrare quindi in gestione file (F6): sara' presente il file di cui eseguire la gestione. Entrare quindi nella funzione F7 (attualmente non collegata ad un pulsante della toolbar), che rigenerera' la base dati necessaria per la creazione dei campi di dettaglio. Chiudere quindi con F3 per confermare e ritornare nella maschera principale di screens.
Apertura e chiusura commessa Ora, sia in caso di prima creazione che di aggiornamento, aprire la commessa che servira' per rilasciare il programma presso i clienti.
Generazione componenti Dalla schermata principale di screens, eseguire la generazione dei componenti programma come per un programma standard. La differenza principale e' che in questo caso verra' generato anche il file p:\eurocoge\cbl\Yxxxxxxx.CBL.
Compilazione programma e test Compilare il programma in modo normale. In qualsiasi ambiente il programma potra' essere aperto da programmi di sistema, e/o dal programma di gestione tabella files (attualmente solo COGE01).
Chiusura commessa A questo punto la commessa puo' essere chiusa.
Estratto da documentazione interna ClickUp