Approcci di migrazione per BizTalk Server ad Azure Integration Services

Questa guida illustra le strategie e le risorse di migrazione insieme alle considerazioni sulla pianificazione e alle procedure consigliate per offrire soluzioni di migrazione riuscite.

Nota

Per una panoramica della migrazione e una guida alla scelta dei servizi in Azure per la migrazione, vedere la documentazione seguente:

• Perché eseguire la migrazione da BizTalk Server ad Azure Integration Services?
• Scegliere le migliori offerte di Azure Integration Services per lo scenario

Opzioni di strategia

La sezione seguente descrive varie strategie di migrazione insieme ai relativi vantaggi e svantaggi:

Modalità lift-and-shift

In Azure Marketplace è possibile trovare l'opzione per effettuare il provisioning di macchine virtuali che includono licenze BizTalk con il modello con pagamento in base al consumo. Questa offerta offre il vantaggio di usare le funzionalità IaaS (Infrastructure as a Service) di Microsoft tramite un modello di determinazione prezzi basato sul consumo. Anche se l'uso di queste macchine virtuali può alleviare alcune difficoltà nella gestione dell'infrastruttura BizTalk Server, questo approccio non risolve le pianificazioni e le scadenze del ciclo di vita del supporto per BizTalk Server.

Con le organizzazioni che adottano la trasformazione digitale passando o adottando il cloud, molte hanno le attività comuni per interrompere l'infrastruttura VMware, Hyper-V o server fisica ed eseguire la migrazione di questa funzionalità a IaaS in Azure. Questa scelta consente di ridurre le problematiche indicate in precedenza, ma non risolve la codebase BizTalk.

Con BizTalk Server 2013 e versioni successive, è possibile scegliere di eseguire i server BizTalk in locale come in precedenza o di eseguirli in un server virtuale in Azure. L'esecuzione dell'ambiente BizTalk Server nel cloud offre i vantaggi seguenti:

• Nessuna necessità di hardware privato o infrastruttura, quindi nessuna manutenzione hardware.
• Maggiore disponibilità per l'infrastruttura server, che può estendersi su più data center o essere replicata nelle zone di disponibilità.
• Accedere ai server da qualsiasi posizione tramite Internet.
• Microsoft esegue il backup delle immagini.
• Distribuzione rapida per i nuovi server usando immagini predefinite disponibili in Azure Marketplace.
• Aumento rapido delle prestazioni per i server modificando le dimensioni delle macchine virtuali per aggiungere memoria e CPU, aggiungere dischi rigidi e così via
• Maggiore sicurezza per l'ambiente usando Centro sicurezza di Azure. Questo servizio identifica le minacce alla sicurezza e fornisce un percorso di indagine quando si verificano eventi imprevisti di sicurezza

Integrazione ibrida

Anche se le funzionalità di BizTalk Server e Azure Integration Services potrebbero sovrapporsi, funzionano meglio quando vengono usate insieme. La maggior parte delle organizzazioni che non spostano l'intera infrastruttura nel cloud hanno principalmente i motivi seguenti:

• Criteri aziendali
• Criteri nazionali/regionali
• Criteri specifici del dominio del settore

Inoltre, non tutte le funzionalità o le applicazioni esistono nel cloud o alcune che sono disponibili potrebbero non essere affidabili come quelle locali. Tuttavia, per mantenere il passo con la rivoluzione del cloud e per estendere le funzionalità aziendali, molte organizzazioni iniziano usando offerte SaaS insieme ai sistemi locali. Molti processi aziendali possono trarre vantaggio dalle strategie di sviluppo e implementazione basate sul cloud.

Adottando una strategia di integrazione ibrida, è comunque possibile sfruttare il valore degli investimenti tecnologici nei sistemi da cui dipende l'organizzazione, ma sfruttare comunque nuove funzionalità, migliorare le prestazioni e ridurre la struttura dei costi delle applicazioni basate sul cloud, ad esempio Azure.

Con BizTalk Server 2016, la versione separata dell'adapter Di Microsoft BizTalk Server per app per la logica offre la possibilità di implementare parte della logica di integrazione come servizio in Azure usando App per la logica di Azure per connettere centinaia di servizi cloud. Questa scheda ha contribuito sia alle integrazioni locali che alle integrazioni ibride offrendo le funzionalità seguenti:

• Integrare i servizi cloud con BizTalk Server usando adattatori predefiniti, ad esempio App per la logica di Azure, bus di servizio di Azure, Hub eventi di Azure, Archiviazione BLOB di Azure e Posta di Office 365, Pianificazione e Contatti.

• Usare il connettore BizTalk Server in App per la logica di Azure per connettersi da App per la logica di Azure a BizTalk Server.

• Pubblicare endpoint BizTalk Server usando Azure Gestione API in modo che le organizzazioni possano esporre gli endpoint a sviluppatori interni e partner esterni.

Con BizTalk Server 2020, l'installazione includeva automaticamente l'adattatore per App per la logica di Azure insieme alle schede predefinite per connettersi facilmente all'ambiente cloud.

Big bang

Un approccio "big bang" o "cambiamento diretto" richiede un sacco di pianificazione e non è consigliato per le organizzazioni che non hanno familiarità con App per la logica di Azure o che dispongono di sistemi o soluzioni di grandi dimensioni per la migrazione. Quando un'organizzazione implementa un nuovo stack di tecnologie, spesso i nuovi apprendimento si comportano spesso. Investendo troppo presto o troppo, non si avrà l'opportunità di trarre vantaggio dalle lezioni apprese e modificare senza rischiare una rielaborazione significativa.

Questo approccio potrebbe anche richiedere più tempo per raccogliere o accumulare valore. Se sono già state completate alcune attività di migrazione, ma non sono state ancora rilasciate nell'ambiente di produzione a causa di altri lavori in sospeso o in corso, gli artefatti migrati non generano valore per l'organizzazione.

Iterativo (scelta consigliata)

Questo approccio offre all'organizzazione l'opportunità di ottenere valore in modo incrementale, ma prima che altrimenti. Il team del progetto può ottenere informazioni sullo stack di tecnologie in anticipo usando analisi retrospettive. Ad esempio, è possibile distribuire un'interfaccia o un progetto BizTalk esistente nell'ambiente di produzione e quindi ottenere informazioni sulle esigenze della soluzione, tra cui gestione, scalabilità, operazioni e monitoraggio. Dopo aver acquisito queste informazioni, è possibile pianificare gli sprint per ottimizzare le funzionalità esistenti o introdurre nuovi modelli che è possibile usare successivamente nel lavoro futuro.

Indipendentemente dall'approccio, se si prevede di passare ad Azure Integration Services o Azure in generale, è consigliabile effettuare il refactoring delle soluzioni BizTalk Server in soluzioni serverless o native del cloud prima di rimuovere l'infrastruttura server. Questa scelta è un'eccellente strategia se l'organizzazione vuole trasformare completamente l'azienda nel cloud.

Pianificare la migrazione

Nella sezione seguente vengono fornite indicazioni sulla pianificazione della migrazione e sulle aree da considerare.

Pianificazione dell'idoneità

L'idoneità rappresenta una parte fondamentale del processo di pianificazione. Quando si comprende l'ampiezza e la profondità del progetto, la prevedibilità migliora in più dimensioni, ad esempio costi, complessità, sequenze temporali e successo complessivo del progetto. L'elenco seguente include aree specifiche da rivedere e affrontare come parte del processo di charter del progetto.

Area	Descrizione
Inventario	Acquisire dati su tutte le interfacce e le applicazioni in modo da poter apprendere il numero di interfacce e applicazioni di cui è necessario eseguire la migrazione. Durante questo processo di catalogazione, raccogliere le informazioni seguenti per fornire il contesto: - Adattatori in uso - Funzionalità di BizTalk Server in uso, ad esempio Monitoraggio attività aziendali, Motore regole business, EDI e così via - Codice personalizzato, ad esempio espressioni, mappe e componenti della pipeline - Velocità effettiva dei messaggi - Dimensioni dei messaggi -Dipendenze
Complessità	Per apprendere i livelli di complessità nelle interfacce, esaminare i tipi di regole business in tali interfacce e i requisiti tecnici che richiedono la personalizzazione per soddisfare le esigenze o i requisiti di prestazioni.
Valore	Valutare il valore delle interfacce in modo da poter determinare la priorità per le interfacce da riapplicare. Anche se a partire da interfacce a basso rischio può avere senso, dopo aver lavorato con Azure Integration Services, assicurarsi di concentrarsi prima sul lavoro con il valore più elevato.
Costi	Stabilire l'ambito del progetto e stimare i costi perché un progetto di migrazione richiede capitale per avviare l'esecuzione. Proteggere il budget del progetto, indipendentemente dal fatto che sia ottenuto tramite la pianificazione del budget di capitale o operativo, e gestire l'ambito del progetto lungo la strada.
Dipendenze dell'applicazione e del sistema	Identificare e tenere conto di queste dipendenze quando si avvia la pianificazione del progetto, in modo da evitare sorprese durante l'avvio dell'esecuzione del progetto.
Registro di sistema dei rischi	Creare e usare questo artefatto per identificare e tenere traccia dei rischi che emergono durante l'esecuzione di esercizi di pianificazione del progetto. Quando si comprendono i rischi, è possibile attenuarli in modo proattivo e comunicare con la leadership. È anche possibile rimuovere i blocchi in anticipo quando sono meno costosi da risolvere.

Strumenti di migrazione

Lo strumento da riga di comando Azure Integration Migration, detto anche strumento di migrazione BizTalk, è un progetto open source Microsoft che consente di pianificare ed eseguire fasi per il progetto di migrazione insieme allo spostamento di applicazioni BizTalk Server in Azure Integration Services. È anche possibile usare questo strumento per individuare informazioni dettagliate e strategie utili per la migrazione delle soluzioni al cloud.

Questo strumento esegue le fasi seguenti:

1. Discover

   Esegue il pull delle risorse di BizTalk Server e identifica gli artefatti BizTalk di cui eseguire la migrazione. Legge gli assembly e le informazioni sul file di associazione.

   Requisiti: identità del servizio gestito per l'applicazione Biztalk Server e tutte le applicazioni BizTalk Server a cui si fa riferimento

2. Parse.

   Legge gli artefatti di BizTalk Server e compila un modello di dati di origine per l'applicazione BizTalk Server.

3. Analisi.

   Compila un modello di dati di destinazione di Azure Integration Services usando il modello di dati di origine dalla fase Analisi. In pratica, lo strumento esamina le risorse di BizTalk Server, identifica gli elementi di cui è possibile eseguire la migrazione e compila un modello di dati della destinazione di Azure Integration Services. 

4. - Report

   Genera un report che delinea le risorse di BizTalk Server trovate e gli elementi di cui è possibile eseguire la migrazione. Il report contiene anche informazioni dettagliate sul contenuto nelle applicazioni di origine e di destinazione, oltre a informazioni dettagliate su eventuali problemi potenziali con la conversione.

5. Converti

   Genera modelli di risorse di Azure Manager e script dell'interfaccia della riga di comando di Azure che è possibile usare per compilare le applicazioni in Azure usando il modello di dati di destinazione.

6. Verificare

   Questa fase non è attualmente integrata nello strumento, ma si eseguono gli script di installazione per distribuire l'applicazione in Azure. È quindi possibile valutare se l'applicazione generata fornisce la stessa funzionalità dell'applicazione locale BizTalk Server.

Il diagramma seguente illustra le fasi eseguite dallo strumento Azure Integration Migrat:

Ruoli e competenze chiave del team per una corretta migrazione

Per eseguire correttamente la migrazione dei flussi di lavoro di integrazione da BizTalk Server ad Azure Integration Services, stabilire un team con i ruoli e le competenze importanti seguenti, che si estendono su più discipline:

Ruolo	Competenze
Responsabili di progetto	Responsabile del progetto complessivo e fornisce l'ambito concordato entro i limiti per il tempo e il budget.
Leader scrum	Gestisce attivamente il backlog e facilita la definizione delle priorità per le attività del progetto.
Architetti	Assicurarsi che il progetto sia allineato ai principi architetturali aziendali e fornire indicazioni su come esplorare l'incertezza e gli ostacoli.
Sviluppatori	Lavorare attivamente sulla migrazione dei componenti da BizTalk Server ad Azure Integration Services.
Tester di controllo qualità	Creare piani di test ed eseguire test su tali piani. Tenere traccia, comunicare e valutare bug e difetti nell'ambito della pianificazione dello sprint del progetto.
Tester di accettazione utente (UAT)	Fornire agli stakeholder aziendali che consentono di assicurarsi che non vengano introdotte regressioni spostando le interfacce da una piattaforma esistente a una nuova piattaforma.
Specialisti della gestione delle modifiche	Valutare l'impatto su processi e ruoli esistenti. Creare un piano per attenuare eventuali problemi percepiti prima che si verifichino.

Per fornire alcune o tutte le risorse descritte in precedenza, prendere in considerazione i partner che hanno esperienza con l'esecuzione delle migrazioni. I membri del team possono contribuire a ridurre i rischi, migliorare il time-to-market e rendere il progetto più prevedibile con i set di competenze e le competenze.

Pianificazione del processo di compilazione

Per la pianificazione della compilazione, Microsoft consiglia di includere sprint ed elementi di lavoro per gestire i servizi di base, ad esempio l'autenticazione, la registrazione, la gestione delle eccezioni e così via. Questa inclusione consente di evitare di rielaborare più avanti nei cicli di sviluppo causati da non soddisfare le esigenze sottostanti. Si vuole anche evitare sviluppatori bloccati a causa di decisioni che richiedono ad altri stakeholder di prendere.

L'elenco seguente illustra solo alcune aree da considerare:

Area	Descrizione
Autenticazione	Prima di approfondire i cicli di sviluppo, risolvere le domande seguenti e altre informazioni sull'autenticazione. - L'organizzazione dispone di standard per gli schemi di autenticazione? - È possibile usare le identità gestite e le entità servizio in Azure? - Le chiavi API e l'autenticazione di base sono consentite o meno? Questa attività può essere una buona opportunità per portare in azienda architetti che possono assicurarsi di ottenere accordi chiari su quali schemi di autenticazione usare.
Registrazione	Prendere in considerazione la raccolta e l'archiviazione dei dati di telemetria in un repository di dati centralizzato, un modello comune usato nelle soluzioni di integrazione. Ad esempio, App per la logica di Azure (Standard) può eseguire il push dei dati di telemetria in Application Insights in Monitoraggio di Azure. App per la logica di Azure (consumo) può eseguire il push dei dati di telemetria in Log Analytics, anche in Monitoraggio di Azure. È anche possibile includere proprietà rilevate in modo che gli sviluppatori possano includere più contesto quando i messaggi passano attraverso la piattaforma di integrazione. Ad esempio, questi dati possono includere numeri di ordine di lavoro, informazioni sugli ordini di acquisto o qualsiasi altro elemento che potrebbe essere utile, utile e pertinente per l'organizzazione. Probabilmente, la soluzione di ogni organizzazione potrebbe essere diversa in base alle esigenze dell'organizzazione. Ad esempio, alcune organizzazioni vogliono il controllo completo su cosa e quando i dati vengono registrati. In questo scenario è possibile creare API o connettori personalizzati e quindi instrumentare il codice in base a attività cardine specifiche. Indipendentemente dall'approccio scelto, assicurarsi che gli sviluppatori comprendano chiaramente le aspettative per evitare rielaborazioni future.
Gestione delle eccezioni	Affrontare una strategia e un modello coerente in anticipo per gestire le eccezioni e gli errori per evitare rielaborazioni future. Assicurarsi di creare chiarezza su questa area prima di creare app per la logica. L'elenco seguente include alcune domande da rispondere quando si risolve la gestione delle eccezioni: - Come si useranno gli ambiti e le impostazioni "Esegui dopo" per rilevare le eccezioni? - Come è possibile usare l'espressione result() per comprendere meglio dove si verifica un'eccezione in un flusso di lavoro e per trovare altre informazioni sulla causa radice sottostante? - Dopo aver scelto come intercettare le eccezioni, come registrare questi dati e comunicare con gli stakeholder? Assicurarsi che queste decisioni siano allineate alla strategia di registrazione come indicato in precedenza. Idealmente, è stato stabilito un processo che cerca attivamente nuovi eventi di errore nell'archivio dati di registrazione. Da qui è possibile rispondere a questi eventi e orchestrare un processo di eccezione. Potrebbe essere necessario filtrare o aggregare eventi di errore duplicati, registrare un ticket nella soluzione di gestione dei servizi IT dell'organizzazione e scegliere come inviare notifiche. Potrebbero essere disponibili percorsi diversi per le notifiche, in base alla gravità del problema e all'ora del giorno. È possibile ottenere agilità creando un flusso di lavoro per gestire questo processo.
Analisi	Per dimostrare la salute e l'igiene generali della soluzione agli stakeholder, considerare le diverse lenti usate dagli stakeholder per esaminare, ad esempio: - I dirigenti potrebbero essere più interessati all'integrità complessiva, ai conteggi delle transazioni o al volume e al valore aziendale generato da tali transazioni, ma non alle sfumature tecniche complessive. - Un responsabile sul campo potrebbe essere più interessato all'integrità complessiva, ma potrebbe anche interessarsi a dettagli tecnici, ad esempio le caratteristiche delle prestazioni, per assicurarsi che i contratti di servizio siano soddisfatti. - Gli analisti del supporto sono probabilmente interessati all'integrità complessiva dei servizi, alle eccezioni e ai colli di bottiglia delle prestazioni. Mentre si riunisce la strategia di analisi, prendere in considerazione gli stakeholder e il tipo di dati che li interessano. Questo processo di pensiero consente di tenere traccia di informazioni utili e utili e di rendere i dati accessibili a scopo di creazione di report. Se si riscontrano gap di copertura, potrebbe essere necessario rivedere gli elementi di lavoro correlati alla registrazione e aggiungere attività appropriate per risolvere questi gap.
Cadenza	Quando si spediscono i progetti di integrazione e si imparano da queste esperienze, assicurarsi di acquisire le lezioni che inevitabilmente emergono. Pianificare sprint o cicli di correzione all'inizio del viaggio, in modo da poter correggere il corso prima che il costo diventi troppo grande. In questo modo, è possibile evitare di introdurre un debito tecnico eccessivo nella nuova piattaforma.

Pianificazione della distribuzione

Quando si prevede e si prepara un piano di distribuzione, si aumentano le opportunità per una distribuzione corretta. Con BizTalk Server, dopo aver creato tutti gli ambienti e l'infrastruttura, si è spostato lo stato attivo sulla distribuzione della soluzione.

Con Azure, questa esperienza è diversa da alcune attività da considerare per prime, ad esempio l'indirizzamento della distribuzione dell'infrastruttura tra ambienti diversi, che può includere sottoscrizioni di Azure diverse, gruppi di risorse di Azure o una combinazione, ad esempio:

• Azure Key Vault: segreti e criteri di accesso
• bus di servizio di Azure: code, argomenti, sottoscrizioni, filtri e criteri di accesso
• servizio app Azure: piani, rete e autenticazione

Successivamente, è possibile concentrarsi sulla distribuzione di soluzioni tra ambienti diversi.

Pianificazione dei test

Per assicurarsi che gli stakeholder siano soddisfatti della soluzione offerta, i test sono importanti da considerare per qualsiasi progetto di migrazione. Una nuova soluzione deve fornire più valore rispetto alla soluzione precedente, senza regressioni che potrebbero influire sull'azienda.

Prendere in considerazione le raccomandazioni di test seguenti per il progetto di migrazione:

• Stabilire la baseline rispondendo alle domande seguenti:

  1. Sono presenti test esistenti?
  2. I test vengono eseguiti senza errori?
  3. I risultati del test sono accurati?

  Per avere la certezza che il team non abbia introdotto regressioni, è necessaria la possibilità di confrontare i risultati della nuova piattaforma rispetto ai test affidabili della piattaforma esistente. Quindi, se non si ha una linea di base, assicurarsi di stabilirne una.

  Naturalmente, non si vuole spendere molte risorse stabilendo test su una piattaforma che si ritira, ma è necessario rispondere alla domanda " Ricerca per categorie sapere che tutto funziona correttamente?" Se si è in questa situazione, iniziare a stabilire la baseline in base alle priorità e creare un piano per attenuare le aree in cui sono presenti lacune.

• Configurare la strategia di test per la nuova piattaforma.

  Supponendo di avere familiarità con la baseline, è ora possibile pensare a come eseguire il test sulla nuova piattaforma. Se si è verificato un problema nella definizione della baseline, sfruttare l'opportunità di configurare una solida base per la nuova piattaforma.

  Quando si pensa ai test per la nuova piattaforma, tenere in considerazione l'automazione. Anche se l'uso di una piattaforma consente di creare rapidamente interfacce, l'uso di test manuali riduce i guadagni di produttività.

• Automatizzare i test.

  App per la logica di Azure (Standard) include la possibilità di eseguire test automatizzati. L'elenco seguente include altre informazioni e risorse disponibili gratuitamente in GitHub:

  • Test automatizzati con App per la logica di Azure (Standard) del team di App per la logica di Azure

    Con App per la logica di Azure (Standard), i test automatizzati non sono più difficili da eseguire, a causa dell'architettura sottostante, basata sul runtime Funzioni di Azure e possono essere eseguiti ovunque sia possibile eseguire Funzioni di Azure. È possibile scrivere test per i flussi di lavoro eseguiti in locale o in una pipeline CI/CD. Per altre informazioni, vedere il progetto di esempio per il framework di test App per la logica di Azure.

    Questo framework di test include le funzionalità seguenti:

    • Scrivere test automatizzati per le funzionalità end-to-end in App per la logica di Azure.
    • Eseguire la convalida con granularità fine ai livelli di esecuzione e azione del flusso di lavoro.
    • Controllare i test in un repository Git ed eseguire localmente o all'interno di pipeline CI/CD.
    • Funzionalità di test fittizie per azioni HTTP e connettori di Azure.
    • Configurare i test per l'uso di valori di impostazione diversi rispetto all'ambiente di produzione.

  • Playbook di integrazione: Test standard di App per la logica di Michael Stephenson, Microsoft MVP

    Il framework di test di Integration Playbook si basa sul framework di test fornito da Microsoft e supporta scenari aggiuntivi:

    • Connessione a un flusso di lavoro in un'app per la logica Standard.
    • Ottenere l'URL di callback in modo da poter attivare il flusso di lavoro da un test.
    • Controllare i risultati dell'esecuzione del flusso di lavoro.
    • Controllare gli input e gli output dell'operazione dalla cronologia di esecuzione del flusso di lavoro.
    • Collegare framework di test automatizzati che gli sviluppatori di app per la logica potrebbero usare.
    • Collega SpecFlow per supportare lo sviluppo basato sul comportamento (BDD) per le app per la logica.

  Indipendentemente dagli approcci o dalle risorse usati, è consigliabile avere test di integrazione automatizzati ripetibili e coerenti.

• Configurare test di risposta fittizi usando risultati statici.

  Indipendentemente dal fatto che siano stati configurati test automatizzati, è possibile usare la funzionalità dei risultati statici in App per la logica di Azure per impostare temporaneamente risposte fittizie a livello di azione. Questa funzionalità consente di emulare il comportamento da un sistema specifico che si vuole chiamare. È quindi possibile eseguire alcuni test iniziali in isolamento e ridurre la quantità di dati creati nei sistemi line-of-business.

• Eseguire test affiancati.

  Idealmente, sono già disponibili test di integrazione di base per l'ambiente BizTalk Server e sono stati stabiliti test automatizzati per Azure Integration Services. È quindi possibile eseguire i test side-by-side in modo da controllare le interfacce usando gli stessi set di dati e migliorare l'accuratezza complessiva dei test.

Passare allo stato live

Al termine del test, considerare le attività necessarie per inserire la nuova piattaforma di integrazione nell'ambiente di produzione:

1. Creare un piano di comunicazione.

   Anche se potrebbe essere presente un piccolo team che implementa gli aspetti tecnici e i dettagli per un progetto di modernizzazione della piattaforma di integrazione, è probabile che siano presenti molti stakeholder che è necessario tenere informati sul progetto di migrazione. Se non hai una chiara strategia di comunicazione, crei ansia per gli altri coinvolti. Considerare anche gli stakeholder esterni che è necessario includere nel piano di comunicazione. Ad esempio, è possibile includere altri partner commerciali o clienti che potrebbero essere interessati da eventi imminenti. Non dimenticare anche queste parti interessate.

   Quindi, comunicare in anticipo e spesso fornendo chiarezza nelle aree che interessano gli stakeholder, ad esempio ciò che ci si aspetta da loro, quando sono necessari, per quanto tempo sono necessari e così via. Fornendo un piano conciso e chiaro, si crea fiducia per gli stakeholder e si mantiene energia positiva intorno al progetto. Rimuovere eventuali dubbi assicurandosi che il team sia pronto per l'esecuzione. In caso contrario, rischi di rovinare il morale a causa di percezioni, speculazioni e voci che il tuo progetto potrebbe fallire.

2. Creare un piano "cut-over".

   Un piano di cut-over illustra i dettagli relativi alle attività e alle attività necessarie per passare dalla piattaforma corrente alla nuova piattaforma, inclusi i passaggi che il team prevede di eseguire. Includere le considerazioni seguenti nel piano di cut-over:

   • Passaggi preliminari richiesti

     Identificare le azioni che è possibile o eseguire in anticipo, in modo da non lasciare tutto per il cut-over day. In genere, un cut-over in una nuova piattaforma di integrazione significa in genere che si dispone di una distribuzione "campo verde", in modo da poter preparare più componenti e configurazioni all'inizio del ciclo. Più è possibile completare prima della finestra di manutenzione della piattaforma originale, più è possibile rimuovere e migliorare il risultato complessivo dell'evento cut-over.

   • Prove di abito

     Gli stakeholder vogliono in genere una certa prevedibilità intorno agli eventi imminenti. Quindi, come si fornisce la prevedibilità intorno a qualcosa che non è mai stato fatto prima? Eseguendo una prova completa che distribuisce la piattaforma di integrazione in un ambiente di pre-produzione, è possibile convalidare il piano di cut-over e i tempi previsti per ogni passaggio del processo.

     In caso contrario, sottostimando il tempo che un passo può intraprendere può portare a un effetto increspamento in ritardi. Cumulativamente, questi ritardi possono costare una quantità significativa di tempo e interrompere l'azienda. Quando si esegue una prova di vestito, è possibile basare la pianificazione sui dati effettivi. Il team potrebbe anche trovare problemi che potrebbero aver causato problemi durante l'esecuzione in produzione. Quando il team rileva e documenta i problemi in anticipo, sono più preparati e rischiano meno sorprese durante il vero evento di taglio.

   • Persone

     Assicurarsi che esista una chiara responsabilità in base alla persona proprietaria di ogni particolare passaggio del piano. Come strategia di mitigazione saggia, identificare e preparare le persone di backup nel caso in cui la persona primaria non sia disponibile per eseguire l'attività, a causa di circostanze impreviste.

   • Pianificare le stime

     Dopo aver eseguito una prova, il team dovrebbe avere una migliore comprensione del tempo necessario per il completamento di ogni attività. È possibile usare queste stime per prevedere una pianificazione in modo che gli utenti sappiano quando sono necessari e circa quanto tempo devono completare l'attività.

   • Disabilitazione delle interfacce nella piattaforma precedente

     Se si conoscono tutte le dipendenze esistenti, è possibile iniziare a disabilitare le interfacce nella piattaforma di integrazione precedente prima di abilitare le interfacce nella nuova piattaforma. Alcune architetture complesse potrebbero richiedere la disabilitazione delle interfacce sequenziali in un ordine specifico per evitare sorprese. A seconda della natura dell'interfaccia, potrebbe anche non essere possibile disabilitare tutte le interfacce nella piattaforma di integrazione precedente. Ad esempio, se si dispone di un sistema line-of-business che invia messaggi alla piattaforma di integrazione, assicurarsi di tenere conto di queste situazioni nel piano di cut-over.

   • Abilitazione delle interfacce nella nuova piattaforma

     Analogamente a come si potrebbero avere interfacce sequenziali che richiedono la disabilitazione in un ordine specifico, potrebbero essere presenti nuove interfacce sequenziali da abilitare con lo stesso requisito. Prima di iniziare ad abilitare le interfacce, assicurarsi di comprendere tutte le dipendenze e di aver identificato l'ordine necessario per abilitare nuove interfacce sequenziali.

     Nota

     Prestare attenzione a eseguire i passaggi per abilitare le interfacce in modo metodico e sistematico per evitare errori che rischino il successo del progetto.

   • Test di convalida

     Questa attività è estremamente importante, quindi includere questo lavoro nel piano di cut-over. Dopo aver abilitato le interfacce, verificare che le interfacce funzionino come previsto prima di passare alla fase "Vai o No-go". Idealmente, è possibile eseguire test di convalida che non influiscono sui dati aziendali principali. Questa guida fornisce altre informazioni sui test di convalida per le nuove interfacce in una sezione successiva.

3. Determinare un piano di rollback.

   Si spera ora di avere un approccio strutturato e dettagliato per implementare la nuova piattaforma di integrazione. Tuttavia, le sorprese possono verificarsi, quindi determinare i passaggi necessari per eseguire il rollback alla piattaforma di integrazione precedente. In questo modo, hai un piano pronto per andare, solo nel caso.

   Quando si sta pensando a questi passaggi, prendere in considerazione gli eventi che potrebbero attivare un rollback. Inoltre, allineare il piano alle persone che è necessario prendere la decisione di rollback. Questa guida fornisce altre informazioni nella sezione relativa all'esecuzione della decisione "Go o No-go".

4. Eseguire test di convalida.

   Il piano di cut-over dovrebbe includere i dettagli per questo lavoro. Dopo aver abilitato le interfacce, verificare che le interfacce funzionino come previsto prima di passare alla fase "Vai o No-go". Idealmente, è possibile eseguire test di convalida che non influiscono sui dati aziendali principali.

   Idealmente, ad esempio, i test di convalida possono leggere i dati da un sistema line-of-business di produzione, ma non possono scrivere dati, creando un problema di conformità. In caso contrario, è necessario attendere il flusso di una transazione aziendale attraverso le interfacce e convalidare tutto funziona come previsto dal team.

5. Pianificare le operazioni o il supporto di produzione.

   Anche se il lavoro per eseguire la migrazione delle interfacce tra piattaforme utilizza in genere la maggior parte delle risorse del progetto, fattore di supporto continuo per le interfacce e la nuova piattaforma.

   • Assicurarsi di condividere la quantità e il livello di conoscenza appropriati tra il team del progetto e il team operativo.

   • Creare e mantenere un elenco contatti corrente con i dettagli di contatto tecnici e aziendali in modo che chiunque possa raggiungere i membri del team appropriati quando necessario.

   • Per una risposta più fluida e tempestiva al supporto dei clienti, è necessario che i processi di supporto e la documentazione siano pronti prima di passare alla pubblicazione. È possibile ridurre lo stress per i clienti, il team di supporto e il team di progetto quando è possibile evitare che un membro del supporto tenti di capire tutto quando si verifica un evento imprevisto effettivo.

6. Scegliere "Vai o No-go" per passare all'ambiente di produzione.

   Per questo passaggio, collaborare con gli stakeholder interessati per decidere se il progetto può passare alla produzione. Ad esempio, gli stakeholder possono includere leadership, gestione dei progetti, operazioni e rappresentanti aziendali.

7. Celebrare il successo del team.

   Complimenti. Dopo aver completato un progetto che influisce positivamente sull'organizzazione o sull'azienda, è giunto il momento di riconoscere il team per tutto il loro duro lavoro e per celebrare un'incredibile pietra miliare! Assicurarsi di accreditare il team in modo appropriato e significativo. Nessun riconoscimento è un modo sicuro per distruggere il morale.

8. Tenere un'analisi retrospettiva.

   Come qualsiasi attività di progettazione, il team acquisisce informazioni preziose ed espande le proprie conoscenze apprendendo dall'esperienza. Incontra il tuo team per discutere e catturare aree che andavano bene, non andava bene e quelle che possono cambiare per il meglio. Si prenda cura di ospitare questa conversazione in un ambiente non minaccioso e di supporto e rimanere concentrati sull'obiettivo di imparare e crescere, non la colpa. Condividi le tue lezioni con la tua leadership e altri stakeholder interessati. Questo esercizio crea fiducia nel team e rappresenta la maturità di progettazione.

Procedure consigliate per la migrazione

Sebbene le procedure consigliate possano variare in tutte le organizzazioni, prendere in considerazione un impegno consapevole per promuovere la coerenza, che consente di ridurre gli sforzi inutili che "reinventano la ruota" e la ridondanza di componenti comuni simili. Quando si abilita la riutilizzabilità, l'organizzazione può creare più rapidamente interfacce che diventano più facili da supportare. Il time-to-market è un fattore chiave per la trasformazione digitale, quindi una priorità assoluta consiste nel ridurre gli attriti inutili per gli sviluppatori e i team di supporto.

Quando si stabiliscono procedure consigliate personalizzate, è consigliabile allinearsi alle indicazioni seguenti:

Convenzioni di denominazione generali per le risorse di Azure

Assicurarsi di configurare e applicare in modo coerente convenzioni di denominazione valide in tutte le risorse di Azure dai gruppi di risorse a ogni tipo di risorsa. Per gettare una solida base per l'individuabilità e il supporto, una buona convenzione di denominazione comunica lo scopo. Il punto più importante per le convenzioni di denominazione è che sono disponibili e che l'organizzazione le riconosce. Ogni organizzazione ha sfumature che potrebbero dover prendere in considerazione.

Per indicazioni su questa procedura, vedere i consigli e le risorse Microsoft seguenti:

• Esempi di abbreviazioni per le risorse di Azure
• Lo strumento di denominazione di Azure, che genera nomi conformi ad Azure, consente di standardizzare i nomi e di automatizzare il processo di denominazione.

Convenzioni di denominazione per le risorse di App per la logica di Azure

La progettazione per l'app per la logica e il flusso di lavoro offre un punto di partenza fondamentale perché questa area offre agli sviluppatori la flessibilità di creare nomi univoci.

Nomi delle risorse dell'app per la logica

Per distinguere tra le risorse dell'app per la logica a consumo e Standard, è possibile usare abbreviazioni diverse, ad esempio:

• Consumo: LACon
• Standard: LAStd

Dal punto di vista dell'organizzazione, è possibile progettare un modello di denominazione che include business unit, reparto, applicazione e, facoltativamente, l'ambiente di distribuzione, ad DEVesempio , UAT, PRODe così via, ad esempio:

LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>

Si supponga di avere un'app per la logica Standard in fase di sviluppo che implementa i flussi di lavoro per il reparto risorse umane nell'unità aziendale di Servizi aziendali. È possibile assegnare alla risorsa dell'app per la logica il nome LAStd-CorporateServices-HR-DEV e usare la notazione Pascal Case, se appropriato per la coerenza.

Nomi del flusso di lavoro dell'app per la logica

Una risorsa dell'app per la logica a consumo esegue sempre il mapping a un solo flusso di lavoro, quindi è necessario un solo nome. Una risorsa dell'app per la logica Standard può includere più flussi di lavoro, quindi progettare una convenzione di denominazione applicabile anche ai flussi di lavoro dei membri. Per questi flussi di lavoro, prendere in considerazione una convenzione di denominazione basata sul nome del processo, ad esempio:

Process-<*process-name*>

Pertanto, se si dispone di un flusso di lavoro che implementa le attività di onboarding dei dipendenti, ad esempio la creazione di un record dipendente, è possibile assegnare al flusso di lavoro il nome Process-EmployeeOnboarding.

Ecco altre considerazioni per la progettazione della convenzione di denominazione del flusso di lavoro:

• Seguire il modello Parent-Child per le app per la logica in cui si vuole evidenziare una relazione tra uno o più flussi di lavoro.
• Prendere in considerazione se un flusso di lavoro pubblica o utilizza un messaggio.

Nomi delle operazioni del flusso di lavoro

Quando si aggiunge un trigger o un'azione al flusso di lavoro, la finestra di progettazione assegna automaticamente il nome generico predefinito per tale operazione. Tuttavia, i nomi delle operazioni devono essere univoci all'interno del flusso di lavoro, quindi la finestra di progettazione aggiunge suffissi numerici sequenziali nelle istanze successive dell'operazione, che rende difficile la leggibilità e decifrare la finalità originale dello sviluppatore.

Per rendere i nomi delle operazioni più significativi e più facili da comprendere, è possibile aggiungere un breve descrittore di attività dopo il testo predefinito e usare la notazione Pascal Case per la coerenza. Ad esempio, per l'azione Analizza JSON, è possibile usare un nome come Parse JSON-ChangeEmployeeRecord. Con questo approccio o altri approcci simili, si continuerà a ricordare che l'azione è Analizza JSON e lo scopo specifico dell'azione. Pertanto, se è necessario usare gli output di questa azione in un secondo momento nelle azioni del flusso di lavoro downstream, è possibile identificare e trovare più facilmente tali output.

Nota

Per le organizzazioni che usano ampiamente espressioni, prendere in considerazione una convenzione di denominazione che non promuove l'uso di spazi vuoti (' '). Il linguaggio delle espressioni in App per la logica di Azure sostituisce gli spazi vuoti con caratteri ('_') di sottolineatura , che potrebbero complicare la creazione. Evitando spazi iniziali, è possibile ridurre l'attrito durante la creazione di espressioni. Usare invece un trattino o un trattino ('-), che fornisce leggibilità e non influisce sulla creazione di espressioni.

Per evitare in seguito possibili rielaborazioni e problemi relativi alle dipendenze downstream, create quando si usano gli output dell'operazione, rinominare immediatamente le operazioni quando vengono aggiunte al flusso di lavoro. In genere, le azioni downstream vengono aggiornate automaticamente quando si rinomina un'operazione. Tuttavia, App per la logica di Azure non rinomina automaticamente le espressioni personalizzate create prima di eseguire la ridenominazione.

nomi di Connessione ion

Quando si crea una connessione nel flusso di lavoro, la risorsa di connessione sottostante ottiene automaticamente un nome generico, ad esempio sql o office365. Analogamente ai nomi delle operazioni, anche i nomi di connessione devono essere univoci. Le connessioni successive con lo stesso tipo ottengono un suffisso numerico sequenziale, ad esempio sql-1, sql-2 e così via. Questi nomi non hanno alcun contesto e creano connessioni di differenziazione e mapping alle app per la logica estremamente impegnative, soprattutto per gli sviluppatori che non hanno familiarità con lo spazio e devono occuparsi della manutenzione per tali app per la logica.

Pertanto, i nomi di connessione significativi e coerenti sono importanti per i motivi seguenti:

• Leggibilità
• Trasferimento e supporto delle conoscenze più semplici
• Governance

Anche in questo caso, avere una convenzione di denominazione è fondamentale, anche se il formato non è eccessivamente importante. Ad esempio, è possibile usare il modello seguente come linea guida:

CN-<*connector-name*>-<*logic-app-or-workflow-name*>

Come esempio concreto, è possibile rinominare una connessione bus di servizio in un'app per la logica OrderQueue o un flusso di lavoro con CN-ServiceBus-OrderQueue come nuovo nome. Per altre informazioni, vedere il post di blog Turbo360 (in precedenza Serverless360) procedure consigliate, suggerimenti e consigli per l'app per la logica: #11 connettori naming convention.

Gestire le eccezioni con ambiti e opzioni "Esegui dopo"

Gli ambiti offrono la possibilità di raggruppare più azioni in modo da poter implementare il comportamento Try-Catch-Finally. La funzionalità dell'azione Ambito è simile al concetto di area in Visual Studio. Nella finestra di progettazione è possibile comprimere ed espandere il contenuto di un ambito per migliorare la produttività degli sviluppatori.

Quando si implementa questo modello, è anche possibile specificare quando eseguire l'azione Ambito e le azioni all'interno, in base allo stato di esecuzione dell'azione precedente, che può essere Succeeded, Failed, Skipped o TimedOut. Per configurare questo comportamento, usare le opzioni Esegui dopo (runAfter) dell'azione Ambito:

• Esito positivo
• Operazione non riuscita
• Viene ignorato
• Timeout scaduto

Consolidare i servizi condivisi

Quando si creano soluzioni di integrazione, è consigliabile creare e usare servizi condivisi per attività comuni. È possibile creare il team ed esporre una raccolta di servizi condivisi che il team di progetto e altri utenti possono usare. Tutti aumentano la produttività, l'uniformità e la capacità di applicare la governance alle soluzioni dell'organizzazione. Le sezioni seguenti descrivono alcune aree in cui è possibile prendere in considerazione l'introduzione di servizi condivisi:

Servizio condiviso	Motivi
Registrazione centralizzata	Fornire modelli comuni per la strumentazione del codice da parte degli sviluppatori con la registrazione appropriata. È quindi possibile configurare visualizzazioni di diagnostica che consentono di determinare l'integrità e il supporto dell'interfaccia.
Monitoraggio delle attività aziendali e monitoraggio delle attività aziendali	Acquisire ed esporre i dati in modo che gli esperti del settore aziendale possano comprendere meglio lo stato delle transazioni aziendali ed eseguire query analitiche self-service.
Dati di configurazione	Separare i dati di configurazione dell'applicazione dal codice in modo da poter spostare più facilmente l'applicazione tra ambienti. Assicurarsi di fornire un approccio coerente e facilmente replicabile unificato per accedere ai dati di configurazione in modo che i team di progetto possano concentrarsi sulla risoluzione del problema aziendale anziché dedicare tempo alle configurazioni dell'applicazione per la distribuzione. In caso contrario, se ogni progetto ha affrontato questa separazione in modo univoco, non è possibile trarre vantaggio dalle economie di scala.
Connettori personalizzati	Creare connettori personalizzati per sistemi interni che non dispongono di connettori predefiniti in App per la logica di Azure per semplificare il team di progetto e altri utenti.
Set di dati o feed di dati comuni	Esporre set di dati e feed comuni come API o connettori per i team di progetto da usare ed evitare di reinventare la ruota. Ogni organizzazione dispone di set di dati comuni che devono integrare i sistemi in un ambiente aziendale.

Esaminare, riflettere e apprendere

Di tanto in tanto, valutare e valutare le app per la logica esistenti, soprattutto quando hanno esito negativo. Non solo analizzare il processo aziendale per trovare cosa e dove è possibile migliorare, ma anche analizzare la cronologia di esecuzione del flusso di lavoro per apprendere da errori, errori ed errori che si sono verificati. App per la logica di Azure fornisce una cronologia di esecuzione così avanzata, si ha una probabilità elevata di individuare nuove informazioni sull'app durante la revisione della cronologia di esecuzione del flusso di lavoro. Come per tutto lo sviluppo di codice, possono emergere alcuni casi di bordi o angoli. Man mano che si effettuano individuazioni, aggiornare le interfacce per tenere conto di queste situazioni e migliorare l'affidabilità complessiva delle soluzioni.

Una realtà per i team di progetto è che gli sviluppatori tentano di acquisire in modo generico gli errori per ottenere almeno una certa protezione dai problemi. Man mano che il team scopre e meglio capisce dove possono verificarsi problemi, è possibile ottenere informazioni più prescrittive su come proteggersi dai problemi.

Analogamente a come le organizzazioni eseguono regolarmente esercizi "red team", ad esempio test di penetrazione o tentativi di phishing, la sicurezza non è un'attività "set-and-forget". Man mano che diventano disponibili nuovi schemi di autenticazione e approcci, rivedere periodicamente le interfacce, esaminare le misure di sicurezza e incorporare nuovi sviluppi pertinenti e appropriati che forniscono gli approcci più sicuri.

DevOps è un'altra area da valutare periodicamente. Man mano che Microsoft o la community introduce nuovi modelli o approcci, valutare questi aggiornamenti per determinare se è possibile ottenere maggiori vantaggi.

Passaggi successivi

Sono stati appresi altri approcci di migrazione disponibili, considerazioni sulla pianificazione e procedure consigliate per lo spostamento di carichi di lavoro di BizTalk Server in Azure Integration Services. Per fornire commenti e suggerimenti dettagliati su questa guida, è possibile usare il modulo seguente:

Inviare commenti e suggerimenti sulla migrazione per BizTalk Server ad Azure Integration Services