SWN073 - Utenti¶
Nome programma SWN073 Linkage section UTILAGPRG - Linkage comune Id processo: 73 Nome processo: UTENTI Tabelle principali gestite
| AREA | AREAGATE | Direzione |
|---|---|---|
| PRNTOPER CRMUSERS |
APUTENTI | ------> |
Versione tabella: 2 Logica generale Sincronizzazione degli utenti CRM Esportazione Esportazione di tutti i record effettivamente modificati (con dati variati). Importazione Per il momento è prevista solo l'aggiornamento di alcune informazioni sul web. 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: APUTENTI Se fallita inviare una Segnalazione critica e chiudere. C - Importazione aggiornamenti Effettuare una query per estrarre tutti gli elementi aggiornati su APP: SELECT * FROM APUTENTI WHERE a_ute_azienda = azienda AND (a_ute_agg_app = 'A') Gli elementi potranno essere: * Cancellati: se A-UTE-FL-CANC = "C" * Inseriti o aggiornati: se A-UTE-FL-CANC <> "C" Per il momento consideriamo solo l'aggiornamento di elementi esistenti e non cancellati Quindi, scartare se A_UTE_FL_CANC = 'C' o 'S' C.1 - Importazione elemento nuovo o aggiornato Fare una ricerca su PRNTOPER impostando:
| Dato | Contenuto |
|---|---|
| PTOP-COD | A-UTE-COD |
Se il record non esiste su PRNTOPER, skippare l'elaborazione. Quindi proseguire con l'aggiornamento di: PRNTOPE2 (inserire se non esiste).
| Dato | Contenuto |
|---|---|
| PTO2-EMAIL | A-UTE-EMAIL |
C.2 - Importazione elemento cancellato Non previsto C.3 - Aggiornamento record APUTENTI Al termine, in qualunque caso, anche se il record è stato ignorato, aggiornarlo impostando A-UTE-AGG-APP = ' ' 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 "APUTENTI"; se il record non esiste, crearlo impostando
| Dato | Contenuto |
|---|---|
| A-SYN-AZIENDA | Codice azienda |
| A-SYN-TABELLA | "APUTENTI" |
| 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à PTOP-CHIA1) |
Si legge direttamente il record da aggiornare su PRNTOPER 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 PRNTOPER; ogni record va considerato, ignorando il controllo sulla variazione dei record |
| Esportazione standard | Si scorrono tutti i record di PRNTOPER, si considerano solo quelli con data/ora aggiornamento superiore all'ultima effettuata | |
| 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: * PRNTOPE2 * CRMUSERS B.2.2 Verifica ed esportazione record Dopodichè si effettua la ricerca dell'informazione su APUTENTI
| Dato | Contenuto |
|---|---|
| A-UTE-AZIENDA | Codice azienda |
| A-UTE-COD | PTOP-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 PRNTOPER NB: se a questo punto A-UTE-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-UTE-AZI | Codice azienda | |
| A-UTE-COD | PTOP-COD | |
| A-UTE-DES | PTOP-DES (*) | Si |
| A-UTE-PROFILO | PTOP-PROF | Si |
| A-UTE-AGENTE | PTOP-AGE | Si |
| A-UTE-FL-AMM | PTOP-FL-AMM | Si |
| A-UTE-REPARTO | PTOP-REPARTO | Si |
| A-UTE-SOTTOREPARTO | PTOP-SOTTOREPARTO | Si |
| A-UTE-EMAIL | PTO2-EMAIL | Si |
| A-UTE-SMS | PTO2-SMS | Si |
| A-UTE-DIVISIONE | PTO2-DIVISIONE | Si |
| A-UTE-MAG | PTO2-MAG | Si |
| A-UTE-ZONA | PTO2-ZONA | Si |
| A-UTE-CRM-LIV | CRU-LIV | Si |
| A-UTE-VIS-FOR | CRU-VIS-FOR | Si |
| A-UTE-VIS-CLI | CRU-VIS-CLI | Si |
| A-UTE-VIS-ALT | CRU-VIS-ALT | Si |
| A-UTE-VIS-PROSPECT | CRU-VIS-PRO | Si |
| A-UTE-AMM-DOS | CRU-AMM-DOS | Si |
| A-UTE-SMS-NUOVO-APP | CRU-SMS-NUOVO-APP | Si |
| A-UTE-SMS-ALLARME | CRU-SMS-ALLARME | Si |
| A-UTE-AGGIORNATO | " " | |
| A-UTE-LINGUA | PTO2-LNG | Si |
| A-UTE-FL-CANC | PTOP-FL-VAL | Si |
| A-UTE-ID-SINCRO | Prossimo id sincro | |
| A-UTE-AGG-APP | " " |
In questa fase tenere memoria di data+ora dell'ultimo record di input considerato. Per i campi contrassegnati con (*) effettuare il parsing tramite GESSTR, come già fatto negli altri programmi di sincronizzazione B.3 Verifica record cancellati Sulla tabella di origine PRNTOPER esiste il flag di cancellazione logica ma è anche possibile la cancellazione fisica. Quindi si opererà come segue: 1. Scorrere tutti i record di APUTENTI per l'azienda 2. Ricerca, per ciascuno, del corrispondente record su PRNTOPER A questo punto la situazione potrebbe essere la seguente:
| PRNTOPER trovato? | A-UTE-FL-CANC | Cosa fare |
|---|---|---|
| Si | "C" | Tralasciamo questo caso, dovrebbe essere gestito già nei giri di esportazione standard |
| Si | " " | |
| No | "C" | Nessuna operazione |
| No | " " | Aggiornare APUTENTI impostando |
B.9 - Aggiornamento id syncro Al termine dell'elaborazione, aggiornare il record APSTATOSYN:
| Dato | Contenuto |
|---|---|
| A-SYN-AZIENDA | Codice azienda |
| A-SYN-TABELLA | "APUTENTI" |
| 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 |
| A-SYN-VERSIONE | 2 |
Estratto da documentazione interna ClickUp
Storico modifiche¶
TASK-3547: protezione email esistente (aprile 2026)¶
Importazione (C.1): quando APUTENTI contiene una email (a-ute-email), questa viene copiata su PRNTOPE2 (pto2-email) solo se il campo locale e' vuoto. Prima veniva sempre sovrascritto, perdendo eventuali email impostate manualmente dall'operatore.
Esportazione: il campo tm-ute-email viene ora alimentato da a-ute-email solo se quest'ultimo e' significativo. Se AreaGate ha gia' un'email per quell'utente, viene preservata.