Approcci di migrazione per BizTalk Server a App per la logica di Azure

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.

Opzioni di strategia

Le sezioni seguenti descrivono varie strategie di migrazione insieme ai relativi vantaggi e svantaggi:

Big Bang

Un "big bang" o "cambiamento diretto" è un approccio che 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, il risultato sono spesso nuovi apprendimenti. Se si investe troppo presto o in maniera eccessiva, 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 le suddette 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.

È consigliabile considerare questo approccio solo se sono presenti carichi di lavoro BizTalk di piccole e basse complessità, esperti in materia (PMI) che conoscono l'ambiente BizTalk e mapping diretti tra le funzionalità BizTalk attualmente usate e App per la logica di Azure. Anche l'esperienza con App per la logica di Azure riduce notevolmente i rischi con questo approccio.

Iterativo o basato su onda (scelta consigliata)

Questo approccio offre all'organizzazione l'opportunità di ottenere valore in modo incrementale, ma prima di quanto accadrebbe altrimenti. Il team del progetto può ottenere tempestivamente informazioni sullo stack di tecnologie 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 criteri che è possibile usare successivamente nel lavoro futuro.

Indipendentemente dall'approccio, se si prevede di passare a App per la logica di Azure 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.

BizTalk Server e App per la logica di Azure hanno architetture diverse. Per modernizzare ulteriormente le soluzioni, è possibile usare Azure Integration Services per estendere le funzionalità in App per la logica di Azure che rispondono alle esigenze di base dell'integrazione dei clienti.

Per un ritorno sugli investimenti (ROI) più elevato, è consigliabile che qualsiasi migrazione BizTalk usi le funzionalità native principali in App per la logica di Azure (Standard) il più possibile e estese con altri Servizi di integrazione di Azure in base alle esigenze. Questa combinazione rende possibili scenari aggiuntivi, ad esempio:

• Funzionalità ibride native del cloud con App per la logica di Azure (Standard) con distribuzione ibrida
• Funzionalità del flusso di lavoro con stato o senza stato in App per la logica di Azure (Standard)
• Mainframe nativo integrato (in-app) e integrazione midrange con i connettori in App per la logica di Azure (Standard)
• Messaggistica secondaria di pubblicazione con bus di servizio di Azure
• Funzionalità SOAP avanzate in Azure Gestione API

Distribuire un progetto di migrazione BizTalk

Per completare un progetto di questo tipo, è consigliabile seguire l'approccio iterativo o basato su onde e usare il processo Scrum. Anche se Scrum non include un concetto Sprint Zero (Sprint 0) per le attività di pre-sprint, è consigliabile concentrare il primo sprint sull'allineamento del team e sull'individuazione tecnica. Dopo Sprint 0, seguire l'esecuzione di più sprint di migrazione e concentrarsi sul rilascio delle funzionalità verso un prodotto minimo funzionante (MVP).

Sprint 0

Durante questo sprint, è consigliabile eseguire l'individuazione degli ambienti BizTalk Server con la pianificazione delle onde. Comprendere l'ampiezza e la profondità del progetto è fondamentale per il successo. L'elenco seguente include le aree specifiche da affrontare durante sprint 0:

Strumenti di individuazione

Per semplificare l'individuazione della migrazione, è possibile usare lo strumento da riga di comando Azure Integration Migration, detto anche strumento di migrazione BizTalk, ovvero un progetto open source Microsoft. Questo strumento usa un approccio in più fasi per individuare informazioni dettagliate e strategie utili per la migrazione delle soluzioni al cloud. È consigliabile usare lo strumento di migrazione solo per l'individuazione e la generazione di report. È anche possibile prendere in considerazione l'uso di altri prodotti per l'individuazione da parte di partner che forniscono soluzioni in questo spazio.

Per un altro modo per generare un inventario con gli elementi di BizTalk Server, è possibile usare BizTalk Documenter, sviluppato da Mark Brimble. Questo strumento funziona con BizTalk Server 2020, nonostante indichi che è supportato solo BizTalk Server 2016.

Progettazione dell'architettura

Anche se App per la logica di Azure offre funzionalità che consentono di riutilizzare gli asset di BizTalk Server, è necessario disporre di una progettazione moderna dell'architettura per sfruttare i vantaggi derivanti da funzionalità più moderne. Dal punto di vista funzionale, usare la logica di business il più possibile. Dal punto di vista della modernizzazione del prodotto, usare Azure Integration Services per quanto possibile. Per problemi di qualità e trasversale, è consigliabile usare Azure Well-Architected Framework.

In questo framework, le migrazioni BizTalk sono carichi di lavoro cruciali. Questo termine descrive le raccolte di risorse dell'applicazione che richiedono disponibilità elevata nella piattaforma, ovvero devono essere sempre disponibili, operative e resilienti agli errori.

Per completare la progettazione dell'architettura per la migrazione bizTalk, seguire la metodologia di progettazione per carichi di lavoro cruciali in Azure. Per un'architettura e una topologia iniziali, esaminare e usare l'architettura di riferimento descritta in Integrazione aziendale di base in Azure nel Centro architetture di Azure.

Per configurare l'ambiente iniziale, usare l'acceleratore di zona di destinazione di Azure Integration Services, destinato alla creazione e alla distribuzione di una piattaforma di integrazione usando una tipica progettazione della zona di destinazione aziendale.

Definizione minima di progetto valido (MVP)

Un MVP è una versione del prodotto che ha solo funzionalità utilizzabili dal cliente. Questa versione mostra le possibilità del prodotto e il potenziale per raccogliere commenti e suggerimenti dei clienti e continuare il lavoro. Per una migrazione BizTalk, la definizione di MVP riflette le iterazioni, le onde o i gruppi di sprint necessari per compiere progressi verso le funzionalità di lavoro e per soddisfare i carichi di lavoro iniziali di integrazione.

È consigliabile che la definizione di MVP includa i risultati aziendali seguenti, espressi come Epics nella terminologia scrum:

Risultati aziendali (epiche)

• Qual è l'obiettivo principale da raggiungere?
• Quali funzionalità o funzionalità è necessario affrontare per questo MVP?
• Quali sono i processi aziendali? Questa domanda offre l'opportunità di ottimizzare i processi esistenti supportati da BizTalk Server.
• Quali sono le decisioni aziendali, ad esempio i risultati aziendali che influiscono sull'MVP o che cos'è la disponibilità delle risorse?

È consigliabile che l'MVP includa i processi nell'ambito seguenti, espressi come funzionalità nella terminologia scrum:

Processi nell'ambito (funzionalità)

È anche necessario identificare ed elencare le varie variabili out-of-scope che modellano l'ambito del lavoro MVP, ad esempio:

• Disponibilità delle risorse
• Rischi
• Documentazione
• Tempo di commercializzazione

Backlog iniziale

Il backlog iniziale è un set di storie utente, raggruppate in Funzionalità per compilare i processi nell'ambito per l'MVP. In altre parole, un MVP è rappresentato da elementi Scrum noti come Epics, Features e User Stories. Idealmente, ogni Epic include un gruppo di applicazioni BizTalk o progetti BizTalk. È possibile usare la regola semplice che associa un'applicazione BizTalk o un progetto BizTalk a una funzionalità.

Si supponga, ad esempio, di avere un progetto BizTalk Server con un'orchestrazione denominata "LoanRequests" usata dai clienti per richiedere prestiti bancari. Di conseguenza, sono disponibili le funzionalità proposte e la storia utente seguenti:

• Funzionalità: elaborazione dei prestiti

• Storia utente: "Come cliente, voglio inviare una richiesta di prestito in modo che la banca possa aggiungere fondi al mio conto sicuro".

  Questa storia utente, che potrebbe esistere come implementazione in BizTalk Server, prevede le attività seguenti da implementare usando App per la logica di Azure e Azure Integration Services:

  • Raccogliere gli artefatti riutilizzabili di BizTalk.
  • Creare un flusso di lavoro di richiesta di prestito usando App per la logica di Azure.
  • Configurare la messaggistica asincrona usando bus di servizio di Azure o IBM MQ.
  • Eseguire il mapping di JSON ai dati XML usando un flusso di lavoro App per la logica di Azure.
  • Personalizzare Azure Integration Services in base alle esigenze per i modelli di messaggistica.

Il diagramma seguente illustra le durate suggerite per epiche, funzionalità, storie utente e attività, che suddividono le storie utente. Sebbene le decisioni di implementazione influiscano su queste durate, presuppongono che si usino elementi BizTalk esistenti in App per la logica di Azure. Creare i flussi di lavoro Standard usando i modelli di flusso di lavoro predefiniti il più possibile.

Onde di migrazione (sprint)

Al termine dello Sprint 0, è necessario avere una visione chiara dell'MVP da compilare. Un'onda è un set di sprint. Il backlog iniziale deve includere gli elementi di lavoro che seguono il diagramma successivo il più possibile:

Durante un'ondata, il team completa le attività di migrazione, test e rilascio in produzione. Esaminiamo più da vicino ciò che accade in ogni onda.

Migrazione

Durante ogni fase, la migrazione è incentrata sulle storie utente concordate. Per la prima ondata, il team si concentra sul backlog iniziale. Le decisioni tecnologiche devono usare le informazioni nel mapping delle funzionalità di BizTalk Server, descritte in Corrispondenza delle funzionalità: perché eseguire la migrazione da BizTalk Server a App per la logica di Azure?

Il diagramma seguente illustra gli eventi che devono verificarsi durante le fasi di migrazione:

Il diagramma seguente illustra un ambiente di migrazione iniziale di esempio con un'app per la logica Standard che orchestra i flussi di lavoro che comunicano con API, servizi, soluzioni ibride e risorse locali:

Test

Ogni onda ha le proprie attività di test, incorporate in ogni storia utente. Per usare i test di spostamento a sinistra, assicurarsi di completare le attività seguenti:

• 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, grazie all'architettura sottostante, basata sul runtime di Funzioni di Azure, ed è possibile eseguirli 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 di 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 Playbook di integrazione si basa sul framework di test fornito da Microsoft e supporta scenari aggiuntivi:

    • Connettersi 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.
    • Collegare SpecFlow per supportare lo sviluppo basato sul comportamento (BDD) per le app per la logica.

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

• 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 App per la logica di Azure. È 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.

Rilascio in produzione

Al termine del team e soddisfa la "definizione di fatto" per le storie utente, prendere in considerazione le attività seguenti:

1. Creare un piano di comunicazione per il rilascio in produzione.

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
   • Prove di abito
   • People
   • Pianificare le stime
   • Disabilitazione delle interfacce nella piattaforma precedente
   • Abilitazione delle interfacce nella nuova piattaforma
   • Test di convalida

3. Determinare un piano di rollback.

4. Eseguire test di convalida.

5. Pianificare le operazioni o il supporto di produzione.

6. Scegliere i criteri "vai o no go" per il rilascio nell'ambiente di produzione.

7. Celebrare il successo del team.

8. Tenere un'analisi retrospettiva.

Procedure consigliate per una migrazione BizTalk

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 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, aiuta a standardizzare i nomi e 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 di app per la logica

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

• A consumo: LACon
• Standard: LAStd

Dal punto di vista dell'organizzazione, è possibile progettare un criterio di denominazione che include business unit, reparto, applicazione e, facoltativamente, l'ambiente di distribuzione, ad esempio DEV, UAT, PROD e 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 dei flussi 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 di 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 padre-figlio per i flussi di lavoro 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 Analizza 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.

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

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 forniscono alcun contesto, che rende estremamente impegnative le connessioni di differenziazione e mapping ai flussi di lavoro, soprattutto per gli sviluppatori che non conoscono lo spazio della soluzione e devono gestire questi flussi di lavoro.

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 criterio seguente come linea guida:

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

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

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. 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 Operazione riuscita, Operazione non riuscita, Operazione ignoratao TimedOut. Per configurare questo comportamento, usare le opzioni Esegui dopo (runAfter) dell'azione Ambito:

• Ha avuto esito positivo
• Non è riuscito
• È stato ignorato
• È 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:

Passaggi successivi

Sono state apprese altre informazioni sugli approcci di migrazione disponibili e sulle procedure consigliate per lo spostamento dei carichi di lavoro di BizTalk Server in App per la logica di Azure. Per fornire commenti e suggerimenti dettagliati su questa guida, è possibile usare il modulo seguente: