Procedure di migrazione automatizzate

Eliminazione finale delle tabelle di movimentazione

Questa fase corrisponde all'inizio del travaso. A questo stadio occorre arrestare l'operatività della soluzione: riprenderà quando la migrazione sarà terminata.

E' possibile distinguere 4 sottofasi in questa fase:

• estrazione dei dati del dossier da migrare:
• tramite estrazione dei dati in formato "flat" per i dossier piccoli. Per fare ciò, si utilizzerà la funzione di estrazione che crea i file nella directory SVG di default.
• tramite estrazione del database quando i volumi sono maggiori (il formato allora dipende dal database e dal tool utilizzato)
• copia dei file del dossier da migrare nella soluzione V6,
• creazione di una directory copia della struttura del dossier nel nuovo ambiente della versione 6 ed import dei dati esportati nel nuovo ambiente.
• creazione della scheda dossier nell'ambiente V6. Se l'import avviene tramite console, la scheda dossier viene creata automaticamente, ma se si effettua l'import con strumenti database, bisognerà creare la scheda dossier manualmente dopo l'import.

 Adesso è possibile raggruppare queste fasi in una sola. Per fare ciò ocorre utilizzare il wizard diimport remotoproposto nella console di configurazione SAFE X3.

Se necessario, si rettificheranno in seguito i valori dei codici attività nella scheda dossier, ad esempio per attivare nuove funzionalità controllate da nuovi codici attività.La modifica della scheda dossier, o la sua creazione, si effettuerà collegandosi al dossier "supervisore" (X3 nel caso di Sage X3).

Esempio di sequenza

La rivalidazione del dossier trasformerà la struttura del dizionario X3, poi delle tabelle di parametrizzazione, poi delle tabelle di dati, della versione 140 o 5 per portarle a livello della V6, trasferendo i dati nel passaggio. Si attiva premendo il bottone Validazionedalla gestione dossier.

Effettua la migrazione supervisore e funzionale del dossier, confrontando il dizionario della nuova versione ed il dizionario della versione a migrare.

Principali fasi della rivalidazione

La rivalidazione di dossier concatena le seguenti fasi sul dossier da migrare:

• cancelllazione di alcune tabelle temporanee o di totali, la cui ricostituzione avverrà nelle ulteriori fasi. Le tabelle supervisore interessate da questa cancellazione sono le seguenti:
      ALSTRD
      ALISTER
      AWRKLOG
      AWRKLOGIND
      AWRKLOGMES
      ATMPTRA
  Vengono inoltre cancellate altre tabelle temporanee funzionali (nel caso di Sage X3, le tabelle sono: LABELPRN, PRTSCRWRK, BALANCE, BALANA, GLCONSO, BALCONSO, GAJOUSTA, FUP, FUPTOT, BATCH, TMPEXPENSE).
• migrazione del pacchetto, vale a dire del dizionario di dati e delle tabelle del supervisore necessarie al funzionamento di base (connessione, gestione degli utenti, ambiente di sviluppo e di parametrizzazione minima). A partire dal momento in cui viene effettuata questa migrazione, una connessione è teoricamente possibile, anche se le tabelle che contengono i dati applicativi di flusso sono per il momento vuote.
• migrazione funzionale: per ogni tabella la cui struttura cambia, la procedura effettuerà le modifiche necessarie, fornendo all'occorrenza dei valori di default conformi, tramite procedure concatenate in fasi e sottofasi. E' questo il momento più lungo della migrazione, in funzione del volume di dati da migrare.
• Programma di post-migrazione (si tratta essenzialmente delle risincronizzazioni di tabelle di totali). Alcune di queste fasi possono essere batch per poter riprendere l'utilizzo del prodotto, a scapito di un funzionamento meno performante dell'applicativo nella sottofase intermedia . Per poter considerare la migrazione come terminata, bisognerà che queste siano state lanciate.
• cancellazione finale delle tabelle temporanee. Questa fase è manuale e potrà, per ragioni di sicurezza, essere rinviata fino a quando non si sarà più che sicuri che tutti i dati di flusso siano stati correttamente migrati.

Utilizzo di piani di migrazione

Questa migrazione funzionale può essere molto lunga quando il dossier è molto voluminoso. Inoltre, alcune delle tabelle aggiornate sono potenzialmente indipendenti, e potrebbero quindi essere migrate in parallelo, approfittando di architetture multi-processori per accellerare tale sotto-fase.

Per permettere di pianificare al meglio questa migrazione, si potrà definire PRIMA di lanciare la validazione dei dati un piano di migrazione personalizzato. Questo piano di migrazione è descritto dalla funzione chiamata procedura di migrazione (richiamabile dal dossier supervisore). Questa funzione permette di definire le fasi, le sotto-fasi e le procedure della migrazione funzionale e supervisore. Più precisamente, un piano di migrazione corrisponde ad una definizione dei parametri esatti della migrazione (dossier interessato, numero di procedure che possono essere parallelizzate, politica di concatenamento dei job, stato di esecuzione). Un piano di migrazione viene creato copiando tutti gli elementi attivi della procedura di migrazione. Questo insieme completo di procedure viene fornito in standard, permettendo di concatenare in maniera completa le elaborazioni effettuate dal software standard nella fase di migrazione. La descrizione succinta di queste procedure è descritta in un documento dedicato.

E' possibile, a questo stadio, definire delle procedure specifiche scrivendo dei programmi complementari coerentemente con la metodologia definita nell'allegato seguente. Queste procedure specifiche verranno inserite tra le procedure standard in maniera appropriata.

Definito un piano di migrazione è possibile, da questo piano, procedere al suo lancio, alla sua interruzione temporanea, alla ripresa della sua esecuzione, alla visualizzazione del suo stato di avanzamento.

Quando un dossier ha un volume ragionevole, la cui migrazione non necessita di particolare pianificazione, è inutile creare un piano di migrazione. Infatti, in assenza di piano di migrazione definito, l'operazione di validazione del dossier creerà automaticamente un piano di migrazione. Questo piano di migrazione avrà come codice quello del dossier, salvo tale codice corrisponda già ad un piano di migrazione che non sia in stato In attesa. Se questo fosse il caso, il piano sarebbe creato con un codice predefinito nel formato MIGmmddM##, dove mme ddsono i numeri del mese e del giorno di lancio, ## è il numero sequenziale.

Al contrario, se si desidera personalizzare le opzioni di concatenamento di migrazione, si potrà creare un piano di migrazione il cui codice corrisponde al nome del dossier. Tale creazione sarà effettuata nel dossier supervisore prima del lancio della validazione dossier. Non appena è presente un tale piano di migrazione con lo stato In attesa, questo verrà utilizzato per la migrazione funzionale del dossier.

Nota : Un piano creato con un nome diverso dal nome del dossier da migrare non verrà mai utilizzato dagli automatismi della validazione di dossier. Un tale piano è riservato ad un lancio manuale.

Svolgimento delle operazioni in un piano di migrazione

Un piano di migrazione è caratterizzato da un codice dossier e da 4 parametri:

• una descrizione indicativa.
• il numero di procedure che possono essere lanciate simultaneamente. Questo numero costituisce un possibile massimo. Verranno lanciate simultaneamente soltanto le procedure parallelizzabili. Attenzione, questo numero è limitato dal numero di job batch che possono essere eseguiti simultaneamente (definiti nella funzione di parametrizzazione del server batch), a sua volta limitato dalla licenza di utilizzo.
• Un flag che indica se le procedure debbano essere lanciate automaticamente concatenandosi a seconda della logica definita dal piano. Se questo non è il caso, il concatenamento delle procedure descritte nel piano dovrà essere effettuato manualmente.
• Un flag che segnala se le procedure post-migrazione debbano essere concatenate alla migrazione stessa. Queste operazioni sono descritte qui di seguito.

Se il piano di migrazione viene creato di default alla rivalidazione del dossier, viene creato con i valori:

• Numero di job simultaneicon il valore del parametro NBRTACSIM o (se non esiste) con il valore 2,
• concatenamento automatico a Si
• Operazioni post-migrazione a Sì.

All'utente sarà sempre permesso modificare questi valori dalla funzione di controllo del piano di migrazione.

Sulla videata associata al piano di migrazione si trova l'elenco ordinato delle procedure del piano. Dei bottoni permetteranno di controllare l'intera esecuzione del piano:

• lanciandone l'esecuzione.
• sospendendo il lancio di nuove procedure.
• interrompendo tutte le procedure in corso.
• rilanciandone l'esecuzione.

Ogni riga del piano consiste in una fase dell'esecuzione, caratterizzata da:

• il codice della procedura e la sua descrizione.
• la fase e la sotto-fase di cui fa parte la procedura.
• il modulo funzionale al quale è collegata la procedura.
• la sequenza di esecuzione.

Le fasi della migrazione permettono di suddividere la migrazione funzionale. Fino a quando non è terminata almeno una procedura legata ad una determinata sotto-fase, le sotto-fasi successive non possono essere lanciate. Le sotto-fasi vengono collegate alle seguenti fasi:

• La fase d'inizializzazione è una fase preliminare che viene eseguita prima di tutto. Ad oggi non viene utilizzata e permette di far eseguire procedure specifiche prima della migrazione stessa.
• La fase di modulo base permette di migrare dei dati utilizzati dalle fasi successive.
• La fase modulo permette di realizzare le migrazioni legate ad ogni modulo funzionale. Un'operazione di questa fase viene associata ad un modulo funzionale: tale associazione è puramente documentale, e non vincola l'esecuzione. Possono così essere eseguite in parallelo delle migrazioni di dati legate a moduli diversi, se queste sono nella medesima sotto-fase. Il loro lancio si effettuerà nell'ordine dei moduli, poi in ordine della posizione di esecuzione.
• La fase post-migrazione permette di effettuare delle operazioni di sincronizzazione o degli aggiornamenti secondari la cui esecuzione non è obbligatoria per ricominciare a funzionare in modalità ottimale. Può essere utilizzata ad esempio per diversificare migrazioni di vecchi dati. Occorre tuttavia notare che, anche se non è obbligatoria per riprendere l'utilizzo, dovrà ugualmente essere effettuata ulteriormente affinché lo stato di un dossier sia considerato come completamente migrato. Queste operazioni di post-migrazione vengono lanciate di default in un piano di migrazione, ma è possibile metterle in pausa. Sono elencate in un paragrafo dedicatodell'allegato che descrive le procedure di migrazione.

In una fase, si trovano delle procedure singole organizzate in sotto-fasi e in sequenze:

• Due procedure definite nella stessa sotto-fase vengono considerate come eseguibili simultaneamente, e devono quindi essere indipendenti. L'assegnazione di una procedura standard ad una determinata sotto-fase non può essere cambiata. Fino a quando tutte le procedure di una sotto-fase non sono terminate, la successiva sotto-fase non può essere lanciata.
• L'ordine di sequenza è semplicemente un ordine preferenziale di lancio, ma può essere cambiato, incluse le procedure standard, al momento della definizione del piano.

Eliminazione finale delle tabelle di movimentazione

Questa sotto-fase è manuale. Sarà attivata dall'esecuzione del programma TRTMIGDEL dalla funzione di esecuzione del programma. La sua esecuzione provoca la cancellazione di tutte le tabelle sottomesse al codice attività MIG.

Poiché questa fase è irreversibile, è importante innanzitutto assicurarsi che i programmi di migrazione siano stati eseguiti correttamente.

Nella misura in cui il fatto di mantenere le tabelle temporanee nel dossier non costituisca un ostacolo alla normale ripresa dell'utilizzo (ciò presuppone ben inteso di disporre di sufficiente spazio su disco), viene permesso il mantenimento di tali tabelle on-line dopo qualche settimana di utilizzo. Si potrà così disporre, in caso di problema riscontrato qualche settimana dopo la migrazione, dei dati di origine a scopo di confronto o di analisi.

Esempio di sequenza sulla migrazione dei flussi

Si supponga di avere le seguenti operazioni:

• nella fase inizializzazione, 7 operazioni:
• IN1, IN2 nella sotto-fase 1 (con sequenza 3 e 7),
• IN3 e IN4, IN5 e IN6 nella sotto-fase 2 (e di sequenze successive 1 3, 5 9),
• IN7 nella sotto-fase 3,
• nella fase modulo base, 6 operazioni:
• TC1, TC2, TC3, tutte e 3 nella fase 1, con sequenze 3, 6, 9,
• TC4 nella sotto-fase 2,
• TC5 e TC6 nella sotto-fase 3,
• nella fase Modulo, 5 operazioni
• la fase MO1, nel modulo Contabilità,con sotto-fase 2 e sequenza 1,
• le fasi MO2 e MO3, nel modulo Stock, nelle rispettive fasi 1 e 2, con le rispettive sequenze 1 e 2,
• le fasi MO4 e MO5, nel modulo Vendite, con rispettive sotto-fasi 1 e 2, sequenza 1,
• le fasi MO6 e MO7, nel modulo, nel modulo Acquisti, con le rispettive sotto-fasi 1 e 5, con delle sequenze 1.

Si supponga ora che il piano di migrazione venga lanciato con un concatenamento dei job e che girino simultaneamente un numero massimo di 2 procedure. Il concatenamento potrebbe quindi essere il seguente:

• Le procedure IN1 e IN2 sono lanciate in questo ordine.
• Si supponga che la procedura IN2 termini per prima. Fin quando la procedura IN1 non viene completata, non ne sarà lanciata nessun altra, poiché le procedure successive sono in una sotto-fase o una fase di sequenza superiore.
• quando la procedura IN1 sarà terminata, le procedure IN3 e IN4 saranno lanciate nell'ordine.
• Se la procedura IN4 termina prima della procedura IN3, verrà lanciata la procedura IN5. Se quest'ultima termina prima della IN3, verrà lanciata la procedura IN6 e girerà contemporaneamente alla procedura IN3.
• Quando entrambe le procedure IN3 e IN6 saranno terminate (e soltanto in quel momento), la fase di inizializzazione sarà completata.
• Sarà allora possibile lanciare le procedure della prima sotto-fase della fase Modulo Base: dapprima le procedure TC1 e TC2, poi TC3, che verrà lanciata non appena una delle due procedure precedenti sia terminata. Si attenderà che le tre procedure TC1, TC2, TC3 siano tutte terminate per lanciare TC4, che girerà da sola poiché non vi sono altre procedure in questa sotto-fase. In seguito, si lancerà TC5 e TC6 che gireranno in parallelo.
• Quando le procedure TC5 e TC6 saranno entrambe terminate, si potrà passare ai job della fase moduli.
• Si lanceranno prima le procedure MO2, poi MO6 (nell'ordine, in quanto queste procedure girano in parallelo); poi, non appena una delle procedure MO2 e MO6 sarà terminata, la procedura MO4, che è la successiva nell'ordine sotto-fase/modulo/sequenza, verrà lanciata in parallelo con una delle procedure MO2 e MO6 che non è terminata.
• Si attenderà di seguito che tutte le procedure precedenti siano finite, poi si lanceranno le procedure MO1 e MO3, procedure della sotto-fase 2. Quando almeno una delle due sarà terminata, si lancerà MO5. Poi si attenderà che tutti i job precedenti siano terminati.
• Si lancerà quindi MO7, che è l'unica nella sotto-fase 5.

Esempio di sequenza sulla migrazione dei flussi

Dopo che la rivalidazione di dossier è terminata correttamente, il dossier è accessibile senza restrizioni per il suo utilizzo (può esserlo in maniera ristretta se alcune operazioni post-migrazione sono state differite).

Non rimane allora che verificare ed adattare alcune parametrizzazioni funzionali. Ciò viene descritto nel documento relativo ai postrequisiti funzionali.