SWN041 - Destinazioni diverse¶
Nome programma SWN041 Linkage section UTILAGPRG - Linkage comune Id processo: 44 Nome processo: ZONE Tabella APSTATOSYN
| A-SYN-TABELLA | VERSIONE ATTUALE | Cosa fare se precedente |
|---|---|---|
| COGDESTI | 2 |
Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
| COGDESTI COGDEST2 |
APCOGDESTI | ------> <------ |
Logica generale Sincronizzazione delle destinazioni diverse. Esportazione Esportazione di tutti i destinazioni effettivamente modificate (con dati variati). Importazione Le applicazioni WEB potranno inserire, modificare o cancellare logicamente nuove destinazioni 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: APCOGDESTI Se fallita inviare una Segnalazione critica e chiudere. C - Importazione aggiornamenti (ex A - SWA064) Effettuare una query per estrarre tutti gli elementi aggiornati su APP: SELECT * FROM APCOGDESTI WHERE a_dst_azi = azienda AND (a_dst_agg_app = 'A') Gli elementi potranno essere: * Inseriti: se A_DST_ID_DST_TIP = ' ' * Aggiornati: se A_DST_ID_DST_TIP <> ' ': in questo caso rientrano anche i record cancellati logicamente C.1 - Importazione elemento nuovo C.1.1 - Creazione nuova destinazione Creazione di un nuovo record su COGDESTI
| Nome campo | Note |
|---|---|
| DST-ANA | A-DST-ANA |
| DST-ID-TIP | A-DST-ID-DST-TIP |
| DST-ID-IDX | Primo progressivo libero a parità di anagrafica e tipo destinazione |
| DST-RAG-SOC | A-DST-RAG-SOC |
| DST-IND | A-DST-IND |
| DST-CAP | 0 |
| DST-LOCA | A-DST-LOCA |
| DST-PROV | A-DST-PROG |
| DST-FL-DEFAULT | A-DST-FL-DEFAULT |
| DST-FL-CANC | A-DST-FL-CANC |
| DST-EMAIL | A-DST-FL-EMAIL |
| DST-CAP-ALFA | A-DST-CAP |
COGDEST2:
| Nome campo | Note |
|---|---|
| DST2-CHIA1 | DST-CHIA1 |
| DST2-ZONA | A-DST-ZONA |
| DST2-NOTE | A-DST-NOTE |
| DST2-CODICE-HOST | A-DST-CODICE-HOST |
| DST2-AGENTE | A-DST-AGENTE |
| DST2-LATITUDINE | A-DST-LATITUDINE |
| DST2-LONGITUDINE | A-DST-LONGITUDINE |
| DST2-FL-LUNEDI | A-DST-FL-LUNEDI |
| DST2-FL-MARTEDI | A-DST-FL-MARTEDI |
| DST2-FL-MERCOLEDI | A-DST-FL-MERCOLEDI |
| DST2-FL-GIOVEDI | A-DST-FL-GIOVEDI |
| DST2-FL-VENERDI | A-DST-FL-VENERDI |
| DST2-FL-SABATO | A-DST-FL-SABATO |
| DST2-FL-DOMENICA | A-DST-FL-DOMENICA |
| DST2-LEAD-TIME-PREP | A-DST-LEAD-TIME-PREP |
| DST2-LEAD-TIME-CONS | A-DST-LEAD-TIME-CONS |
| DST2-ID-DESTINAZIONE | A-DST-ID-DESTINAZIONE |
| DST2-TELEFONO | A-DST-TELEFONO |
C.1.2 - Rimozione record di input Il record di origine da cui siamo partiti su APCOGDESTI va cancellato. C.1.3 - Creazione immediata destinazione "ufficiale" A questo punto è necessario effettuare immediatamente l'esportazione della destinazione appena importata. Si può effettuare semplicemente eseguendo l'operazione già creata per eseguire il punto B.2.2 Dopodichè aggiornare il record APCOGDESTI per memorizzare:
| Nome campo | Contenuto |
|---|---|
| A-DST-IDD-ORIG | A-DST-ID-DISPOSITIVO del record appena cancellato |
| A-DST-IDD-PROG-ORIG | A-DST-IDD-PROG del record appena cancellato |
C.2 - Importazione elemento aggiornato C.2.1 - Aggiornamento destinazione Fare una ricerca su COGDESTI impostando:
| Dato | Contenuto |
|---|---|
| DST-ANA | A-DST-ANA |
| DST-ID-TIP | A-DST-ID-DST-TIP |
| DST-ID-IDX | A-DST-ID-DST-IDX |
Se l'elemento non esiste, inserirlo. Quindi proseguire con l'aggiornamento di COGDESTI.
| Dato | Contenuto |
|---|---|
| DST-RAG-SOC | A-DST-RAG-SOC |
| DST-IND | A-DST-IND |
| DST-CAP | 0 |
| DST-LOCA | A-DST-LOCA |
| DST-PROV | A-DST-PROG |
| DST-FL-DEFAULT | A-DST-FL-DEFAULT |
| DST-FL-CANC | A-DST-FL-CANC |
| DST-EMAIL | A-DST-FL-EMAIL |
| DST-CAP-ALFA | A-DST-CAP |
Poi con l'inserimento o aggiornamento di COGDEST2.
| Nome campo | Note |
|---|---|
| DST2-CHIA1 | DST-CHIA1 |
| DST2-ZONA | A-DST-ZONA |
| DST2-NOTE | A-DST-NOTE |
| DST2-CODICE-HOST | A-DST-CODICE-HOST |
| DST2-AGENTE | A-DST-AGENTE |
| DST2-LATITUDINE | Se sono vuoti, importarli da A-DST-LATITUDINE, A-DST-LONGITUDINE, altrimenti lasciarli invariati |
| DST2-LONGITUDINE | |
| DST2-FL-LUNEDI | A-DST-FL-LUNEDI |
| DST2-FL-MARTEDI | A-DST-FL-MARTEDI |
| DST2-FL-MERCOLEDI | A-DST-FL-MERCOLEDI |
| DST2-FL-GIOVEDI | A-DST-FL-GIOVEDI |
| DST2-FL-VENERDI | A-DST-FL-VENERDI |
| DST2-FL-SABATO | A-DST-FL-SABATO |
| DST2-FL-DOMENICA | A-DST-FL-DOMENICA |
| DST2-LEAD-TIME-PREP | A-DST-LEAD-TIME-PREP |
| DST2-LEAD-TIME-CONS | A-DST-LEAD-TIME-CONS |
| DST2-ID-DESTINAZIONE | A-DST-ID-DESTINAZIONE |
| DST2-TELEFONO | A-DST-TELEFONO |
C.2.2 - Aggiornamento APCOGDESTI Aggiornare il record di origine APCOGDESTI impostando
| Nome campo | Note |
|---|---|
| A-DST-AGG-APP | "N" |
B - Esportazione elementi aggiornati * ID SINCRO: gestito * Esportazione differenziale: gestita ma non ottimizzata: non esiste una chiave diretta per ottenere solo i record aggiornati * Cancellazione logica: non 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 "COGDESTI"; se il record non esiste, crearlo impostando
| Dato | Contenuto |
|---|---|
| A-SYN-AZIENDA | Codice azienda |
| A-SYN-TABELLA | "COGDESTI" |
| 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à DST-CHIA1) |
Si legge direttamente il record da aggiornare su COGDESTI 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 COGDESTI; ogni record va considerato, ignorando il controllo sulla variazione dei record |
| Esportazione standard | Si scorrono tutti i record di COGDESTI e COGDEST2 con data/ora aggiornamento maggiore o uguale all'ultimo eseguito | |
| 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: COGDEST2 B.2.2 Verifica ed esportazione record Dobbiamo esportare solo le destinazioni merce: quindi se: * DST-ID-TIP <> "D" scartare il record Dopodichè si effettua la ricerca del record su APCOGDESTI
| Dato | Contenuto |
|---|---|
| A-DST-AZI | Codice azienda |
| A-DST-ID-DISPOSITIVO | 0 |
| A-DST-IDD-PROG | 0 |
| A-DST-ANA | DST-ANA |
| A-DST-ID-TIP | DST-ID-TIP |
| A-DST-ID-IDX | DST-ID-IDX |
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 COGDESTI NB: se a questo punto A-DST-AGG-APP 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-DST-AZI | Codice azienda | |
| A-DST-ID-DISPOSITIVO | 0 | |
| A-DST-IDD-PROG | 0 | |
| A-DST-ANA | DST-ANA | |
| A-DST-ID-TIP | DST-ID-TIP | |
| A-DST-ID-IDX | DST-ID-IDX | |
| A-DST-RAG-SOC | DST-RAG-SOC (*) | Si |
| A-DST-IND | DST-IND (*) | Si |
| A-DST-CAP | DST-CAP-ALFA | Si |
| A-DST-LOCA | DST-LOCA (*) | Si |
| A-DST-PROV | DST-PROV | Si |
| A-DST-FL-DEFAULT | DST-FL-DEFAULT | Si |
| A-DST-FL-CANC | DST-FL-CANC | Si |
| A-DST-VAL | DST-FL-CANC | Si |
| A-DST-EMAIL | DST-EMAIL | Si |
| A-DST-LATITUDINE | Vedi B.2.3 | Si |
| A-DST-LONGITUDINE | Si | |
| A-DST-ZONA | DST2-ZONA | Si |
| A-DST-NOTE | DST2-NOTE (*) | Si |
| A-DST-AGENTE | DST2-AGENTE | Si |
| A-DST-FL-LUNEDI | DST2-FL-LUNEDI | Si |
| A-DST-FL-MARTEDI | DST2-FL-MARTEDI | Si |
| A-DST-FL-MERCOLEDI | DST2-FL-MERCOLEDI | Si |
| A-DST-FL-GIOVEDI | DST2-FL-GIOVEDI | Si |
| A-DST-FL-VENERDI | DST2-FL-VENERDI | Si |
| A-DST-FL-SABATO | DST2-FL-SABATO | Si |
| A-DST-FL-DOMENICA | DST2-FL-DOMENICA | Si |
| A-DST-LEAD-TIME-PREP | DST2-LEAD-TIME-PREP | Si |
| A-DST-LEAD-TIME-CONS | DST2-LEAD-TIME-CONS | Si |
| A-DST-ID-SINCRO | Prossimo id sincro | |
| A-DST-AGG-AGG | "N" |
(*) Questi campi devono essere parsati da GESSTR con operazione "CONV-TESTO-X-ESPORT" prima di effettuare il confronto In questa fase tenere memoria di data+ora dell'ultimo record di input considerato. B.2.3 - Aggiornamento coordinate geografiche Se i dati che identificano l'indirizzo della destinazione sono diversi da quelli già presenti (indirizzo, cap, località, provincia), o se la destinazione è nuova, azzerare le coordinate. Altrimenti, se le coordinate su COGDEST2 sono diverse da quelle su APCOGDESTI, esportarle. Se dopo l'aggiornamento le coordinate (A-DST-LATITUDINE/A-DST-LONGITUDINE) sono vuote, alzare un flag FL-RICALCOLO-GEOMAPPING) B.3 - Aggiornamento coordinate geografiche Al termine dell'esportazione delle destinazioni, se una di quelle aggiornate ha le coordinate vuote (FL-RICALCOLO-GEOMAPPING), allora innescare in comando che invoca un apposito script che permette il ricalcolo su WEB; vedi SWA064, procedura b-geomapping-clienti; il comando in questo caso è : string "https://kpngate.es2000.it/coordinate/" "getCoordinate2.php?azienda=" tm-cfg-cod-azienda Generalmente il comando viene eseguito con una chiamata a "BROWSER"; in un caso (per ora, azienda C04493) viene eseguita tramite "CURL" B.4 Verifica record cancellati Sulla tabella di origine COGDESTI esiste il flag di cancellazione logica, ma alcune funzioni non gestite correttamente potrebbero tuttora effettuare cancellazione fisica. Quindi si opererà come segue: 1. Scorrere tutti i record di APCOGDESTI per l'azienda 2. Ricerca, per ciascuno, del corrispondente record su COGDESTI A questo punto la situazione potrebbe essere la seguente:
| COGDESTI trovato? | A-DST-FL-CANC | Cosa fare |
|---|---|---|
| Si | "C" | Aggiornare APCOGDESTI impostando |
| Si | " " | Nessuna operazione |
| No | "C" | Nessuna operazione |
| No | " " | Aggiornare APCOGDESTI impostando |
B.9 - Aggiornamento id syncro Al termine dell'elaborazione, aggiornare il record APSTATOSYN:
| Dato | Contenuto |
|---|---|
| A-SYN-AZIENDA | Codice azienda |
| A-SYN-TABELLA | "COGDESTI" |
| 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