Approcci di migrazione per BizTalk Server ai Servizi di integrazione 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

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

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 prende in esame 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 o infrastruttura privata, per cui 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 tramite il 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 Servizi di integrazione di Azure 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 mantenersi al 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 beneficiare comunque di 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 Microsoft BizTalk Server per App per la logica ha offerto l'opportunità 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 a quelle 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, Pianificazione e Contatti di Office 365.

• 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 Gestione API di Azure 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 "passaggio diretto" richiede molta 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.

Iterativo (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 Servizi di integrazione di Azure o Azure in generale, è vivamente 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 diverse 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.

Strumenti di migrazione

Lo strumento da riga di comando Azure Integration Migrator, detto anche strumento di Migrazione BizTalk, è un progetto open source Microsoft che aiuta nelle fasi di pianificazione ed esecuzione del progetto di migrazione oltre che nello spostamento di applicazioni BizTalk Server in Servizi di integrazione di Azure. È 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: MSI 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 Servizi di integrazione di Azure 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 Servizi di integrazione di Azure. 

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. Convert

   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 Migrator:

Ruoli e competenze chiave del team per una corretta migrazione

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

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 il blocco di sviluppatori a causa di decisioni che richiedono ad altri stakeholder di prendere.

L'elenco seguente illustra solo alcune aree da considerare:

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 di 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 "Come faccio a sapere 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, 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 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 Servizi di integrazione 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.

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 tempestivamente 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 operazioni 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 giorno di cut-over. 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 di 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 tempestivamente i problemi, è più preparato e rischia meno sorprese durante il reale evento di cut-over.

   • 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 suddette funzionino come previsto prima di passare alla fase "Go o No-go". Idealmente, è possibile eseguire test di convalida che non influiscono sui principali dati aziendali. 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 suddette funzionino come previsto prima di passare alla fase "Go o No-go". Idealmente, è possibile eseguire test di convalida che non influiscono sui principali dati aziendali.

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

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

Come esempio concreto, è possibile rinominare una connessione del 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: 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. 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 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:

Esaminare, riflettere e apprendere

Di tanto in tanto, prendere in esame 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 offre una cronologia di esecuzione altamente avanzata, con una probabilità elevata di individuare nuove informazioni sull'app durante la presa in esame 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

Si sono appresi altri approcci di migrazione disponibili, considerazioni sulla pianificazione e procedure consigliate per lo spostamento di carichi di lavoro di BizTalk Server a Servizi di integrazione di Azure. Per fornire commenti e suggerimenti dettagliati su questa guida, è possibile usare il modulo seguente: