Perché eseguire la migrazione da BizTalk Server ad App per la logica di Azure?

Questa guida offre una panoramica dei motivi e dei vantaggi, delle funzionalità e di altre informazioni utili per iniziare la migrazione da BizTalk Server ad App per la logica di Azure. Seguendo questa guida sono disponibili altre guide che illustrano le strategie di migrazione, le considerazioni sulla pianificazione e le procedure consigliate per ottenere risultati positivi.

Motivazioni e vantaggi

Eseguendo la migrazione dei carichi di lavoro di integrazione ad App per la logica di Azure, è possibile sfruttare i vantaggi principali seguenti:

Funzionamento di BizTalk Server

BizTalk Server si avvale di un'architettura del motore di messaggistica di pubblicazione-sottoscrizione che ha come componente centrale il database MessageBox. MessageBox è responsabile dell'archiviazione di messaggi, proprietà dei messaggi, sottoscrizioni, stati orchestrazione, dati di rilevamento e altre informazioni.

Quando BizTalk Server riceve un messaggio, il server trasmette ed elabora il messaggio tramite una pipeline. Questo passaggio normalizza e pubblica il messaggio su MessageBox. Quindi, BizTalk Server valuta eventuali sottoscrizioni esistenti e determina il destinatario previsto del messaggio, in base alle proprietà del contesto del messaggio. Infine, BizTalk Server indirizza il messaggio al destinatario previsto basandosi su sottoscrizioni o filtri. Il destinatario è un'orchestrazione o una porta di trasmissione, ovvero una destinazione alla quale BizTalk Server invia messaggi o un'origine dalla quale BizTalk Server può ricevere messaggi. BizTalk Server trasmette i messaggi tramite una porta di trasmissione, facendoli passare attraverso una pipeline di trasmissione. La pipeline di trasmissione serializza i messaggi nel formato nativo previsto dal destinatario prima di inviare i messaggi tramite un adapter.

Il database MessageBox include i componenti seguenti:

• Agente di messaggistica

  BizTalk Server interagisce con MessageBox usando questo agente, che fornisce interfacce per pubblicare messaggi, per la sottoscrizione ai messaggi, il recupero di messaggi, e altro ancora.

• Uno o più database SQL Server

  Questi database forniscono l'archivio salvataggi permanenti per messaggi, parti di messaggi, proprietà dei messaggi, sottoscrizioni, stato orchestrazione, dati di rilevamento, code host per il routing, e altro ancora.

L'immagine seguente mostra il funzionamento del motore di messaggistica di BizTalk Server:

Quando una porta di ricezione riceve un messaggio, MessageBox archivia il messaggio per l'elaborazione da parte dei processi aziendali o per il instradarlo a qualsiasi porta di trasmissione che abbia sottoscrizioni per messaggi specifici.

Per altre informazioni, vedere Architettura di pubblicazione-sottoscrizione più avanti in questa guida.

App per la logica di Azure: successore di BizTalk

Azure Logic Apps è la piattaforma di orchestrazione e integrazione del workflow di livello aziendale di Microsoft. Questa piattaforma è progettata per processi deterministici a esecuzione prolungata e con stato in ambienti cloud e ibridi. L'elemento di differenziazione principale combina flussi di lavoro visivi a basso codice con funzionalità della piattaforma Azure di prima classe: sicurezza, identità, rete, monitoraggio e governance. Azure Logic Apps supporta più modelli di distribuzione (Consumo, Standard, Ibrido), permettendo ai clienti di eseguire workflows completamente gestiti su Azure o in prossimità dei sistemi locali, mantenendo al contempo affidabilità, gestione dello stato ed esecuzione verificabile. Questa flessibilità rende la piattaforma il backbone naturale per modernizzare le proprietà di BizTalk Server, orchestrare le integrazioni B2B/EDI e connettere sistemi SaaS, ERP, CRM e legacy in cui la durabilità e l'osservabilità non sono negoziabili.

Tuttavia, Azure Logic Apps non è solamente "low-code". I clienti usano regolarmente l'estendibilità pro-code insieme ai flussi di lavoro visivi: inline C#, JavaScript e PowerShell, codice personalizzato tramite funzioni locali eseguite in App per la logica di Azure e connettori personalizzati. Questa estendibilità consente ai team di incorporare logica di business complessa, trasformazioni, gestione dei protocolli e convalida direttamente all'interno di orchestrazioni senza interrompere il modello del flusso di lavoro. Negli scenari reali, ad esempio l'elaborazione delle attestazioni, l'onboarding, le pipeline di conformità, i mainframe e le integrazioni del settore sanitario, i clienti si affidano ad App per la logica di Azure per agire come livello di esecuzione controllata che combina orchestrazione deterministica con codice personalizzato e, sempre più, decisioni assistita dall'intelligenza artificiale, mantenendo al tempo stesso governance, sicurezza e attendibilità operativa su larga scala.

In Azure Logic Apps, è possibile creare applicazioni e processi aziendali eseguibili come workflow di Logic Apps utilizzando un approccio a blocchi con un progettista visivo e operazioni predefinite da centinaia di connettori, che richiedono un codice minimo. Un flusso di lavoro di app per la logica inizia con un'operazione di attivazione seguita da una o più operazioni di azione, dove ogni operazione funziona come passaggio logico nel processo di implementazione del flusso di lavoro. Il flusso di lavoro si può avvalere delle azioni per chiamare software, servizi e sistemi esterni. Alcune azioni eseguono attività di programmazione, ad esempio condizioni, cicli, operazioni di dati, gestione delle variabili e altro ancora.

App per la logica di Azure offre i seguenti vantaggi di esempio:

• Incentrato sulla finestra di progettazione (dichiarativo)

  Progettare processi complessi usando strumenti di progettazione intuitivi per implementare modelli e flussi di lavoro la cui implementazione nel codice potrebbe essere complessa.

• Sviluppo code-first

  Creare soluzioni complete basate su codice usando Visual Studio Code, consentendo di riutilizzare il codice .NET Framework legacy esistente e di incorporare le versioni più recenti di .NET.

• Flessibile e scalabile

  Azure Logic Apps è un servizio di elaborazione basato sul cloud, serverless e altamente scalabile che adatta automaticamente alle esigenze aziendali in continua evoluzione.

Esperienze per sviluppatori

Questa sezione riepiloga le modifiche apportate agli strumenti di sviluppo durante la migrazione da BizTalk Server (incentrato su Visual Studio) ad App per la logica di Azure (incentrate su Visual Studio Code) e perché molti team trovano il modello di flusso di lavoro di App per la logica di Azure più velocemente per la compilazione e la manutenzione.

• Strumenti e modello di autorizzazione

  Con BizTalk, il lavoro di integrazione giornaliera avviene in Visual Studio e viene distribuito in più tipi di artefatti, ad esempio schemi, mappe, orchestrazioni e pipeline, oltre alla creazione di pacchetti di distribuzione (MSI/binding) in ambienti server condivisi.

  Con App per la logica di Azure, molti team passano a Visual Studio Code per modificare le definizioni dei flussi di lavoro e i file correlati usando un approccio più semplice "flusso di lavoro e connettori" che riduce la complessità della soluzione e incoraggia modifiche più piccole e incrementali. In pratica, Visual Studio Code è in genere più veloce da installare, aggiornare e standardizzare tra team rispetto al mantenimento dell'allineamento delle versioni di BizTalk e Visual Studio. Le definizioni del flusso di lavoro basate su testo tendono a migliorare le differenze e il merge di Git, le revisioni del codice e il riutilizzo rispetto alle soluzioni BizTalk compilate di grandi dimensioni.

• Cosa rende il passaggio ad App per la logica di Azure un miglioramento

  App per la logica di Azure associa lo sviluppo basato su Visual Studio Code con la diagnostica nativa del cloud. È possibile convalidare e aggiornare rapidamente i flussi di lavoro, quindi usare la cronologia di esecuzione del flusso di lavoro per visualizzare gli input e gli output dell'operazione senza basarsi su console lato server e risolvere i problemi relativi alle istanze host. Nei progetti di migrazione, questo vantaggio in genere accelera l'iterazione (modifica, distribuzione, aggiornamento, convalida), migliora la collaborazione perché i flussi di lavoro sono più facili da rivedere e versione e supportano la separazione dell'ambiente più pulito esternalizzando le connessioni e le impostazioni, riducendo la deviazione della configurazione "funziona su tale server".

Connectors

I connettori forniscono operazioni che è possibile usare come procedura nei flussi di lavoro. Quando si creano flussi di lavoro con App per la logica di Azure, i connettori consentono di usare dati, eventi e risorse tra app, servizi, sistemi, protocolli e piattaforme spesso senza scrivere codice. È possibile creare soluzioni di integrazione per servizi e sistemi di Microsoft e partner, tra cui BizTalk Server, Salesforce, Office 365, IBM Mainframe, database SQL e molti servizi di Azure, ad esempio Funzioni di Azure, Archiviazione di Azure e bus di servizio di Azure, oltre ad app locali, SaaS e API. Se non esiste alcun connettore predefinito per la risorsa a cui si vuole accedere, è possibile usare l'operazione HTTP generica per comunicare con il servizio oppure creare un connettore personalizzato.

Tecnicamente, un connettore è un proxy o wrapper intorno a un'API utilizzata dal servizio o sistema sottostante per comunicare con Azure Logic Apps. I connettori offrono le funzionalità di connettività in App per la logica di Azure e un'astrazione oltre alle API che solitamente sono di proprietà del sistema SaaS sottostante. Per semplificare la chiamata a queste API, i connettori usano i metadati per descrivere il contratto di messaggistica in modo che gli sviluppatori sappiano quali dati sono previsti nella richiesta e nella risposta. Il connettore espone quindi le operazioni come trigger o azioni con proprietà configurabili. Alcuni trigger e azioni richiedono prima di tutto di creare e configurare una connessione al servizio o al sistema sottostante e autenticare l'accesso a un account utente.

La maggior parte dei connettori in Azure Logic Apps sono integrati o gestiti. Alcuni connettori sono disponibili in entrambe le versioni e la disponibilità dipende dal fatto che si crei un flusso di lavoro di app per la logica a consumo o standard. Per gli scenari di migrazione di BizTalk Server, i flussi di lavoro delle app per la logica Standard sono consigliati perché le funzionalità di migrazione di BizTalk sono disponibili a livello Standard.

Per molte migrazioni BizTalk, i connettori selezionati sono basati su requisiti di integrazione comuni, ad esempio connettività locale, trasferimento di file, ad esempio SFTP, sistemi di messaggistica e sistemi line-of-business.

• I connettori predefiniti vengono eseguiti nativamente nel runtime di Azure Logic Apps. Rispetto ai connettori gestiti, i connettori predefiniti in genere riducono la latenza ed evitano chiamate per connessione al servizio connettore gestito, a seconda del connettore e dello scenario.

• I connettori gestiti vengono distribuiti, ospitati e gestiti da Microsoft in Azure. Questi connettori forniscono trigger e azioni per i servizi cloud, i sistemi locali, o per entrambi.

Nella raccolta connettori della finestra di progettazione i connettori predefiniti vengono visualizzati sotto l'etichetta predefinita , mentre i connettori gestiti vengono visualizzati sotto l'etichetta Condiviso . Per i flussi di lavoro delle app per la logica a consumo, i connettori gestiti seguono il modello tariffario Standard o Enterprise.

• I connettori personalizzati consentono di eseguire il wrapping delle API REST, in genere usando una definizione OpenAPI o api SOAP usando un WSDL, quando non esiste alcun connettore predefinito. Se non esistono connettori predefiniti per le API da usare, è possibile creare un connettore personalizzato e accedere a tale connettore dai flussi di lavoro dell'app per la logica con le autorizzazioni appropriate.

Per le API REST, in genere si descrive l'API usando una definizione OpenAPI. Per le API SOAP, si usa un WSDL. Il connettore personalizzato crea un contratto tra App per la logica di Azure e l'API che consente di assemblare i messaggi di richiesta e ricevere risposte tipate che è possibile usare nelle azioni downstream. I connettori personalizzati possono fare riferimento a API pubbliche o API private, incluse le API nella rete locale.

Quando si implementa un connettore personalizzato, si fornisce un'interfaccia comune per l'invio di richieste e la ricezione di risposte tipate, semplificando l'esperienza di sviluppo.

Per altre informazioni, vedere:

• Panoramica dei connettori predefiniti
• Panoramica dei connettori gestiti
• Connettori gestiti disponibili in App per la logica di Azure
• API e connettori personalizzati

Modellazione dei dati e artefatti

Quando si esegue la migrazione delle integrazioni ad App per la logica di Azure, è in genere necessario quanto segue:

• Strutturazione dei dati nel flusso di lavoro, ad esempio analisi, composizione e mappatura.

• Una strategia chiara per l'archiviazione e la distribuzione di artefatti riutilizzabili, ad esempio schemi, mappe, modelli e assembly.

Le sezioni seguenti riepilogano le principali opzioni predefinite per le trasformazioni e le posizioni comuni in cui archiviare gli artefatti di supporto per i flussi di lavoro Standard e gli scenari B2B condivisi.

• Modellazione dei dati nei flussi di lavoro: operazioni sui dati, espressioni e modelli Liquid

  Per la maggior parte delle trasformazioni JSON nei flussi di lavoro dell'app per la logica, usare operazioni di dati predefinite, ad esempio le azioni Compose e Parse JSON, insieme alle espressioni e alle azioni di controllo del flusso di lavoro, ad esempio condizioni e cicli, per modellare i dati. Per scenari di mapping più avanzati, in particolare in cui si vuole un modello riutilizzabile per trasformazioni come JSON-to-JSON, JSON-to-text, XML-to-JSON o XML-to-text, è possibile usare un modello Liquid. I modelli liquid descrivono i mapping usando il linguaggio del modello Liquid open source. È possibile gestire le versioni e distribuire i modelli come artefatti insieme al flusso di lavoro.

• Operazioni XML basate su schema: analizzare XML e Compose XML

  Per gli scenari di creazione e convalida XML nei flussi di lavoro dell'app per la logica, è possibile usare operazioni XML predefinite, ad esempio Componi XML con schema e Analizza XML con azioni schema . Queste azioni sono le più utili quando è necessaria una gestione XML fortemente tipizzata (basata su XSD), anziché trattare il payload come testo normale. Ad esempio, sono necessari nomi di elementi coerenti, tipi di dati e struttura in più flussi di lavoro.

• Archiviare gli artefatti nelle app per la logica Standard

  Per i flussi di lavoro dell'app per la logica Standard, è possibile archiviare gli artefatti di integrazione nella risorsa dell'app per la logica stessa. Nel portale di Azure è possibile caricare mappe e schemi direttamente nella risorsa dell'app per la logica Standard. Se si lavora in Visual Studio Code, è possibile aggiungere schemi, mappe e modelli alle cartelle appropriate nella directory Artifacts del progetto e distribuirli insieme al flusso di lavoro. Questa funzionalità rende più facile mantenere gli artefatti nel controllo del codice sorgente.

  I processi di lavoro standard supportano la chiamata di assemblati compilati su misura, come gli assembly del .NET Framework, attraverso le mappe XSLT. Questo supporto consente di usare scenari di migrazione BizTalk basati sulla logica di trasformazione esistente.

• Archiviare gli artefatti B2B condivisi in un account di integrazione

  Un account di integrazione è una risorsa di Azure che fornisce accesso centralizzato agli artefatti B2B riutilizzabili e di integrazione che più flussi di lavoro possono condividere. Gli artefatti possono includere partner commerciali, contratti, schemi XSD, mappe XSLT, mappe basate su modelli liquid, certificati, configurazioni batch e assembly .NET Framework.

  In genere si usano gli account di integrazione in scenari B2B/EDI in cui si vuole un archivio di artefatti condivisi e regolamentati separato da qualsiasi singolo flusso di lavoro. Per i flussi di lavoro Standard, è spesso possibile evitare un account di integrazione tramite la creazione di pacchetti di schemi, mappe e modelli con il progetto di app per la logica Standard e distribuirli insieme. I flussi di lavoro standard supportano anche la chiamata di assembly .NET Framework dalle trasformazioni XSLT, il che può aiutare a portare le mappe BizTalk esistenti e le librerie di supporto. Se si preferisce un approccio basato su progetto, aggiungere schemi, mappe e assembly in Visual Studio Code e quindi distribuirlo in Azure.

• Schemi EDI: artefatti XSD specializzati per le integrazioni B2B

  Gli schemi di documento EDI definiscono la struttura o il corpo di un tipo di documento di transazione EDI. Nei progetti di migrazione BizTalk, i team spesso iniziano riutilizzando le stesse definizioni XSD e quindi convalidando in modo iterativo le varianti specifiche del partner commerciale. Per i flussi di lavoro in App per la logica di Azure, molti schemi EDI BizTalk nel repository GitHub di integrazione Microsoft sono disponibili pubblicamente per l'uso. In base all'approccio di implementazione, è possibile archiviare questi schemi insieme a un'app per la logica Standard come artefatti del progetto o centralmente in un account di integrazione per il riutilizzo in più flussi di lavoro.

Connectivity

Il modello di connettività in App per la logica di Azure è diverso da BizTalk Server, parzialmente a causa dell'evoluzione dell'economia dell'API. Considerato che sempre più organizzazioni espongono l'accesso ai sistemi e ai dati sottostanti, era necessario adottare un approccio indipendente dalla piattaforma. Attualmente, REST è l'approccio di architettura dominante per la progettazione di servizi Web moderni.

In App per la logica di Azure, REST è l'approccio predefinito per la connessione dei sistemi. Poiché Microsoft e altri fornitori di software espongono servizi RESTful sui propri sistemi e dati, App per la logica di Azure può esporre e utilizzare questo tipo di informazioni. La specifica OpenAPI rende possibile questa funzionalità per gli esseri umani e per i computer al fine di comprendere l'interazione tra un client e un server tramite i metadati. Nell'ambito di questa comprensione vengono derivati i payload di richiesta e di risposta; ciò significa che è possibile usare il contenuto dinamico per popolare gli input di un'azione del flusso di lavoro e utilizzare gli output della risposta nelle azioni downstream.

In base al fornitore di software che implementa il servizio sottostante chiamato da un connettore, gli schemi di autenticazione variano in base al connettore. Generalmente, questi schemi includono i tipi seguenti:

• Base
• Certificato client
• Active Directory OAuth
• Raw
• Identità gestita

Microsoft offre livelli di protezione avanzata mediante la crittografia dei dati durante il transito e quando sono inattivi. Quando il traffico dei clienti di Azure si sposta tra i data center, al di fuori dei limiti fisici non controllati da Microsoft o per conto di Microsoft, viene applicato un metodo di crittografia del livello di collegamento dati che si avvale dello Standard MAC IEEE 802.1AE (MACsec) da punto a punto, nell'hardware di rete sottostante.

Microsoft offre la possibilità di usare il protocollo Transport Layer Security (TLS) per proteggere i dati che viaggiano tra servizi cloud e clienti. I data center Microsoft negoziano una connessione TLS con i sistemi client che si connettono ai servizi di Azure. Il protocollo TLS offre capacità di autenticazione avanzata, privacy dei messaggi e integrità, abilitando il rilevamento di manomissioni, intercettazioni e falsificazioni dei messaggi, oltre che interoperabilità, flessibilità degli algoritmi e facilità di distribuzione e di utilizzo.

Anche se questa sezione è incentrata sulla connettività RESTful tramite i connettori, è possibile implementare la connettività del servizio Web SOAP tramite l'esperienza del connettore personalizzata o usando l'esperienza di Gestione API, che offre ottime funzionalità SOAP. Per altre informazioni, vedere Aumento del valore aziendale integrando asset legacy SOAP con App per la logica di Azure e Gestione API di Azure.

Durabilità dei messaggi

App per la logica di Azure assicura la durabilità dei messaggi nei modi seguenti:

• I flussi di lavoro con stato nelle app per la logica standard memorizzano lo stato del flusso di lavoro e gli input e gli output delle operazioni nell'archiviazione usando checkpoint. Questa persistenza offre un'esecuzione durevole e una cronologia di esecuzione avanzata del flusso di lavoro, in modo da poter esaminare gli input e gli output dettagliati dell'operazione.

• È possibile inviare nuovamente o rieseguire un flusso di lavoro nel portale di Azure o usando le API.

  Il rinvio potrebbe causare di nuovo l'elaborazione dello stesso messaggio da parte del flusso di lavoro, quindi assicurarsi che le progettazioni presuppongono almeno un'elaborazione e implementino l'idempotenza. Ad esempio, usare chiavi di deduplicazione, upsert o effetti eseguiti esattamente una volta nella destinazione finale.

  In base al tipo e alla configurazione del flusso di lavoro, è anche possibile inviare di nuovo da un punto specifico nell'esecuzione. Tuttavia, assicurarsi che i sistemi a valle possano gestire in sicurezza i nuovi tentativi e i potenziali duplicati.

• Con la messaggistica peek-lock nel bus di servizio di Azure, un ricevitore può elaborare un messaggio e quindi risolvere in modo esplicito il messaggio. Ad esempio, il ricevitore può completare il messaggio e quindi rimuoverlo dalla coda oppure il ricevitore può abbandonare il messaggio e renderlo disponibile per la riconsegna.

  Per usare questa funzionalità in App per la logica di Azure, usare il connettore del bus di servizio di Azure. La modalità peek-lock migliora l'affidabilità e supporta schemi di tentativo di ripetizione o ritrasmissione. Tuttavia, almeno un'elaborazione end-to-end richiede in genere l'idempotenza nei sistemi a valle.

• Con RabbitMQ, è in genere possibile ottenere la durabilità usando code durevoli o scambi insieme a messaggi persistenti e affidandosi ai riconoscimenti dei consumer in modo che il sistema possa recapitare i messaggi in caso di errore di elaborazione prima di inviare un riconoscimento. Quando si esegue l'integrazione utilizzando il connettore RabbitMQ, è necessario applicare lo stesso principio di progettazione degli altri broker: assumere la presenza di tentativi di ritrasmissione e potenziali duplicati, e far sì che l'elaborazione a valle sia idempotente.

• Con IBM MQ, in genere è possibile gestire la durabilità e il recapito affidabile usando messaggi persistenti ed elaborazione transazionale (unità di lavoro). È quindi possibile eseguire il commit o il rollback congiunto dei messaggi ricevuti e del lavoro a valle. Se si verifica un errore prima che il lavoro sia confermato o che un messaggio venga riconosciuto, il messaggio può diventare nuovamente disponibile per la ritrasmissione.

  Quando si usa il connettore IBM MQ, progettare almeno un recapito e gestire possibili duplicati alla destinazione. Negli scenari di migrazione BizTalk, questo modello viene in genere collegato alla progettazione del flusso di lavoro dell'app per la logica e agli endpoint a valle per garantire una rielaborazione sicura, ad esempio usando identificatori di correlazione, deduplicazione e operazioni di scrittura idempotenti, anziché affidarsi unicamente al broker per garantire almeno un comportamento end-to-end.

Architettura di pubblicazione-sottoscrizione

Rispetto al motore di messaggistica bizTalk Server, App per la logica di Azure usa connettori e servizi di messaggistica esterni per implementare modelli di messaggistica insieme all'orchestrazione del flusso di lavoro. Per i modelli publish-subscribe (pub-sub) con Azure Logic Apps, le opzioni di broker comuni includono Azure Service Bus (argomenti e sottoscrizioni) e RabbitMQ. Azure Service Bus è un broker di messaggi aziendale completamente gestito con code e argomenti di pubblicazione e sottoscrizione che è possibile usare per disaccoppiare applicazioni e servizi, offrendo i vantaggi seguenti:

• Bilanciare il carico di lavoro tra ruoli di lavoro in competizione.
• Instradare e trasferire i dati in modo sicuro con il controllo sui limiti del servizio e dell'applicazione.
• Coordinare le operazioni transazionali che richiedono un livello di affidabilità elevato.

App per la logica di Azure include un connettore del bus di servizio di Azure che può essere usato per la pubblicazione e la sottoscrizione di messaggi. Il vantaggio è che è possibile usare la messaggistica indipendentemente dal flusso di lavoro. A differenza di BizTalk Server, la messaggistica viene disaccoppiata dal motore del flusso di lavoro. È possibile creare sottoscrizioni di messaggi nel bus di servizio di Azure e usare le proprietà dei messaggi (proprietà utente) come coppie chiave-valore valutate dai filtri per una sottoscrizione di argomento. Queste proprietà utente vengono definite quando si configura un'operazione del bus di servizio di Azure aggiungendo una o più coppie chiave-valore. Per una dimostrazione, vedere il video: Pub Sub Messaging using Azure Integration Services - Part 2 Content Based Routing.

Azure Logic Apps con Flussi di lavoro Standard include anche un connettore RabbitMQ integrato che è possibile usare per inviare e ricevere messaggi. In RabbitMQ, si implementa in genere il modello pub-sub pubblicando su un exchange e facendo sì che più consumer ricevano messaggi tramite code separate collegate a tale exchange, spesso utilizzando chiavi di routing o routing basato su intestazioni, in base al tipo di exchange. Questo approccio supporta modelli di distribuzione basati sul fan-out e sul routing simili ad argomenti Bus di servizio e regole di sottoscrizione, ma configurati usando scambi, associazioni e impostazioni della coda di RabbitMQ. RabbitMQ è spesso una solida opzione quando si dispone di un ambiente RabbitMQ on-premises esistente, si necessitano di funzionalità di broker negli ambienti in cui il bus di servizio Azure non è disponibile, o si desidera mantenere la messaggistica locale all'interno della rete in cui operano il produttore e il consumatore. Come per qualsiasi integrazione basata su broker, progettare con attenzione ai tentativi di ripetizione e ai potenziali duplicati, ad esempio utilizzando riconoscimenti, code durevoli e messaggi persistenti dove appropriato, e assicurare che l'elaborazione a valle sia idempotente.

Per molti progetti di migrazione BizTalk, Azure Service Bus è la scelta predefinita per il pub-sub nativo del cloud perché il servizio è completamente gestito e fornisce semantica integrata di topic e sottoscrizioni con filtri. Per i requisiti pub-sub locali, RabbitMQ può essere una soluzione migliore, in particolare con il modello di distribuzione ibrida di Azure Logic Apps, perché Azure Service Bus è un servizio cloud e non ha un'opzione di distribuzione locale. In questi casi, standardizzare la semantica di durabilità e ripetizione dei tentativi e applicare l'idempotenza ai limiti del flusso di lavoro e dell'endpoint.

Motore regole di business

Azure Logic Apps include il Motore di Regole delle Azure Logic Apps. Questo motore regole include il runtime di BizTalk Business Rules Engine (BRE) in modo da poter usare il riutilizzo dei criteri BizTalk BRE esistenti. Attualmente, il supporto esiste solo per i fatti XML e .NET Framework.

Rete

Per la connettività in ingresso e in uscita, Azure offre diversi modi per isolare i servizi all'interno di un limite di rete e connettere carichi di lavoro locali e cloud. L'elenco seguente descrive i diversi modi in cui è possibile integrare le risorse di Azure con le risorse all'interno di un perimetro di rete:

• connessioni ibride

  Sia un servizio di Azure che una funzionalità nel servizio app di Azure, le connessioni ibride supportano scenari e offrono funzionalità oltre a quelle nel servizio app di Azure. Per altre informazioni sull'utilizzo all'esterno del Servizio app di Azure, vedere Connessioni ibride di Inoltro di Azure. Nel servizio app di Azure è possibile usare connessioni ibride per accedere alle risorse dell'applicazione in qualsiasi rete in grado di effettuare chiamate in uscita ad Azure sulla porta 443. Le connessioni ibride forniscono l'accesso dall'app a un endpoint TCP e non abilitano un nuovo modo per accedere all'app. Nel Servizio app di Azure, ogni connessione ibrida è correlata a una singola combinazione di host e porta TCP. Questa funzionalità consente alle app di accedere alle risorse in qualsiasi sistema operativo, purché sia presente un endpoint TCP. Le connessioni ibride non conoscono o ignorano il protocollo dell'applicazione o gli elementi a cui si desidera accedere. Questa funzionalità fornisce semplicemente l'accesso alla rete.

• Integrazione della rete virtuale

  L'integrazione della Rete virtuale di Microsoft Azure consente di connettere la risorsa di Azure a una rete virtuale configurata in Azure, concedendo all'app l'accesso alle risorse in tale rete virtuale. L'integrazione della rete virtuale in App per la logica di Azure viene usata solo per effettuare chiamate in uscita dalla risorsa di Azure alla rete virtuale.

  Con il peering di reti virtuali è possibile connettere le reti locali ad Azure che offre connettività bidirezionale tra le risorse locali e i servizi di Azure. I Servizi di integrazione di Azure forniscono la connettività di rete virtuale, consentendo l'integrazione ibrida.

  L'immagine seguente mostra una risorsa di app per la logica Standard con la pagina Rete aperta e l'integrazione della rete virtuale abilitata, come evidenziato nella casella Traffico in uscita. Questa configurazione garantisce che tutto il traffico in uscita esca da questa rete virtuale.

  

• Endpoint privati

  L'endpoint privato è un'interfaccia di rete che usa un indirizzo IP provato della rete virtuale. Questa interfaccia di rete si connette privatamente e in modo sicuro a una risorsa di Azure basata sul collegamento privato di Azure. Abilitando un endpoint privato, la risorsa di Azure viene inserita nella rete virtuale e si consente alle risorse nella rete di effettuare chiamate in ingresso alla risorsa di Azure.

Codice personalizzato

In App per la logica di Azure è possibile creare ed eseguire codice .NET nel flusso di lavoro dell'app per la logica Standard. A questo scopo, è necessario usare Visual Studio Code con l'estensione App per la logica di Azure (Standard).

Il connettore Operazioni codice inline fornisce le azioni denominate Execute JavaScript Code (Esegui codice JavaScript), Execute CSharp Script Code (Esegui codice CSharp) ed Execute PowerShell Code (Esegui codice PowerShell). È possibile usare queste azioni per aggiungere codice, che supporta input e output dinamici del contenuto. Il motore di App per la logica di Azure prevede che questo codice abbia tempi di esecuzione brevi. Al termine dell'esecuzione del codice, l'output è disponibile per le azioni downstream da usare nel flusso di lavoro.

Come accennato in precedenza, il supporto per la chiamata di assembly .NET Framework da una mappa XSLT è attualmente disponibile nei flussi di lavoro dell'app per la logica quando si caricano tali assembly in un account di integrazione. Questa funzionalità consente di supportare regole di trasformazione dei dati personalizzate. Per i flussi di lavoro delle app logiche Standard è possibile chiamare il codice .NET Framework da mappe XSLT senza un account di integrazione. È anche possibile aggiungere assembly e mappe a un progetto di app per la logica Standard in Visual Studio Code e successivamente distribuirlo in Azure. Per ulteriori informazioni, vedere supporto dell'assembly .NET Framework aggiunto alle trasformazioni XSLT di Azure Logic Apps (Standard).

Gruppi di applicazioni

In App per la logica di Azure è possibile includere ed eseguire più flussi di lavoro in una risorsa dell'app per la logica Standard, con conseguente relazione da 1 a molti. Se si usa localmente un progetto di app per la logica Standard in Visual Studio Code, la risorsa dell'app per la logica esegue il mapping su questo singolo progetto. Grazie a questo approccio, è possibile raggruppare facilmente e logicamente carichi di lavoro, codice ed artefatti correlati nello stesso progetto e distribuire il progetto come singola unità.

Le architetture cloud funzionano in modo diverso rispetto ai paradigmi basati su server come BizTalk. App per la logica di Azure (Standard) usa un modello pull per inserire codice e artefatti. Di conseguenza, copierai gli eventuali elementi aggiuntivi necessari nel tuo progetto per poi distribuirli insieme al tuo codice e altri artefatti. In alcuni casi, è consigliabile evitare di dover copiare il codice e gli artefatti necessari. In tal caso, questa funzionalità potrebbe essere trasformata in un servizio che si possa gestire separatamente, ma che sia in grado di effettuare chiamate da un flusso di lavoro.

Si supponga, ad esempio, di avere una trasformazione dei dati che l'organizzazione usi ampiamente. Anziché includere la mappa per la trasformazione in più progetti di app per la logica, è possibile implementare un'interfaccia che fornisca la trasformazione come servizio. In questo modo è possibile gestire il ciclo di vita del servizio separatamente dai progetti di app per la logica e chiamare tale servizio dai flussi di lavoro.

Con la possibilità di includere più flussi di lavoro in un progetto di app per la logica Standard, ci si potrebbe chiedere come organizzare tali flussi di lavoro all'interno di un progetto o più progetti. Solitamente la risposta dipende dai requisiti, ad esempio:

• Affinità del processo aziendale
• Monitoraggio e supporto end-to-end
• Sicurezza, controllo degli accessi in base al ruolo e isolamento della rete
• Prestazioni e criticità aziendali
• Georilevazione e ridondanza geografica

Per altre informazioni, vedere Organizzazione dei flussi di lavoro di app per la logica in App per la logica di Azure (Standard).

Sicurezza e governance

App per la logica di Azure supporta le funzionalità di sicurezza seguenti:

• Azure Key Vault (Archivio chiavi di Azure)

  Credenziali, segreti, chiavi API e certificati possono essere archiviati usando Azure Key Vault. In App per la logica di Azure è possibile accedere a queste informazioni usando il connettore Azure Key Vault ed escluderle dai log della piattaforma e dalla cronologia di esecuzione usando la funzionalità di input e output sicuri.

  Più avanti nella sezione Rilevamento, la guida descrive la funzionalità della cronologia di esecuzione che fornisce una riproduzione dettagliata dell'esecuzione di un flusso di lavoro. Sebbene App per la logica di Azure offra la proposta di valore di acquisire ogni input e output in un'esecuzione del flusso di lavoro, a volte si rende necessario gestire l'accesso ai dati sensibili in modo più granulare. È possibile configurare l'offuscamento per questi dati con la funzionalità di input e output sicuri su trigger e azioni, al fine di nascondere tale contenuto dalla cronologia di esecuzione e impedire, quindi, l'invio di tali dati a Monitoraggio di Azure, in particolare Log Analytics e Application Insights. L'immagine seguente mostra un risultato di esempio dell'abilitazione di input e output sicuri nella cronologia di esecuzione.

  

• Integrazione basata su OAuth

  Durante la creazione delle connessioni, la maggior parte dei connettori si avvale di questo tipo di autenticazione. Grazie a questo approccio, l'integrazione con molti servizi SaaS diventa semplice come fornire l'indirizzo di posta elettronica e la password. Gestione API di Azure supporta anche OAuth, pertanto i due servizi possono essere usati insieme se si fornisce uno schema di autenticazione unificato.

  Questa funzionalità non è disponibile in modo nativo in BizTalk Server.

• Identità gestite

  App per la logica di Azure (Standard) può autenticare l'accesso agli account di archiviazione usando un'identità gestita. Inoltre, alcuni connettori supportano l'uso di identità gestite per autenticare l'accesso alle risorse protette da Microsoft Entra ID. Se si usa un'identità gestita per autenticare la connessione, non sarà necessario fornire credenziali, segreti o token Microsoft Entra.

Gestione delle applicazioni e gestione degli accessi

Il portale di Azure è uno strumento comune usato dagli amministratori e dal personale addetto al supporto per visualizzare e monitorare l'integrità delle interfacce. Per App per la logica di Azure, questa esperienza include tracce di transazioni avanzate, disponibili tramite la cronologia di esecuzione. Sono anche disponibili i controlli degli accessi in base al ruolo granulari per gestire e limitare l'accesso alle risorse di Azure a vari livelli.

Immagazzinamento

App per la logica di Azure si basa su Archiviazione di Azure per archiviare e crittografare automaticamente i dati inattivi. Questa crittografia protegge i dati e consente di soddisfare gli obblighi di sicurezza e conformità dell'organizzazione. Per impostazione predefinita, Archiviazione di Azure usa chiavi gestite da Microsoft per crittografare i dati. Per altre informazioni, vedere Crittografia di Archiviazione di Azure per dati inattivi.

Quando si usa Azure Storage su portale di Azure, tutte le transazioni vengono eseguite tramite HTTPS. È anche possibile usare Archiviazione di Azure usando l'API REST di archiviazione su HTTPS. Per imporre l'uso del protocollo HTTPS quando si chiamano le API REST per accedere a oggetti negli account di archiviazione, abilitare l'opzione di trasferimento sicuro, obbligatoria per l'account di archiviazione.

Il modello di distribuzione ibrida di App per la logica di Azure (Standard) si basa su SQL Server. Questa dipendenza consente di usare gli ambienti SQL Server locali esistenti con BizTalk Server.

Elaborazione di file di grandi dimensioni

Esistono alcune differenze fondamentali tra l'elaborazione di file di grandi dimensioni con BizTalk Server rispetto ad App per la logica di Azure. Ad esempio, esaminare attentamente gli scenari con messaggi di grandi dimensioni per trovare la soluzione appropriata, infatti vi sono modi potenzialmente diversi per risolvere questo problema in un ambiente cloud moderno.

Limiti delle dimensioni dei file

In Azure esistono limiti relativi alle dimensioni dei file per garantire esperienze coerenti e affidabili. Per convalidare lo scenario, assicurarsi di esaminare la documentazione relativa ai limiti del servizio di App per la logica di Azure. Alcuni connettori supportano la suddivisione in blocchi dei messaggi in caso di superamento del limite di dimensioni predefinito per i messaggi, che è variabile a seconda del connettore. La suddivisione in blocchi dei messaggi prevede che un messaggio di grandi dimensioni venga suddiviso in messaggi più piccoli.

App per la logica di Azure non è l'unico servizio con limiti alle dimensioni dei messaggi. Ad esempio, anche il bus di servizio di Azure prevede tali limiti. Per altre informazioni sulla gestione dei messaggi di grandi dimensioni nel bus di servizio di Azure, vedere Supporto per messaggi di grandi dimensioni.

Per evitare le limitazioni alle dimensioni dei file, è possibile implementare il modello di controllo delle attestazioni che prevede la suddivisione di un messaggio di grandi dimensioni in un controllo delle attestazioni e in un payload. Il controllo delle attestazioni viene inviato alla piattaforma di messaggistica e il payload viene archiviato in un servizio esterno. In questo modo è possibile elaborare messaggi di grandi dimensioni proteggendo il bus di messaggi e il client dal sovraccarico. Questo modello consente anche di ridurre i costi, poiché l'archiviazione è in genere più economica rispetto alle unità di risorse usate dalla piattaforma di messaggistica.

Monitoraggio e avvisi

In App per la logica di Azure è possibile abilitare il supporto di Application Insights, che offre visualizzazioni curate come base per il monitoraggio dei servizi di Azure. Queste visualizzazioni consentono di monitorare in modo più efficace i flussi di lavoro Standard usando dashboard progettati specificamente per App per la logica di Azure (Standard). L'ambito del dashboard copre i flussi di lavoro all'interno di un'app per la logica Standard. Il dashboard è basato su Cartelle di lavoro di Azure e offre diverse visualizzazioni. È possibile estendere e personalizzare facilmente queste cartelle di lavoro per soddisfare esigenze specifiche.

Serverless 360 è una soluzione esterna di Kovai che offre capacità di monitoraggio e gestione tramite il mapping dei servizi di Azure, ad esempio App per la logica di Azure, bus di servizio di Azure, Gestione API di Azure e Funzioni di Azure. I messaggi possono essere rielaborati usando le code di messaggi non recapitabili nel bus di servizio di Azure, è possibile abilitare la riparazione automatica per risolvere interruzioni intermittenti del servizio e configurare il monitoraggio proattivo tramite transazioni sintetiche.

È possibile configurare regole di monitoraggio personalizzate e visualizzare i log in un'esperienza del portale. Le notifiche possono essere inviate tramite vari canali, ad esempio posta elettronica, Microsoft Teams e ServiceNow. Per determinare visivamente l'integrità delle interfacce, sono disponibili le mappe dei servizi.

Monitoraggio attività di business

Gli sviluppatori o gli analisti aziendali che lavorano su soluzioni che integrano servizi e sistemi usando varie risorse di Azure potrebbero avere difficoltà a visualizzare la relazione tra i componenti tecnici nella soluzione e lo scenario aziendale. Per includere il contesto aziendale sulle risorse di Azure nella soluzione, è possibile creare processi aziendali che rappresentino visivamente la logica di business implementata da queste risorse. In Rilevamento processi aziendali di Azure, un processo aziendale è una serie di fasi che rappresentano le attività che passano attraverso uno scenario aziendale reale.

Un'altra opzione consiste nell'uso di una soluzione esterna di Kovai denominata Serverless 360. Insieme alla piattaforma di monitoraggio è possibile usare la funzionalità di monitoraggio attività di business che fornisce il rilevamento end-to-end per i processi aziendali tra integrazioni native del cloud e ibride. Questa funzionalità include un connettore gestito che gli sviluppatori possono usare per instrumentare il codice e acquisire dati aziendali importanti. Successivamente, gli amministratori possono creare i dashboard e condividerli con gli analisti aziendali.

Rilevamento

Azure Logic Apps offre una cronologia avanzata delle esecuzioni del flusso di lavoro, in modo che gli sviluppatori e gli analisti del supporto possano esaminare i dati di telemetria passo per passo, inclusi tutti gli input e gli output elaborati. Per contribuire alla protezione dei dati sensibili, è possibile abilitare gli input e output sicuri per le singole azioni nei flussi di lavoro. Questa funzionalità offusca o nasconde i dati nei log e nelle cronologie di esecuzione del flusso di lavoro per evitare perdite.

Oltre all'offuscamento dei dati, è possibile usare le regole di Controllo degli accessi in base al ruolo di Azure per proteggere l'accesso ai dati. Il controllo degli accessi in base al ruolo di Azure include ruoli predefiniti specifici per App per la logica di Azure (Standard). Oltre al controllo degli accessi in base al ruolo di Azure, è possibile limitare l'accesso allo storico delle esecuzioni in App per la logica di Azure in base all'intervallo di indirizzi IP.

Servizi di hosting

• Piani di hosting

  Nelle Azure Logic Apps a tenant singolo, è possibile utilizzare un singolo piano del servizio Workflow per ospitare più app logiche Standard. Ciò significa che non è necessario distribuire tutti i flussi di lavoro in una singola risorsa dell'app per la logica Standard. È invece possibile organizzare questi flussi di lavoro in gruppi logici (app per la logica) per migliorare la gestione di altri aspetti della soluzione. Questo approccio consente di sfruttare al meglio il piano di servizio di flusso di lavoro e le applicazioni per il lungo termine, la cui implementazione prevede il ridimensionamento individuale.

  Un'app per la logica Standard prevede i piani tariffari seguenti: WS1, WS2 e WS3. A livello funzionale, ogni livello offre le stesse funzionalità. I requisiti per il calcolo e la memoria determinano il meglio per lo scenario, ad esempio:

  Piano tariffario	CPU virtuale (vCPU)	Memoria (GB)
  WS1	1	3,5
  WS2	2	7
  WS3	4	14

  Per altre informazioni, vedere Piani tariffari nel modello Standard.

• Modello di distribuzione ibrida

  App per la logica di Azure offre un modello di distribuzione ibrida che consente di distribuire e ospitare flussi di lavoro di app per la logica Standard in scenari locali, cloud privati o cloud pubblici. Questo modello offre le funzionalità per ospitare soluzioni di integrazione in ambienti parzialmente connessi quando è necessario usare l'elaborazione locale, l'archiviazione dei dati e l'accesso alla rete. Con l'opzione ibrida, si ha la libertà e la flessibilità di scegliere l'ambiente migliore per i flussi di lavoro. Per altre informazioni, vedere Configurare un'infrastruttura personalizzata per le app per la logica Standard usando la distribuzione ibrida.

• Disponibilità e ridondanza

  In Azure, le zone di disponibilità offrono resilienza, disponibilità distribuita e scalabilità della zona attiva-attiva. Per aumentare la disponibilità per i carichi di lavoro dell'app per la logica, è possibile abilitare il supporto della zona di disponibilità, ma solo quando si crea l'app per la logica. Sono richieste almeno tre zone di disponibilità separate in qualsiasi area di Azure che supporti e abiliti la ridondanza della zona. La piattaforma App per la logica di Azure distribuisce queste zone e i carichi di lavoro delle app per la logica al loro interno. Questa funzionalità è un requisito fondamentale per abilitare architetture resilienti e garantire una disponibilità elevata in caso di errori del data center in una determinata area. Per altre informazioni, vedere Creare soluzioni per la disponibilità elevata usando le zone di disponibilità.

• Ambiente isolato e dedicato

  Per le app per la logica Standard, un'opzione consente di selezionare un ambiente del servizio app v3 per l'ambiente di distribuzione. Con un ambiente del servizio app v3 si ottiene un ambiente completamente isolato e dedicato per eseguire applicazioni su larga scala e a prezzi prevedibili. Si paga solo per il piano di servizio app dell'ambiente del servizio app, indipendentemente dal numero di app per la logica create ed eseguite.

Per gli scenari che richiedono servizi di integrazione di Azure aggiuntivi, vedere la documentazione seguente:

• Livelli di messaggistica Standard e Premium del bus di servizio di Azure
• Gestione API di Azure - Confronto tra livelli basati sulle funzionalità

Distribuzione

Azure Logic Apps supporta l'infrastruttura come codice (IaC), offrendo la capacità di creare risorse di infrastruttura usando i modelli di gestione delle risorse di Azure. Sebbene i modelli ARM possano sembrare difficili da comprendere e si implementino come soluzione unificata, è possibile usare strumenti di astrazione, ad esempio Bicep, Terraform o Pulumi, che offrono un'esperienza simile al codice per creare la definizione dell'infrastruttura. Anche se questi strumenti forniscono livelli di astrazione sui modelli ARM, gli strumenti generano infine dei modelli ARM e possono distribuirli automaticamente.

Con l'infrastruttura in posizione, è possibile distribuire la logica che implementa i flussi di lavoro end-to-end. Poiché i Servizi di integrazione di Azure offrono una raccolta di strumenti per implementare i flussi di lavoro di integrazione, è necessario distribuire ogni componente. Per le soluzioni create con i Servizi di integrazione di Azure, le pipeline CI/CD si basano generalmente sulla distribuzione di un'orchestrazione di componenti. I responsabili DevOps possono usare azioni predefinite che astraggono le attività di distribuzione, oppure usano azioni generiche che eseguono i comandi dell'interfaccia della riga di comando o script di automazione, ad esempio PowerShell e Bash. Nella maggior parte dei casi, i tecnici personalizzano le pipeline in base alle esigenze dell'applicazione, esaminano le linee guida della documentazione ufficiale e usano i repository di esempio come punto di partenza.

La procedura per preparare ciascun componente per la distribuzione, solitamente prende in considerazione i passaggi seguenti:

• Fase di integrazione continua

  1. Ottenere la versione più recente del codice sorgente.

  2. Preparare il codice con la configurazione specifica dell'ambiente.

     I dettagli di questo passaggio dipendono dal supporto di ogni tecnologia per l'inserimento esterno di variabili di ambiente. La premessa di base è che le informazioni di configurazione basate sull'ambiente, ad esempio stringhe di connessione e riferimenti a risorse esterne, vengono astratte per fare riferimento a un repository delle impostazioni dell'applicazione. Pertanto, in questo scenario, è possibile archiviare i riferimenti che possono esistere come testo non crittografato direttamente nel repository delle impostazioni dell'applicazione, tuttavia è necessario archiviare i valori sensibili, ad esempio i segreti, come puntatori di riferimento alle voci in un archivio di segreti, ad esempio un insieme di credenziali delle chiavi di Azure.

     App per la logica di Azure rende possibile questo approccio per una risorsa dell'app per la logica Standard, supportando i riferimenti al repository delle impostazioni dell'applicazione; quindi è possibile eseguire il mapping delle coppie nome-valore rispetto alle voci nell'insieme di credenziali delle chiavi.

  3. Creare un pacchetto del codice per la distribuzione nei vari ambienti.

• Fase di distribuzione continua

  1. Distribuire il pacchetto del codice nell'ambiente di destinazione.

  2. Aggiornare il repository delle impostazioni dell'applicazione con i valori di ambiente corretti, o come testo non crittografato o come riferimenti alle voci nell'insieme di credenziali delle chiavi.

  3. Aggiornare le autorizzazioni necessarie che dipendono dal codice.

  4. Preparare l'applicazione per l'esecuzione, se necessario.

Corrispondenza delle funzionalità

La tabella e il diagramma seguenti illustrano come le risorse, gli artefatti, le funzionalità e le capacità si confrontano e si abbinano tra BizTalk Server, Azure Logic Apps (Standard) e altri servizi. Provare a usare le funzionalità di App per la logica di Azure il più possibile per creare una soluzione coesa e più conveniente.

Azure Logic Apps Standard (Cloud)

Azure Logic Apps Standard Hybrid (in locale)

Per restare aggiornati sugli investimenti più recenti, abbonarsi a Integrazioni sul blog di Azure - Tech Community.

Passaggi successivi

Si è appreso di più sul confronto tra App per la logica di Azure e BizTalk Server. Esaminare quindi gli approcci e le risorse suggeriti, le considerazioni sulla pianificazione e le procedure consigliate per la migrazione.