Migrazione WBM con Windchill+
Utilizzare il modulo Windchill Bulk Migrator (WBM) per la migrazione. Questo argomento illustra le varie attività di Windchill Bulk Migrator (WBM).
Prerequisiti
Uno scenario di migrazione WBM presenta alcune specificità, ma viene realizzato in modo omogeneo dai concetti sviluppati nelle altre sezioni di questo Help Center.
• Uno scenario di migrazione WBM è uno scenario Windchill+ avanzato che coinvolge ambienti di migrazione e controllo qualità. La struttura generale dell'ambiente è la seguente:
• La migrazione WBM utilizza un framework automatizzato appositamente creato per Windchill+. Non è richiesto e non viene concesso alcun accesso back-end nell'ambiente di migrazione.
• Ogni migrazione è a sé. Questa sezione descrive i servizi disponibili in Windchill+ per supportare la maggior parte degli scenari di migrazione WBM. Tuttavia, a seconda della complessità, i clienti o i partner devono progettare e pianificare il progetto di migrazione e adattarlo a requisiti specifici. Ad esempio, il numero di prove, prerequisiti e attività obbligatorie aggiuntive da eseguire in locale e così via.
• La strutturazione dei metadati di cui eseguire la migrazione richiede un database. Per evitare diverse trasformazioni, si presuppone che venga utilizzato un database di staging locale. È necessario utilizzare il database Oracle. L'utilizzo del database Oracle è necessario in base ai requisiti della versione di Windchill. La struttura del database deve soddisfare i requisiti del database di staging Windchill WBM.
• Si consiglia di creare uno schema di database distinto in locale per il database di staging WBM.
• Windchill ha eseguito la transizione dal modello di dati legacy di gestione delle modifiche al nuovo modello di dati flessibile utilizzando un'utilità di conversione, poiché Windchill+ non supporta la modalità mista. Di conseguenza, prima di eseguire un processo di migrazione in blocco con Windchill Bulk Migrator, il sistema di origine deve essere convertito alla modalità flessibile. Per ulteriori informazioni, vedere Removal of Legacy Links from Windchill 13.0.2.0.
Ambiente di migrazione
Nell'ambiente di migrazione si verifica un processo prescrittivo per riunire codice, configurazione e dati. Oltre a inviare un package della build per la migrazione, utilizzare Windchill Bulk Migrator (WBM) per inviare i dati di staging. Questi dati vengono caricati nel database di staging di migrazione per la valutazione. Lo spostamento di codice, configurazione e dati fa parte del framework operativo principale di Windchill+. Ad esempio, l'utente genera dati dal sistema A e li inserisce in una posizione, quindi Windchill+ esegue automaticamente la migrazione di tutti gli elementi nel sistema B.
Dopo la migrazione, l'utente invia i package della build all'ambiente di controllo qualità e quindi all'ambiente di produzione.
Attività di migrazione WBM
Si considerino le seguenti informazioni relative alle attività di migrazione WBM:
Prima della fase di Go Live
Il sistema utilizza l'ambiente di integrazione per integrare tutte le modifiche al codice e raggiungere un livello di maturità con la build prima di avviare i test di caricamento della migrazione. Il processo di distribuzione di una build è simile a quello descritto nell'argomento Invio e promozione del package.
Attenersi alla procedura descritta di seguito.
1. Inviare una build e un file manifest con deploy_pipe : int. Per ulteriori informazioni, vedere Deploying Code and Configuration Package.
2. Completare il ciclo di test di integrazione e accettazione funzionale. Al termine del ciclo di test, il task viene completato e l'ambiente viene ripristinato allo stato del ciclo di vita precedente.
 | Se questo passo non viene completato entro sette giorni, viene ripristinato lo stato del ciclo di vita precedente dell'ambiente. |
Procedura per l'ambiente di migrazione
L'ambiente di migrazione viene utilizzato per i test di caricamento. Attenersi alla procedura descritta di seguito.
1. Caricare il dump del database di staging nell'area di archiviazione utilizzando AzCopy.
Per ulteriori informazioni, visitare i link seguenti:
2. Aprire una richiesta di assistenza per richiedere l'importazione del dump del database di staging. Per ulteriori informazioni, vedere Apertura di una richiesta di assistenza.
3. Distribuire la build. Il processo di distribuzione di una build è simile a quello descritto nell'argomento Invio e promozione del package. Questo argomento si applica alla distribuzione di una build nell'ambiente di migrazione.
4. Inviare una build e un file manifest con deploy_pipe : mig. Per ulteriori informazioni, vedere Deploying Code and Configuration Package.
| | Per default, per l'ambiente di migrazione, il backup creato durante questo passo viene mantenuto per 30 giorni. |
5. Aprire una richiesta di assistenza per eseguire il caricamento.
6. In caso di migrazione del contenuto, recuperare il file mappa del contenuto dall'account di archiviazione e preparare uno script di copia del contenuto. Successivamente, aprire una richiesta di assistenza con lo script allegato per eseguire il trasferimento finale del contenuto. Per ulteriori informazioni, vedere Apertura di una richiesta di assistenza.
7. Completare il ciclo di test di migrazione. Al termine del ciclo di test, viene ripristinato lo stato del ciclo di vita vuoto dell'ambiente tramite una delle azioni seguenti necessarie con una richiesta di assistenza (nell'ordine preferito):
◦ Riconfigurazione dall'ambiente di produzione
◦ Reprovisioning (utilizzato solo per la migrazione iniziale, da non utilizzare per migrazioni di dati successive).
Procedura per l'ambiente di controllo qualità
L'ambiente di controllo qualità viene utilizzato per i test di accettazione degli utenti. Attenersi alla procedura descritta di seguito.
1. Ripetere lo stesso processo con lo stato del ciclo di vita più recente dei dati importati nel database di staging.
◦ Inviare una build e un file manifest con deploy_pipe : pipeline.
| | Per default, per l'ambiente di controllo qualità, il backup acquisito durante questo passo viene mantenuto per 30 giorni. |
2. Aprire una richiesta di assistenza per richiedere l'esecuzione del caricamento sull'ambiente di controllo qualità. Per ulteriori informazioni, vedere Apertura di una richiesta di assistenza.
3. In caso di migrazione del contenuto, recuperare il file mappa del contenuto dall'account di archiviazione e preparare uno script di copia del contenuto. Successivamente, aprire una richiesta di assistenza con lo script allegato per eseguire il trasferimento finale del contenuto. Per ulteriori informazioni sulla creazione di un file mappa del contenuto, vedere Fasi di WBM.
4. Completare il ciclo di test di accettazione degli utenti. Sono disponibili fino a 30 giorni per prendere una delle seguenti decisioni:
◦ Se il ciclo di test ha esito positivo, il task viene approvato e solo la build viene promossa all'ambiente di produzione.
◦ Se il ciclo di test non ha esito positivo:
▪ Il task può essere rifiutato e viene ripristinato lo stato del ciclo di vita precedente dell'ambiente.
▪ Il task può essere approvato e la build viene promossa all'ambiente di produzione. È possibile inviare una build successiva per correggere i bug.
◦ Se il ciclo di test non viene completato entro 30 giorni, viene automaticamente ripristinato lo stato del ciclo di vita precedente dell'ambiente. Per mantenere l'ambiente, è necessario approvare il task.
| | Se è necessario un altro caricamento completo nel controllo qualità, viene ripristinato lo stato del ciclo di vita vuoto dell'ambiente tramite una delle seguenti azioni necessarie con una richiesta di assistenza (nell'ordine preferito): • Riconfigurazione dall'ambiente di produzione. • Reprovisioning (solo per la migrazione iniziale, da non utilizzare per migrazioni di dati successive). |
Facoltativamente, se il caricamento delta è pianificato per il Go Live, deve essere eseguito in produzione in modo indipendente. Aprire una richiesta di assistenza per richiedere o ripetere un'esecuzione del caricamento nell'ambiente di produzione. Per ulteriori informazioni, vedere Apertura di una richiesta di assistenza.
Fase di Go Live
• In questa fase, la build precedentemente approvata è già presente negli ambienti di controllo qualità e produzione.
• Inoltre, nell'ambiente di produzione potrebbe essere disponibile un caricamento di dati precedente.
• Se non sono richiesti invii di build durante il cutover del Go Live (o se è stata inviata in anticipo la build richiesta per il Go Live), attenersi alla procedura descritta di seguito.
1. Caricare il dump del database di staging più recente nell'account di archiviazione.
2. Aprire una richiesta di assistenza per richiedere un'importazione del database di staging più recente.
3. Aprire una richiesta di assistenza per eseguire il caricamento nell'ambiente di produzione.
4. In caso di migrazione del contenuto, dopo la creazione dello script, aprire una richiesta di assistenza per il trasferimento del contenuto finale.
• Se è necessario l'invio di una build, seguire il processo descritto nella sezione Procedura per l'ambiente di controllo qualità per l'invio e la promozione della build. Successivamente, eseguire le attività di produzione e le richieste di servizio come descritto nella sezione Procedura per l'ambiente di controllo qualità.
• Una volta confermato il Go Live da parte dell'utente, è obbligatorio riconfigurare l'ambiente di produzione in un ambiente di controllo qualità e integrazione (ed eseguire l'eventuale migrazione successiva pianificata). È necessario aprire una richiesta di assistenza per le attività di riconfigurazione.
Fase di esecuzione
• Al termine del Go Live, poiché tutti gli ambienti vengono riconfigurati dall'ambiente di produzione, PTC consiglia vivamente di propagare le modifiche agli ambienti di sviluppo.
◦ Il modello di dati è la configurazione minima richiesta e deve essere utilizzato come punto di partenza nell'ambiente di sviluppo.
◦ È possibile riutilizzare la build più recente.
• In caso di migrazioni successive, è necessario ripetere il processo descritto nella sezione Prima della fase di Go Live.
| | Per evitare la perdita di dati esistenti, considerare attentamente le attività di aggiornamento dell'ambiente durante le fasi di progettazione e pianificazione del progetto. |
Considerazioni finali
• Per eseguire una migrazione su larga scala e ridurre l'impatto durante il cutover del Go Live, si consiglia di progettare le attività di migrazione in modo da consentire il caricamento delta.
• Ogni progetto di migrazione è a sé. Per garantire l'esito positivo dei progetti di migrazione, è necessario eseguire attività quali pianificazione avanzata, definizione dell'ambito, gestione di dipendenze e rischi. Queste attività garantiscono una corretta progettazione della migrazione e un cutover del Go Live uniforme.
• I test di migrazione vengono spesso sottostimati. Per i progetti di migrazione semplici, PTC consiglia di iniziare con tre cicli di migrazione di test. Con l'aumento della complessità, è possibile pianificare l'implementazione di più cicli.