SWN016 - Modelli matricola¶
Nome programma SWN016 Linkage section UTILAGPRG - Linkage comune Id processo: 19 Nome processo: MODELLI-MATRICOLA Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
| ASNMODEL | ARPMODEL | ------> <------ |
Logica generale Sincronizzazione dei modelli matricola. Esportazione Esportazione di tutti i modelli effettivamente modificati (con dati variati). Importazione Le applicazioni WEB potranno inserire, modificare o cancellare logicamente nuovi modelli Configurazioni possibili
| Gruppo | Parametro | Note |
|---|---|---|
| abilita | attiva-areaapp | |
| areaapp | cod-azienda | |
| areaapp | db-conn-string | |
| areaapp | agg-postgres-online |
Elaborazione Tipi di segnalazione: Vedi Tipi di segnalazione A - Controllo di esecuzione Vedi Controllo di esecuzione A.1 - Aggiornamento KEEP-ALIVE Per il momento non lo eseguiamo: il keep-alive viene tenuto aggiornato dal thread autonomo di aglancio; se il programma venisse chiamato in "tempo reale" dal programma di gestione, non necessita comunque del keep-alive. A.2 - Apertura A.2.1 Apertura tabelle Tentare l'apertura della tabella da sincronizzare: ARPMODEL Se fallita inviare una Segnalazione critica e chiudere. C - Importazione aggiornamenti Effettuare una query per estrarre tutti i modelli aggiornati su APP: SELECT * FROM arpmodel WHERE a_mod_azi = azienda AND a_mod_fl_agg = 'A' I modelli matricola potranno essere: * Cancellati: se A_MOD_FL_CANC = "C" * Inseriti o aggiornati: se A_MOD_FL_CANC <> "C" Corrispondenza tra modelli e marche La tabella ARPMODEL potrà contenere un solo modello con un deterrminato "nome" o codice, mentre su ASNMODEL potenzialmente potrebbe esserci uno stesso modello collegato ad una marca diversa. Quindi in fase di importazione dovremo tenere conto di questo. C.1 - Importazione modello matricola nuovo o aggiornato Diamo per scontato che esista un solo modello con un certo nome, altrimenti se viene modificato un modello, applicandolo ad una nuova marca, potrebbe nascere un duplicato non richiesto. Fare una ricerca su ASNMODEL usando AMOD-CHIA2 impostando:
| Dato | Contenuto |
|---|---|
| AMOD-NOME | A-MOD-COD |
Si effettua un inserimento solo se non esiste nessun modello con il nome A-MOD-COD. Altrimenti si effettuerà solo la variazione del modello trovato. In caso di inserimento si dovrà cercare il primo id modello disponibile (AMOD-ID), quindi effettuare immediatamente l'inserimento del modello stesso. Quindi proseguire con l'aggiornamento di ASNMODEL.
| Dato | Contenuto |
|---|---|
| AMOD-MARCA | A-MOD-MARCA |
| AMOD-NOME | A-MOD-COD |
| AMOD-DES | A-MOD-DES |
| AMOD-TIP-MTR | Non dovrebbe essere usato, in ogni caso lasciare invariato |
| AMOD-MOD-SCHEDA | A-M OD-MODELLO-CERT |
| AMOD-TCL-COD | A-MOD-TCL-COD |
| AMOD-TCL-MOD | A-MOD-TCL-MOD |
| AMOD-COD-NOM | A-MOD-COD-NOM |
| AMOD-CANONE | Lasciare invariato |
C.2 - Importazione marca cancellata Diamo per scontato che esista un solo modello con un certo nome, altrimenti se viene modificato un modello, applicandolo ad una nuova marca, potrebbe nascere un duplicato non richiesto. Fare una ricerca su ASNMODEL usando AMOD-CHIA2 impostando:
| Dato | Contenuto |
|---|---|
| AMOD-NOME | A-MOD-COD |
Effettuare la cancellazione fisica di tutti i modelli con il nome cercato. B - Esportazione informazioni aggiornate * ID SINCRO: gestito * Esportazione differenziale: gestita ma non ottimizzata: non esiste una chiave diretta per ottenere solo i record aggiornati * Cancellazione logica: gestita In questa fase si dovrà tenere conto di * Limite record * Limite errori * "Esporta tutto" B.1 - Stato sincronizzazione Sulla tabella APSTATOSYN, leggere il record relativo alla tabella/oggetto da sincronizzare "ARPMODEL"; se il record non esiste, crearlo impostando
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "ARPMODEL" |
| A_SYN_DA_GES_DATA | 0 |
| A_SYN_DA_GES_ORA | 0 |
| A_SYN_DA_ID_SINCRO | 1 |
Qui otterremo due informazioni importanti: * Data/ora ultima esportazione da gestionale a postgres (A_SYN_DA_GES_DATA e A_SY_DA_GES_ORA) * Prossimo ID sincronizzazione da memorizzare sulla tabella (A_SYN_ID_SINCRO) B.2 - Ricerca record da esportare B.2.1 Ricerca record da esportare
| Tipo di elaborazione | Condizione | Cosa fare |
|---|---|---|
| Singolo record | AGPRG-KEY <> " " (conterrà AMRC-CHIA1) |
Si legge direttamente il record da aggiornare su ASNMODEL Verrà eseguita se agg-postgres-online è attiva Se viene sincronizzato un record cancellato, verrà effettuata la cancellazione logica |
| Esportazione totale | AGPRG-ESPORTA-TUTTO = "S" | Si scorrono tutti i record di ASNMODEL; ogni record va considerato, ignorando il controllo sulla variazione dei record |
| Esportazione standard | Si scorrono tutti i record di ASNMODEL: si considerano solo i record dove: (AMOD-DA-DATA+AMOD-DA-TIME) >= (A-SYN-DA-GES-DATA+A-SYN-DA-GES-ORA) |
|
| Pulizia | AGPRG-OPE = "PULIZIA" | Eseguire solo il giro di cancellazione logica B.3 quindi uscire |
Per ciascun record valido si cercano tutti i record collegati: Nessuno B.2.2 Verifica ed esportazione record Dopodichè si effettua la ricerca dell'informazione su ARPMODEL
| Dato | Contenuto |
|---|---|
| A-MOD-AZI | Codice azienda |
| A-MOD-COD | AMOD-COD |
Se non esiste, inserirlo. Se esiste, aggiornarlo l'aggiornamento del record deve avvenire solo se almeno un dato tra quelli da modificare è diverso. NB: se è stata richiesta l'esportazione completa (AGPRG-ESPORTA-TUTTO = "S") allora il record dovrà essere esportato a prescindere dal confronto Suggerimento Invece di popolare direttamente i dati del record di destinazione, portarli su delle copie in w/s. Al termine confrontare i dati sulla destinazione con la copia in w/s. Aggiornamento da ASNMODEL NB: se a questo punto A-MOD-FL-AGG vale "A", significa che nel lasso di tempo tra la fase di importazione e questa, qualcuno ha aggiornato il record su APP: quindi segnalare sul log e ignorare l'esportazione.
| Dato | Contenuto | Confronto? |
|---|---|---|
| A-MOD-AZI | Codice azienda | |
| A-MOD-COD | AMOD-COD | |
| A-MOD-DES | AMOD-DES | Si |
| A-MOD-MARCA | AMOD-MARCA | Si |
| A-MOD-MODELLO-CERT | AMOD-MODELLO-CERT | Si |
| A-MOD-TCL-COD | AMOD-TCL-COD | Si |
| A-MOD-TCL-MOD | AMOD-TCL-MOD | Si |
| A-MOD-COD-NOM | AMOD-COD-NOM | Si |
| A-MOD-FL-CANC | " " | Si |
| A-MOD-ID-SINCRO | Prossimo id sincro | |
| A-MOD-FL-AGG | " " |
In questa fase tenere memoria di data+ora dell'ultimo record di input considerato. Per tutti i campi alfanumerici significativi (non flag, non valori fissi) effettuare il parsing tramite GESSTR, come già fatto negli altri programmi di sincronizzazione B.3 Verifica record cancellati Sulla tabella di origine ASNMODEL non esiste il flag di cancellazione logica. Quindi si opererà come segue: 1. Scorrere tutti i record di ARPMODEL per l'azienda 2. Ricerca, per ciascuno, del corrispondente record su ASNMODEL A questo punto la situazione potrebbe essere la seguente:
| ASNMODEL trovato? | A-MOD-FL-CANC | Cosa fare |
|---|---|---|
| Si | "C" | Aggiornare ARPMODEL impostando |
| Si | " " | Nessuna operazione |
| No | "C" | Nessuna operazione |
| No | " " | Aggiornare ARPMODEL impostando |
B.9 - Aggiornamento id syncro Al termine dell'elaborazione, aggiornare il record APSTATOSYN:
| Dato | Contenuto |
|---|---|
| A_SYN_AZIENDA | Codice azienda |
| A_SYN_TABELLA | "ARPMODEL" |
| A_SYN_DA_GES_DATA | Data/ora dell'ultimo record aggiornato |
| A_SYN_DA_GES_ORA | |
| A_SYN_DA_ID_SINCRO | Ultimo id sincro + 1 |
Estratto da documentazione interna ClickUp