Logistica Remota - Z-LAB

AD HOC REVOLUTION
Modulo Logistica Remota
Logistica Remota
Modulo Logistica Remota
Release
Modulo
Funzionalità
del
AHR 5.0
Logistica Remota
Nuovo modulo
20/01/2006
Emissione:
Revisione
Data ultima
revisione
0
Approvazione:
Alessandro Uberti
Nicola Gorlandi
COPYRIGHT 2000 - 2006 by ZUCCHETTI S.p.A.
Tutti i diritti sono riservati. Questa pubblicazione contiene informazioni protette da copyright. Nessuna parte
di questa pubblicazione può essere riprodotta, trascritta o copiata senza il permesso dell’autore.
TRADEMARKS
Tutti i marchi di fabbrica sono di proprietà dei rispettivi detentori e vengono riconosciuti in questa
pubblicazione
ZUCCHETTI S.p.A.
Sede Operativa di Aulla
Centro Nuova Filanda snc – Aulla - MS
E-mail: [email protected]
Sito Web: http://www.zucchetti.it
Sommario
Premessa
1
Database Virtuale tra le sedi
1
Struttura collegamenti tra le sedi
1
Protocollo di Comunicazione
1
Sistema di Sincronizzazione
3
Attori di sincronizzazione
3
Ambito di Sincronizzazione
3
Nuove Tabelle del modulo
3
Validazione
4
Fase di Pubblicazione
5
Validazione dei records
5
Preparazione Files di Pubblicazione
5
Fase di Acquisizione
6
Logica di Importazione
6
Gestione dei conflitti di importazione
6
M O D U L O
L O G I S T I C A
R E M O T A
Premessa
Il modulo Logistica Remota consente di gestire installazioni di ad hoc Revolution distribuite
in sedi distinte, mediante un collegamento di tipo off-line (non in linea) on-demand (su
richiesta dell’utente) oppure schedulato, relativamente al flusso documentale e relative
anagrafiche collegate, clienti, fornitori, articoli di magazzino e saldi, situazione delle partite
aperte.
DATABASE VIRTUALE TRA LE SEDI
Sebbene ogni sede presenti una autonoma installazione di ad hoc Revolution, è possibile
pensare all’esistenza di un database virtuale costituito da un sottoinsieme di tutti i
database, filtrati in modo verticale (tabelle e campi sincronizzati) e orizzontale (records di
una tabella).
È così possibile implementare una sincronizzazione mantenendo specificità in ogni sede (ad
esempio diversi mastri di raggruppamento contabile dei clienti).
STRUTTURA COLLEGAMENTI TRA LE SEDI
La correttezza delle modifiche viene accertata dalla sede che funge da Validatore. La
modifica di un record deve necessariamente passare al Validatore affinché venga accettata
dall’intero sistema, e quindi sia modificabile nuovamente.
Si ipotizzi, ad esempio, il caricamento di un nuovo
(Validatore), che viene quindi inviato a tutti i negozi.
negozio siano accettate dal sistema, devono essere
sede centrale prima di eventuali modifiche da parte di
articolo da parte della sede centrale
Affinché le modifiche effettuate da un
necessariamente sincronizzate con la
altri negozi.
Il gruppo delle sedi avrà probabilmente una struttura a stella, con collegamenti da e verso
la sede centrale di tutte le sedi periferiche. È comunque possibile implementare anche una
struttura a grafo, ove più sedi possono essere “proprietarie” dei dati (più Validatore per
insiemi non sovrapposti di records).
PROTOCOLLO DI COMUNICAZIONE
Il protocollo di comunicazione tra le sedi si compone dei seguenti strati (partendo dal più
alto):
¾
Scambio di files contenenti i reciproci inserimenti, aggiornamento o cancellazioni
delle entità sincronizzate (articoli di magazzino, clienti, fornitori, documenti ecc.);
¾
Rete V.P.N. (Virtual Private Networking), mediante la creazione di un tunnel privato
di una rete pubblica;
¾
Rete pubblica Internet oppure collegamento diretto (anche telefonico commutato).
La sede che apre la connessione (anche in modo schedulato) fungerà sia da pubblicatore per
le variazioni apportate dalla stessa, sia da ricevente delle variazioni della controparte.
1
M O D U L O
L O G I S T I C A
All’interno di una
sincronizzazione:
R E M O T A
stessa
connessione
si
configurano
perciò
due
distinte
fasi
di
¾
Fase di Pubblicazione: il file con le variazioni prodotte localmente viene copiato nella
opportuna cartella della sede ricevente, in modo che quest’ultimo possa aggiornare il
proprio database;
¾
Fase di Acquisizione: viene letto il file con le variazioni prodotte dalla sede remota
presente nella opportuna cartella creata dal pubblicatore per ciascun ricevente, per
l’aggiornamento del database locale.
Relativamente ad un certa sede, le cartelle di origine e di destinazione possono essere
indifferentemente locali o remote:
¾
Entrambe le cartelle remote: la sede in oggetto si preoccupa di aprire la connessione
e del trasferimento fisico dei files;
¾
Entrambe le cartelle locali: l’apertura della connessione e del trasferimento fisico dei
files è di responsabilità delle altre sedi (la sede in oggetto sincronizza files già
disponibili localmente).
2
M O D U L O
L O G I S T I C A
R E M O T A
1
Capitolo
Sistema di Sincronizzazione
ATTORI DI SINCRONIZZAZIONE
¾
Pubblicatore: è la sede che durante un certo processo di sincronizzazione si occupa
dell’invio dei dati verso un’altra sede (detta Ricevente);
¾
Ricevente: è la sede che durante un certo processo di sincronizzazione riceve i dati
da una sede Pubblicatore per l’aggiornamento del database locale.
¾
Validatore: è la sede che effettua un controllo di coerenza durante l’importazione
rispetto ad un certo insieme di records; in definitiva è la sede che ha la proprietà di
un record, anche in presenza di modifiche avvenute in modo distribuito.
AMBITO DI SINCRONIZZAZIONE
L’insieme dei dati che vengono pubblicati dipende da una combinazione dei seguenti
elementi:
¾
Entità: tabelle che vengono sincronizzate
¾
Riceventi: sedi a cui sono rivolti i dati
¾
Filtro Verticale: campi da escludere relativi ad una certa tabella (ad esempio il
sottoconto studio sui clienti)
¾
Filtro Orizzontale: record da filtrare (ad esempio un insieme di magazzini per i quali
non sincronizzare il saldo)
NUOVE TABELLE DEL MODULO
¾
¾
Una tabella Mirror per ciascuna tabella che può essere oggetto di sincronizzazione,
con i seguenti campi:
o
Chiave (uno o più campi a seconda della tabella principale);
o
Ancestor: CPCCCHK assegnato dal Validatore
o
Codice Sede Pubblicatore
o
CPCCCHK dell’ultima pubblicazione
Parametri generali:
o
Codice Sede: 2 caratteri da utilizzare come prefisso per i seriali dei
documenti e dei movimenti di magazzino
3
M O D U L O
¾
¾
L O G I S T I C A
R E M O T A
o
Dettaglio Riceventi (codificati con le 2 cifre suindicati), con un dettaglio figlio
relativo alle Entità da pubblicare e per ciascuna l’elenco dei filtri verticali
(campi da escludere con default) e l’espressione del filtro orizzontale
(record da scartare). Per ciascun ricevente è possibile definire un recapito I.P.
o telefonico per l’apertura della connessione.
o
Dettaglio Pubblicatori, con sottodettaglio delle tabelle da importare e per
ciascuna l’elenco dei filtri verticali (campi da escludere con default) con
relativo ultimo progressivo importato. Per ciascun pubblicatore è possibile
definire un recapito I.P. o telefonico per l’apertura della connessione.
Tabella con le entità oggetto di sincronizzazione, da caricare con una procedura
di importazione (Carica/Salva Dati Esterni). Di fatto è un insieme cablato in una certa
versione del gestionale. Per ciascuna entità sono definite:
o
tutte le tabelle che la compongono con l’ordine di importazione
o
un’eventuale espressione di validazione, da utilizzarsi in fase di
pubblicazione per determinare i record sui quali la sede ha privilegi di
Validatore
o
un’eventuale routine di verifica integrità funzionale del dato (ad
esempio non deve essere permessa una reimportazione di una vendita
negozio per la quale siano già stati generati i documenti corrispettivi)
Nuovo flag sulle casuali documento che inabiliti la modifica del documento dalle sedi
che non lo hanno caricato
VALIDAZIONE
Possono essere definiti dei filtri di validazione orizzontale per una certa sede (ad esempio i
clienti del nord potrebbero essere validati dalla sede di Milano e quelli del Centro/Sud da
quella di Roma) mediante una semplice espressione di Where. Se una sede deve validare
tutti i record di una tabella si imposterà (1=1), e contrariamente (1=0).
Per i Documenti, Movimenti di Magazzino e Vendite Negozio esiste un Validatore Intrinseco,
costituito dalla sede che ha caricato originariamente il movimento (codificata nei primi due
caratteri del seriale). È comunque sempre possibile specificare una diversa espressione di
validazione come per gli altri archivi.
4
M O D U L O
L O G I S T I C A
R E M O T A
2
Capitolo
Fase di Pubblicazione
Durante la fase di Pubblicazione sono esportati i record che presentano un CPCCCHK diverso
da quello presente nella tabella Mirror, rispetto all’ultima pubblicazione. Vengono esclusi i
record con CPCCCHK uguale all’Ancestor verso la sede di pubblicazione; in sintesi si evita di
reinviare i records non modificati direttamente verso la stessa sede che li ha pubblicati (e li
ha validati).
Le cancellazioni vengono
aggiunte/variazioni.
gestite
con
un
file
opportuno
distino
da
quello
delle
Una volta creati i files relativi a modifiche/inserimenti e cancellazioni (per ciascuna tabella
da esportare), viene aggiornato il record corrispondente nella tabella Mirror con il CPCCCHK
attuale, oppure cancellato il record se non più disponibile nella tabella principale.
VALIDAZIONE DEI RECORDS
Prima della dell’effettiva pubblicazione, il Validatore del record (in base all’espressione di
validazione specificata nei parametri) aggiorna anche il campo Ancestor presente nella
tabella Mirror con il CPCCCHK attuale. In sintesi convalida la nuova modifica del record,
definendo una nuova base di partenza.
I record nuovi presenteranno un Ancestor vuoto nel caso il pubblicatore non sia il
Validatore, e l’Ancestor uguale al CPCCCHK nel caso contrario.
PREPARAZIONE FILES DI PUBBLICAZIONE
I file di pubblicazione vengono numerati progressivamente e memorizzati in una directory
distinta per ciascun ricevente (ove deve essere possibile definire un numero massimo di
files oppure una dimensione massima, superata la quale avvengano cancellazioni
automatiche di quelli più vecchi).
Ogni file rappresenta gli inserimenti/modifiche/cancellazioni di una certa tabella rispetto al
momento dell’ultima pubblicazione (per un certo ricevente).
5
M O D U L O
L O G I S T I C A
R E M O T A
3
Capitolo
Fase di Acquisizione
Durante la fase di Acquisizione sono letti tutti i files di aggiornamento/inserimento o
cancellazione disponibili in una certa directory del pubblicatore (dedicata al ricevente), con
un progressivo superiore all’ultimo importato per una certa entità per ogni pubblicatore.
Se presente più di un files (a causa di un ritardo nella sincronizzazione oppure di una
tempificazione differenze tra le sedi), sarà effettuato un merge preliminare sui record (se lo
stesso record fosse presente in più files, sarà considerato solo quello contenuto nel files di
pubblicazione con progressivo più elevato).
LOGICA DI IMPORTAZIONE
L’importazione riguarda tutti i record che provengono direttamente dal Validatore, oppure
che sono stati distribuiti senza alcuna modifica dal momento di convalida. Il trattamento di
ogni record ricevuto è il seguente (verifiche ordinate):
¾
Record Nuovi: sempre importati
¾
CPCCCHK attuale = CPCCCHK inviato: non è necessario importarlo (già aggiornato)
¾
La sede di pubblicazione è il Validatore: sempre importati
¾
La sede di ricezione è il Validatore: saranno importati solo i record per i quali
CPCCCHK attuale = Ancestor inviato, ovvero la modifica del pubblicatore è stata
eseguita sulla stessa versione già validata
¾
La sede di pubblicazione e di ricezione non rappresentano il Validatore: possono
essere importati solo i records con CPCCCHK inviato = Ancestor inviato, che non
hanno subito modifiche dopo la validazione. Questi records non potranno però essere
modificati da parte del ricevente.
Ogni inserimento o modifica di un record importato è seguita da un aggiornamento del
campo Ancestor, presente nella tabella Mirror, con il CPCCCHK fornito dal pubblicatore.
È previsto un log dei records che non sono stati importati, in quanto non coerenti con le
modifiche locali.
GESTIONE DEI CONFLITTI DI IMPORTAZIONE
La gestione dei conflitti avviene a livello globale di entità: sono considerate le variazioni
della tabella principale e di ogni singola sotto-tabella. Ad esempio, la modifica ad una riga di
un ordine implica lo status di modificato a tutto il documento.
6
M O D U L O
L O G I S T I C A
R E M O T A
È comunque possibile prevedere funzioni che consentano di analizzare la possibilità di un
merge automatico tra variazioni riguardanti la stessa entità (ordine) purché siano
ammissibili in base alle business rules (ad esempio siano state variate righe differenti dello
stesso ordine).
7