Sincronizzazione anagrafiche

Quali dati vengono sincronizzati?

Vengono sincronizzati i dati relativi alle anagrafiche dei residenti (correnti e passati) e ai loro recapiti. I dati del database in cui viene avviata l'operazione sono quindi aggiornati, completati o sovrascritti dai dati provenienti dal database di origine, specificato nei parametri della maschera.

Come avviene il processo di sincronizzazione?

• Il processo avviene nelle seguenti fasi
  • Il chiamante invia la lista di anagrafiche per cui esiste una riga tra i riferimenti di importazione (AN1_TRASCO) con applicazione (SINCRO_ANAG). La prima volta che avviene la sincronizzazione questi dati devono essere inseriti manualmente con delle query.
  • Il server chiamato verifica nel suo archivio se i dati delle anagrafiche inviate sono diversi nel suo archivio e si tiene traccia di quali anagrafiche sono cambiate
  • Il chiamante chiede quindi l'esportazione di tutte le anagrafiche modificate e quelle nuove
  • Il server chiamato produce questi due gruppi di file di esportazione e li restituisce
  • Il chiamante avvia quindi 2 importazioni, la prima per le anagrafiche modificate e la seconda, accodata alla prima, di quelle nuove

Tutte le comunicazioni tra i due server avvengono tramite web-service, in realtà tramite un meccanismo più complesso descritto in seguito. Il processo di sincronizzazione può essere effettuato immediatamente o schedulato periodicamente.

Dettaglio tecnico del meccanismo di sincronizzazione

Il meccanismo descritto in precedenza si compone delle seguenti fasi, individuiamo con server "corrente" quello a cui si è attualmente collegati e con "chiamato" il server da cui si volgiono estrarre i dati.

• Invio al server chiamato della versione dell'algoritmo, il quale risponde con la sua, in modo da trovare la versione minima comune da utilizzare
• Il server corrente processa quindi tutte le anagrafiche per cui esiste una riga in AN1_TRASCO con applicazione un SINCRO_ANAG, in blocchi da n record, dove n è il parametro "Dimensione pagina di check" descritto nel seguito. Per ogni blocco di record si estraggono i campi significativi da sincronizzare, come il nome, il cognome, l'indirizzo, etc. e con questi si crea un checksum e poi si spedisce un blocco di checksum (opportunamente compresso), comprensivo di codice dell'anagrafica (preso da AN1_TRASCO), data inizio validità dell'anagrafica e del recapito di residenza
• Il chiamato prende questo blocco di anagrafiche, le processa una per una verificando il checksum e si segna se è diverso in una tabella di supporto (an1_sincro_anag_res). Se l'anagrafiche è di un non residente, allora verifica se le date di inizio validità sono successive a quelle passate, viceversa non esamina nemmeno il checksum: significa che il dato nel database corrente è più aggiornato rispetto al quello del "chiamato" ed essendo un non residente, non ha senso sincronizzarlo
• Finito il controllo dei checksum il server corrente chiama n volte l'altro server per farsi dare le anagrafiche modificate e nuove. Non potendo fare un'unica chiamata, perchè si incorre nel rischio di timeout del web-server, si fanno n chiamate per le anagrafiche modificate e m chiamate per quelle nuove. Il numero di chiamate dipende da quante anagrafiche sono da sincronizzare e quanto grande è un blocco di esportazione, specificato nel parametro "Dimensione pagina di export"
• Il server corrente, prende quindi tutti gli export prodotti nelle n+m chiamate li concatena in 2 gruppi di file e avvia 2 importazioni distinte (solamente per agevolarne la verifica): anagrafiche modificate e anagrafiche nuove. Le due importazioni avvengono con il normale iter di bonifica, con alcune lievi differenze:
  • In caso di riferimenti a consolati non esistenti, c'è un before-import che crea questi consolanti mancanti, in modo da non creare errori di validazione fastidiosi
  • Le anagrafiche dei residenti vengono importate come "In anagrafe", ma a fine import vengono spenti i flag "In anagrafe" in modo che sia possibile modificarli liberamente
  • Le anagrafiche già sincronizzate in precedenza, vengono ricercate per il codice presente in AN1_TRASCO quindi anche in caso di variazioni delle generalità saranno individuate, inoltre le righe presenti nella tabella temporanea di AN1_TRASCO, non vengono importate, ma sono collegate alle pre-esistenti

Meccanismi di debug

In modalità debug di s@w, nella maschera di configurazione della sincronizzazione compaiono degli altri campi, utili per debug:

• pkid anagrafe unica: impostare il codice di un'anagrafica in modo che il programma calcoli i 2 campi successivi
• Test per il checksum: viene valorizzato con i dati utilizzati per calcolare il checksum. Confrontanto questa stringa con quella che si ottiene collegandosi all'altro server, si capisce il motivo per cui un'anagrafica è stata sincronizzata o meno
• Checksum: è il checksum vero e proprio usato per il confronto. Se nei due server risulta diverso, le anagrafiche sono sincronizzate, viceversa no (salvo i casi dei non residenti, descritti sopra)

Parametri da configurare

• Per avviare la sincronizzazione bisogna impostare alcuni dati nella maschera:
  • URL: l'indirizzo HTTP del server da chiamare, che dovrà essere qualcosa del tipo http://INDIRIZZO_DEL_SERVER:PORTA_DI_TOMCAT/client/services/CmnWSSGateway, dove:
  • INDIRIZZO_DEL_SERVER è l'indirizzo del server in cui sta girando JBoss da cui si vogliono estrarre i dati (si può recuperare scaricando il jnlp che si usa per collegarsi all'altro server, facendo "salva oggetto con nome" o "salva destinazione con nome" sul link, e poi aprendo il jnlp con notepad si trova subito una riga del tipo <jnlp codebase="http://INDIRIZZO_DEL_SERVER)
  • PORTA_DI_TOMCAT è la porta HTTP in cui gira Tomcat (non Apache). Non è la porta che si trova nel JNLP, che è quella di Apache, ma quella che si trova scritta nel file \jboss-3.2.5\server\default\deploy\jbossweb-tomcat50.sar\server.xml cercando <Connector port="XXX" ... Tipicamente è la 50080, (si recupera dal precedente JNLP dal primo tag <argument>jboss:INDIRIZZO_DEL_SERVER:PORTA_TOMCAT:PORTA_RMI</argument> il valore che si trova qui come 3° elemento dovrebbe essere quello che ci serve)
  • J2EE user: utente J2EE del server da cui estrarre i dati (si recupera dal precedente JNLP dal tag <argument>J2EE_USER</argument>, solitamente il 2° tag <argument>)
  • J2EE password: password dell'utente J2EE del server da cui estrarre i dati
  • sicraweb username: nome di un utente di s@w del server da cui estrarrei i dati
  • sicraweb password: password di un utente di s@w del server da cui estrarrei i dati
  • Dimensione pagina di check: abbassare il valore proposto se a causa della lentezza del sever chiamato la risposta supera il tempo di timeout del web-server (durante la prima fase)
  • Dimensione pagina di export: abbassare il valore proposto se a causa della lentezza del sever chiamato la risposta supera il tempo di timeout del web-server (durante la seconda fase)

• Pulsante di verifica dei parametri di configurazione: permette di verificare se i parametri sopra impostati sono corretti, facendo un collegamento con l'altro server, e verificandone la risposta. Non schedulare l'avvio della sincronizzazione se non si verificano prima i parametri

• Schedulazione: è possibile impostare una schedulazione sia periodica, che una tantum. Se non si specifica alcun tipo di schedulazione al momento in cui si preme il pulsante schedula, si la sincronizzazione parte immediatamente (dopo opportuno messaggio di conferma)

Quali operazioni vanno fatte prima di avviare la sincronizzazione?

Affichè il processo di sincronizzazione funzioni sono necessarie le seguenti caratteristiche:

• Non devono esserci consolati con codice istat duplicato nel database corrente (controllato in automatico all'avvio del sincronismo)
• Non devono esserci anagrafiche con recapiti di residenza doppi, come da apposita diagnostica, nel database corrente (controllato in automatico all'avvio del sincronismo)
• La prima volta deve essere valorizzata la tabella AN1_TRASCO con opportuno script da realizzare di volta in volta