AD HOC REVOLUTION. Modulo Logistica Remota. Logistica Remota

Transcript

1 AD HOC REVOLUTION Mdul Lgistica Remta Lgistica Remta

2 Mdul Lgistica Remta Release Mdul Funzinalità del Revisine Data ultima revisine AHR 5.0 Lgistica Remta Nuv mdul 20/01/ Emissine: Alessandr Uberti Nicla Grlandi Apprvazine: COPYRIGHT by ZUCCHETTI S.p.A. Tutti i diritti sn riservati. Questa pubblicazine cntiene infrmazini prtette da cpyright. Nessuna parte di questa pubblicazine può essere riprdtta, trascritta cpiata senza il permess dell autre. TRADEMARKS Tutti i marchi di fabbrica sn di prprietà dei rispettivi detentri e vengn ricnsciuti in questa pubblicazine ZUCCHETTI S.p.A. Sede Operativa di Aulla Centr Nuva Filanda snc Aulla - MS market@zucchetti.it Sit Web:

3 Smmari Premessa 1 Database Virtuale tra le sedi 1 Struttura cllegamenti tra le sedi 1 Prtcll di Cmunicazine 1 Sistema di Sincrnizzazine 3 Attri di sincrnizzazine 3 Ambit di Sincrnizzazine 3 Nuve Tabelle del mdul 3 Validazine 4 Fase di Pubblicazine 5 Validazine dei recrds 5 Preparazine Files di Pubblicazine 5 Fase di Acquisizine 6 Lgica di Imprtazine 6 Gestine dei cnflitti di imprtazine 6

4 Premessa Il mdul Lgistica Remta cnsente di gestire installazini di ad hc Revlutin distribuite in sedi distinte, mediante un cllegament di tip ff-line (nn in linea) n-demand (su richiesta dell utente) ppure schedulat, relativamente al fluss dcumentale e relative anagrafiche cllegate, clienti, frnitri, articli di magazzin e saldi, situazine delle partite aperte. DATABASE VIRTUALE TRA LE SEDI Sebbene gni sede presenti una autnma installazine di ad hc Revlutin, è pssibile pensare all esistenza di un database virtuale cstituit da un sttinsieme di tutti i database, filtrati in md verticale (tabelle e campi sincrnizzati) e rizzntale (recrds di una tabella). È csì pssibile implementare una sincrnizzazine mantenend specificità in gni sede (ad esempi diversi mastri di raggruppament cntabile dei clienti). STRUTTURA COLLEGAMENTI TRA LE SEDI La crrettezza delle mdifiche viene accertata dalla sede che funge da Validatre. La mdifica di un recrd deve necessariamente passare al Validatre affinché venga accettata dall inter sistema, e quindi sia mdificabile nuvamente. Si iptizzi, ad esempi, il caricament di un nuv articl da parte della sede centrale (Validatre), che viene quindi inviat a tutti i negzi. Affinché le mdifiche effettuate da un negzi sian accettate dal sistema, devn essere necessariamente sincrnizzate cn la sede centrale prima di eventuali mdifiche da parte di altri negzi. Il grupp delle sedi avrà prbabilmente una struttura a stella, cn cllegamenti da e vers la sede centrale di tutte le sedi periferiche. È cmunque pssibile implementare anche una struttura a graf, ve più sedi pssn essere prprietarie dei dati (più Validatre per insiemi nn svrappsti di recrds). PROTOCOLLO DI COMUNICAZIONE Il prtcll di cmunicazine tra le sedi si cmpne dei seguenti strati (partend dal più alt): Scambi di files cntenenti i reciprci inserimenti, aggirnament cancellazini delle entità sincrnizzate (articli di magazzin, clienti, frnitri, dcumenti ecc.); Rete V.P.N. (Virtual Private Netwrking), mediante la creazine di un tunnel privat di una rete pubblica; Rete pubblica Internet ppure cllegament dirett (anche telefnic cmmutat). La sede che apre la cnnessine (anche in md schedulat) fungerà sia da pubblicatre per le variazini apprtate dalla stessa, sia da ricevente delle variazini della cntrparte. 1

5 All intern di una stessa cnnessine si cnfiguran perciò due distinte fasi di sincrnizzazine: Fase di Pubblicazine: il file cn le variazini prdtte lcalmente viene cpiat nella pprtuna cartella della sede ricevente, in md che quest ultim pssa aggirnare il prpri database; Fase di Acquisizine: viene lett il file cn le variazini prdtte dalla sede remta presente nella pprtuna cartella creata dal pubblicatre per ciascun ricevente, per l aggirnament del database lcale. Relativamente ad un certa sede, le cartelle di rigine e di destinazine pssn essere indifferentemente lcali remte: Entrambe le cartelle remte: la sede in ggett si preccupa di aprire la cnnessine e del trasferiment fisic dei files; Entrambe le cartelle lcali: l apertura della cnnessine e del trasferiment fisic dei files è di respnsabilità delle altre sedi (la sede in ggett sincrnizza files già dispnibili lcalmente). 2

6 Capitl 1 Sistema di Sincrnizzazine ATTORI DI SINCRONIZZAZIONE Pubblicatre: è la sede che durante un cert prcess di sincrnizzazine si ccupa dell invi dei dati vers un altra sede (detta Ricevente); Ricevente: è la sede che durante un cert prcess di sincrnizzazine riceve i dati da una sede Pubblicatre per l aggirnament del database lcale. Validatre: è la sede che effettua un cntrll di cerenza durante l imprtazine rispett ad un cert insieme di recrds; in definitiva è la sede che ha la prprietà di un recrd, anche in presenza di mdifiche avvenute in md distribuit. AMBITO DI SINCRONIZZAZIONE L insieme dei dati che vengn pubblicati dipende da una cmbinazine dei seguenti elementi: Entità: tabelle che vengn sincrnizzate Riceventi: sedi a cui sn rivlti i dati Filtr Verticale: campi da escludere relativi ad una certa tabella (ad esempi il sttcnt studi sui clienti) Filtr Orizzntale: recrd da filtrare (ad esempi un insieme di magazzini per i quali nn sincrnizzare il sald) NUOVE TABELLE DEL MODULO Una tabella Mirrr per ciascuna tabella che può essere ggett di sincrnizzazine, cn i seguenti campi: Chiave (un più campi a secnda della tabella principale); Ancestr: CPCCCHK assegnat dal Validatre Cdice Sede Pubblicatre CPCCCHK dell ultima pubblicazine Parametri generali: Cdice Sede: 2 caratteri da utilizzare cme prefiss per i seriali dei dcumenti e dei mvimenti di magazzin 3

7 Dettagli Riceventi (cdificati cn le 2 cifre suindicati), cn un dettagli figli relativ alle Entità da pubblicare e per ciascuna l elenc dei filtri verticali (campi da escludere cn default) e l espressine del filtr rizzntale (recrd da scartare). Per ciascun ricevente è pssibile definire un recapit I.P. telefnic per l apertura della cnnessine. Dettagli Pubblicatri, cn sttdettagli delle tabelle da imprtare e per ciascuna l elenc dei filtri verticali (campi da escludere cn default) cn relativ ultim prgressiv imprtat. Per ciascun pubblicatre è pssibile definire un recapit I.P. telefnic per l apertura della cnnessine. Tabella cn le entità ggett di sincrnizzazine, da caricare cn una prcedura di imprtazine (Carica/Salva Dati Esterni). Di fatt è un insieme cablat in una certa versine del gestinale. Per ciascuna entità sn definite: tutte le tabelle che la cmpngn cn l rdine di imprtazine un eventuale espressine di validazine, da utilizzarsi in fase di pubblicazine per determinare i recrd sui quali la sede ha privilegi di Validatre un eventuale rutine di verifica integrità funzinale del dat (ad esempi nn deve essere permessa una reimprtazine di una vendita negzi per la quale sian già stati generati i dcumenti crrispettivi) Nuv flag sulle casuali dcument che inabiliti la mdifica del dcument dalle sedi che nn l hann caricat VALIDAZIONE Pssn essere definiti dei filtri di validazine rizzntale per una certa sede (ad esempi i clienti del nrd ptrebber essere validati dalla sede di Milan e quelli del Centr/Sud da quella di Rma) mediante una semplice espressine di Where. Se una sede deve validare tutti i recrd di una tabella si impsterà (1=1), e cntrariamente (1=0). Per i Dcumenti, Mvimenti di Magazzin e Vendite Negzi esiste un Validatre Intrinsec, cstituit dalla sede che ha caricat riginariamente il mviment (cdificata nei primi due caratteri del seriale). È cmunque sempre pssibile specificare una diversa espressine di validazine cme per gli altri archivi. 4

8 Capitl 2 Fase di Pubblicazine Durante la fase di Pubblicazine sn esprtati i recrd che presentan un CPCCCHK divers da quell presente nella tabella Mirrr, rispett all ultima pubblicazine. Vengn esclusi i recrd cn CPCCCHK uguale all Ancestr vers la sede di pubblicazine; in sintesi si evita di reinviare i recrds nn mdificati direttamente vers la stessa sede che li ha pubblicati (e li ha validati). Le cancellazini vengn gestite cn un file pprtun distin da quell delle aggiunte/variazini. Una vlta creati i files relativi a mdifiche/inserimenti e cancellazini (per ciascuna tabella da esprtare), viene aggirnat il recrd crrispndente nella tabella Mirrr cn il CPCCCHK attuale, ppure cancellat il recrd se nn più dispnibile nella tabella principale. VALIDAZIONE DEI RECORDS Prima della dell effettiva pubblicazine, il Validatre del recrd (in base all espressine di validazine specificata nei parametri) aggirna anche il camp Ancestr presente nella tabella Mirrr cn il CPCCCHK attuale. In sintesi cnvalida la nuva mdifica del recrd, definend una nuva base di partenza. I recrd nuvi presenterann un Ancestr vut nel cas il pubblicatre nn sia il Validatre, e l Ancestr uguale al CPCCCHK nel cas cntrari. PREPARAZIONE FILES DI PUBBLICAZIONE I file di pubblicazine vengn numerati prgressivamente e memrizzati in una directry distinta per ciascun ricevente (ve deve essere pssibile definire un numer massim di files ppure una dimensine massima, superata la quale avvengan cancellazini autmatiche di quelli più vecchi). Ogni file rappresenta gli inserimenti/mdifiche/cancellazini di una certa tabella rispett al mment dell ultima pubblicazine (per un cert ricevente). 5

9 Capitl 3 Fase di Acquisizine Durante la fase di Acquisizine sn letti tutti i files di aggirnament/inseriment cancellazine dispnibili in una certa directry del pubblicatre (dedicata al ricevente), cn un prgressiv superire all ultim imprtat per una certa entità per gni pubblicatre. Se presente più di un files (a causa di un ritard nella sincrnizzazine ppure di una tempificazine differenze tra le sedi), sarà effettuat un merge preliminare sui recrd (se l stess recrd fsse presente in più files, sarà cnsiderat sl quell cntenut nel files di pubblicazine cn prgressiv più elevat). LOGICA DI IMPORTAZIONE L imprtazine riguarda tutti i recrd che prvengn direttamente dal Validatre, ppure che sn stati distribuiti senza alcuna mdifica dal mment di cnvalida. Il trattament di gni recrd ricevut è il seguente (verifiche rdinate): Recrd Nuvi: sempre imprtati CPCCCHK attuale = CPCCCHK inviat: nn è necessari imprtarl (già aggirnat) La sede di pubblicazine è il Validatre: sempre imprtati La sede di ricezine è il Validatre: sarann imprtati sl i recrd per i quali CPCCCHK attuale = Ancestr inviat, vver la mdifica del pubblicatre è stata eseguita sulla stessa versine già validata La sede di pubblicazine e di ricezine nn rappresentan il Validatre: pssn essere imprtati sl i recrds cn CPCCCHK inviat = Ancestr inviat, che nn hann subit mdifiche dp la validazine. Questi recrds nn ptrann però essere mdificati da parte del ricevente. Ogni inseriment mdifica di un recrd imprtat è seguita da un aggirnament del camp Ancestr, presente nella tabella Mirrr, cn il CPCCCHK frnit dal pubblicatre. È previst un lg dei recrds che nn sn stati imprtati, in quant nn cerenti cn le mdifiche lcali. GESTIONE DEI CONFLITTI DI IMPORTAZIONE La gestine dei cnflitti avviene a livell glbale di entità: sn cnsiderate le variazini della tabella principale e di gni singla stt-tabella. Ad esempi, la mdifica ad una riga di un rdine implica l status di mdificat a tutt il dcument. 6

10 È cmunque pssibile prevedere funzini che cnsentan di analizzare la pssibilità di un merge autmatic tra variazini riguardanti la stessa entità (rdine) purché sian ammissibili in base alle business rules (ad esempi sian state variate righe differenti dell stess rdine). 7