Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
App per la logica di Azure Standard aiuta le organizzazioni ad estendere e modernizzare incrementalmente i carichi di lavoro mainframe e midrange senza prima riscrivere i programmi host già esistenti o spostare tutta l'elaborazione su Azure. Utilizza flussi di lavoro e connettori integrati per esporre transazioni, dati, messaggi, file e applicazioni controllate dallo schermo esistenti ai consumatori moderni. Esegui il livello di integrazione in Azure, in ambiente del servizio app v3 (ASE v3) oppure su infrastrutture gestite dal cliente tramite la distribuzione ibrida in Kubernetes abilitato per Azure Arc.
I clienti che migrano da BizTalk Server possono preservare i metadati compatibili dell'integrazione host e utilizzare configurazioni di adattatori esistenti come input per nuove connessioni di connettori integrati. Questo approccio supporta la coesistenza graduale tra sistemi esistenti e modernizzati mentre i team spostano interfacce e capacità aziendali in ondate gestibili.
Valore del cliente
App per la logica di Azure Standard offre i seguenti vantaggi per la modernizzazione di sistemi mainframe e midrange:
| Obiettivo del cliente | valore di App per la logica di Azure Standard |
|---|---|
| Preservare i sistemi funzionanti | Riutilizzare programmi host esistenti, strutture dati, code, file e metadati compatibili modernizzando il livello di integrazione circostante. |
| Modernizzare in modo incrementale | Introdurre i flussi di lavoro come facciate di integrazione, spostare un'interfaccia o una capacità aziendale alla volta e mantenere operativi insieme i sistemi legacy e moderni durante la transizione. |
| Ridurre il codice di integrazione personalizzato | Usa flussi di lavoro visivi, connettori integrati, trasformazioni e codice con ambito di workflow invece di costruire ogni componente di integrazione da zero. |
| Scegli dove avviene l'elaborazione | Ospita i flussi di lavoro in Azure o eseguili su Kubernetes abilitati ad Arc vicino ai sistemi locali quando latenza, residenza dei dati o requisiti di rete favoriscono l'elaborazione locale. |
| Supporta diverse caratteristiche di carico di lavoro | Usa flussi di lavoro con stato per processi duraturi e di lunga durata, e workflow senza stato per un elaborazione in memoria a bassa latenza quando la persistenza non è necessaria. |
| Adottare pratiche moderne di consegna | Archivia definizioni di flusso di lavoro, configurazioni, metadati e il codice di supporto nel controllo del codice sorgente e utilizza pipeline automatizzate di compilazione e distribuzione. |
App per la logica di Azure Standard è il runtime principale di orchestrazione e integrazione per la soluzione. Altri servizi di messaggistica, gestione API, distribuzione eventi, database o servizi gestiti dal cliente non sono necessari di default. Aggiungili solo quando l'architettura rifattorizzata richiede una capacità indipendente, un confine di scala, un ciclo di vita o un modello di proprietà.
Perché usare App per la logica di Azure Standard
Standard offre funzionalità adatte all'integrazione con il sistema host che non sono tutte disponibili contemporaneamente nel tipo di risorsa Consumption:
- I connettori integrati, basati su provider di servizi, vengono eseguiti con il runtime di App per la logica di Azure e consentono l'accesso diretto ai sistemi mainframe e midrange supportati.
- Un'app di logica standard può contenere molteplici flussi di lavoro correlati che condividono confini di calcolo, archiviazione, rete, configurazione e distribuzione.
- I flussi di lavoro con stato e senza stato supportano processi durevoli e scenari richiesta-risposta a bassa latenza.
- I flussi di lavoro Standard ospitati su Azure supportano l'integrazione di rete virtuale e endpoint privati per l'accesso ai sistemi privati.
- Il deployment ibrido gestisce flussi di lavoro e operazioni di collegamento integrate su infrastrutture gestite dal cliente.
- Lo sviluppo con Visual Studio Code supporta test in locale, controllo del codice sorgente e CI/CD.
App per la logica di Azure Standard fornisce implementazioni cloud-native di molte funzionalità di integrazione core storicamente fornite da Host Integration Server (HIS), incluso l'accesso a programmi di transazione IBM, sistemi di messaggistica, database, file host e applicazioni 3270. Alcuni protocolli e scenari, come la connettività LU6.2, continuano a richiedere HIS.
Scegli dove eseguire i flussi di lavoro
I connettori integrati mainframe e midrange in questo articolo sono supportati con ogni opzione di hosting Standard. Scegli l'opzione che soddisfa i requisiti del carico di lavoro per la proprietà dell'infrastruttura, l'isolamento, la connettività, la latenza e la localizzazione dei dati.
| Opzione di hosting | Soluzione ottimale | Considerazioni principali |
|---|---|---|
| Piano di servizi per il flusso di lavoro | Hosting Azure gestito per flussi di lavoro che si collegano ai sistemi host tramite percorsi di rete privati o pubblici. | Utilizza capacità riservata di WS1, WS2 o WS3 e supporta l'integrazione di rete virtuale, endpoint privati e monitoraggio Azure. |
| ambiente del servizio app v3 | Carichi di lavoro ospitati su Azure che richiedono isolamento dedicato, networking, confini di conformità o consolidamento con altri carichi di lavoro App Service. | Richiede un ASE v3 e un piano di servizi App Isolated v2. |
| Ibrido | Elaborazione locale, residenza dei dati, accesso a bassa latenza ai sistemi host o infrastrutture gestite dal cliente. | Funziona su Kubernetes abilitato per Azure Arc e richiede Kubernetes, SQL Server, archiviazione SMB, rete, scalabilità e operazioni gestiti dal cliente. |
La distribuzione ibrida è parzialmente connessa, non in un ambiente isolato. Le operazioni di connettore integrate si seguono con l'runtime locale di App per la logica di Azure, mentre la gestione Azure e qualsiasi connettore gestito ospitato nel cloud richiedono connettività in uscita. Per i requisiti e le limitazioni attuali dell'infrastruttura, vedi Configura la tua infrastruttura per app di logica standard usando un deployment ibrido.
Preservare gli investimenti di integrazione esistenti
Per decenni, Microsoft ha fornito funzionalità di integrazione mainframe e midrange tramite Microsoft Host Integration Server. App per la logica di Azure Standard si basa su questa esperienza con strumenti guidati dai metadati e connettori che aiutano a preservare gli investimenti applicativi esistenti.
Microsoft HIS Designer per App per la logica di Azure
Questo strumento Visual Studio crea i metadati XML del Host Integration Designer (HIDX) che i connettori App per la logica di Azure utilizzano per interagire con programmi mainframe e midrange e strutture dati. Il graphic designer ti permette di creare, visualizzare, modificare e mappare interfacce di programma, metodi, parametri, record e tipi di dati. Puoi anche importare i copybook COBOL e RPG. Per maggiori informazioni, consulta HIS Designer for App per la logica di Azure.
Strumento di progettazione di Microsoft 3270
Questo strumento registra schermate, percorsi di navigazione, metodi e parametri per i compiti in un'applicazione 3270. Lo strumento genera metadati HIDX che il connettore IBM 3270 utilizza per eseguire il piano di navigazione registrato. Per altre informazioni, vedere Strumento di progettazione 3270.
Migra integrazioni tra sistema host e sistema BizTalk
Se le tue applicazioni BizTalk Server utilizzano adattatori per i sistemi host, puoi utilizzare molti artefatti e dettagli di configurazione esistenti per accelerare la migrazione verso App per la logica di Azure Standard:
- Riutilizzare i metadati HIDX compatibili con i connettori integrati CICS, IMS, IBM i, IBM 3270 e IBM Host File.
- Utilizza i copybook esistenti di COBOL e RPG per creare o aggiornare i metadati HIDX.
- Usa l'App per la logica di Azure Migration Agent per scoprire artefatti BizTalk supportati, inclusi binding, configurazioni degli endpoint e file HIDX, e utilizzali durante analisi, pianificazione e conversione.
Le impostazioni esistenti non vengono trasferite come connessioni di App per la logica di Azure distribuibili senza verifica. Ricrea la configurazione, le credenziali, i certificati e le impostazioni di rete specifiche dell'ambiente di hosting di destinazione e convalida il comportamento risultante. Le integrazioni BizTalk che dipendono da LU6.2 richiedono rifattorizzazione o riprogettazione. Per maggiori informazioni, consulta Migrate BizTalk Server con App per la logica di Azure Migration Agent.
Associare gli asset esistenti ai connettori integrati
I seguenti connettori integrati, basati sul provider di servizi, funzionano con l'esecuzione Standard. Alcuni connettori hanno anche versioni gestite che girano in Azure globale, ma questo articolo si concentra sulle versioni integrate.
| Asset o integrazione esistente | App per la logica di Azure Percorso standard di modernizzazione | Investimenti da preservare |
|---|---|---|
| Applicazione IBM 3270 | Usa il connettore IBM 3270 per eseguire la navigazione su schermo registrata su un flusso di dati TN3270. Questa opzione si adatta ad applicazioni che non forniscono un'interfaccia a livello di programma. | Metadati di navigazione HIDX e requisiti di connessione TN3270. Vedi Integra applicazioni IBM 3270. |
| Programma di transazioni CICS | Utilizzare il connettore CICS Program Call per esporre le transazioni esistenti a flussi di lavoro e applicazioni moderne su TCP/IP o HTTP. Usa HIS quando è necessario LU6.2. | Metadati HIDX, copybook e requisiti di connessione all'host e a CICS. Vedi Integra i programmi CICS. |
| database di IBM DB2 | Utilizzare il connettore IBM DB2 per leggere e modificare i database DB2 supportati direttamente su TCP/IP senza un gateway dati on-premise. | Requisiti di server, database, pacchetto, code page e autenticazione. Vedi Collegati alle risorse IBM DB2. |
| File di host IBM | Usa il connettore IBM Host File per analizzare contenuti binari in dati strutturati o generare contenuti binari di file host. Il connettore non richiede una connessione diretta con l'host. | Layout HIDX, copybook e informazioni sulle pagine dei codici. Vedi Analizzare e generare file host di IBM. |
| IBM i COBOL o programma RPG | Utilizzare il connettore IBM i Program Call per riutilizzare la logica di business consolidata tramite il server Distributed Program Calls su TCP/IP. Usa HIS quando è necessario LU6.2. | I metadati HIDX, i copybook e i requisiti di connessione di IBM i. Consulta Integrare i programmi IBM i. |
| Programma di transazione IMS | Usa il connettore IMS Program Call per chiamare programmi tramite IMS Connect tramite TCP/IP. Dietro le quinte, IMS Connect utilizza code di messaggi IMS per instradare richieste e risposte. | Metadati HIDX, copybook e impostazioni di IMS Connect. Vedi Integra i programmi IMS. |
| Messaggistica IBM MQ | Usa il connettore IBM MQ per collegare code e messaggi esistenti a moderni processi di flusso di lavoro. | Requisiti di gestione della coda, canale, coda, TLS e formato dei messaggi. Vedi Connetti a IBM MQ. |
Modernizzare in modo incrementale
Gli ambienti mainframe e midrange spesso contengono programmi, dati, file, scheduler e interfacce esterne strettamente connessi. Una singola migrazione “big-bang” prevede di sostituire l’ambito selezionato con un unico rilascio coordinato. Questo approccio può adattarsi a un ambiente piccolo e ben compreso, ma il rischio di consegna e cambio aumenta con il numero di dipendenze e la durata del progetto.
Per la maggior parte degli ambienti, usa ondate successive per preservare il funzionamento esistente e generare valore più rapidamente:
- Inventario di programmi, dati, interfacce, lavori, dipendenze, obiettivi di servizio e requisiti operativi.
- Seleziona un flusso di integrazione end-to-end con chiaro valore aziendale e dipendenze gestibili.
- Introdurre App per la logica di Azure Standard come facciata di integrazione mentre il sistema host rimane operativo.
- Riutilizza i metadati compatibili e configura i connettori integrati richiesti.
- Testare il comportamento funzionale, la produttività, il recupero, la sicurezza e la coesistenza con l'implementazione legacy.
- Reindirizza i consumatori all'interfaccia modernizzata e monitora il flusso di produzione.
- Ripetere l'operazione per i cicli successivi e ritirare le interfacce legacy solo dopo che i relativi utenti e le dipendenze siano stati spostati.
Ogni ondata può fornire una caratteristica o un gruppo correlato di flussi di integrazione. I job condivisi e le applicazioni altamente interconnesse potrebbero rimanere fino a ondate successive, dopo che interfacce a rischio inferiore avranno stabilito flussi di lavoro, sicurezza, distribuzione e modelli operativi riutilizzabili.
Applicare i modelli di modernizzazione
Usa i pattern architettonici in base al carico di lavoro target invece di trattare un singolo pattern come obbligatorio.
Modello di livello anti-danneggiamento
Considera l'uso di App per la logica di Azure Standard come livello anticorruzione tra le interfacce legacy e i consumatori moderni. I flussi di lavoro possono tradurre protocolli, formati e modelli di interazione senza richiedere ai consumatori di comprendere i dettagli specifici dell'host. Il livello façade può essere eseguito in Azure o su Kubernetes abilitato per Arc in prossimità dell'ambiente host.
Per altre informazioni, vedere il pattern del livello anticorruzione.
Modello Strangler Fig
Usa il pattern Strangler Fig per instradare interfacce o capacità selezionate attraverso il nuovo livello di integrazione mentre il carico di lavoro rimanente continua a essere eseguito sull'host. Sostituire le implementazioni gradualmente, convalidare ogni passaggio e dismettere i componenti legacy solo dopo che le relative dipendenze sono state migrate.
Per altre informazioni, vedere pattern Strangler Fig.
Modelli Saga e Choreography
Usa il modello Saga quando un processo aziendale attraversa sistemi che non possono partecipare a una sola transazione distribuita. Un workflow con stato può fungere da orchestratore centrale della saga coordinando i partecipanti e gestendo esplicitamente ritentativi, errori e azioni compensative. Ogni partecipante esegue la propria transazione locale. Le azioni del workflow non sono automaticamente atomiche come gruppo, e App per la logica di Azure non annulla automaticamente le modifiche nei sistemi esterni. Progettare le operazioni in modo che siano idempotenti e implementare la logica di compensazione utilizzando azioni, ambiti e condizioni di run-after.
In una saga basata sulla coreografia, i servizi partecipanti scambiano eventi tramite infrastrutture di messaggistica senza un flusso di lavoro centrale che coordini l'intera transazione. Aggiungi servizi come bus di servizio di Azure o Griglia di eventi di Azure solo quando l'architettura richiede messaggistica indipendente o distribuzione di eventi. Per maggiori informazioni, vedi il pattern delle transazioni distribuite Saga e il pattern Choreography.
Sicurezza del piano, operazioni e costi
- Utilizzare la connettività di rete privata e un'autenticazione sicura adeguata all'ambiente di hosting e al sistema host. Memorizza i segreti in archivi segreti approvati invece che nelle definizioni del flusso di lavoro.
- Mantieni le definizioni del flusso di lavoro, i file HIDX, i modelli di configurazione e il codice di supporto nel sistema di controllo del codice sorgente. Separare i valori specifici dell'ambiente dagli artefatti distribuibili e utilizzare pipeline automatizzate.
- Progettare tenendo conto dei nuovi tentativi e dell'elaborazione almeno una volta. Usa idempotenza, deduplicazione, identificatori di correlazione e scritture sicure per prevenire effetti duplicati.
- Definisci monitoraggio, allerta, ritenzione della cronologia di esecuzione, recupero in caso di disastri e proprietà del supporto prima del taglio della produzione. Le implementazioni Azure ospitate e ibride hanno capacità di monitoraggio e limitazioni differenti.
- Confronta il costo totale di proprietà tra hosting, utilizzo dei connettori, reti, storage, monitoraggio e infrastruttura gestita dal cliente. Il piano Standard include esecuzioni di operazioni integrate, mentre le operazioni dei connettori gestiti e le risorse di supporto possono comportare costi aggiuntivi.
Per i limiti e i prezzi attuali, consulta Azure Logic Apps limits and configuration e App per la logica di Azure pricing and billing models.
Esempi di scenari di modernizzazione
Esporre una transazione CICS a un'applicazione moderna
Crea un flusso di lavoro Standard che richiami un programma CICS esistente tramite il connettore integrato, trasformi la risposta e restituisca un'interfaccia moderna a un livello applicativo o API. Mantenere il programma CICS come sistema di record mentre i consumer abbandonano la connettività specifica per l'host.
Rendere i dati DB2 disponibili all'analisi
Utilizza un flusso di lavoro Standard per leggere i dati operativi approvati da DB2, validare e trasformare i record e inviarli a un servizio dati o di analisi Azure. Questo approccio evita di creare un programma di estrazione mainframe separato per ogni consumatore, preservando la governance su quando e come i dati escono dall'host.
Esegui l'integrazione vicino ai sistemi host
Distribuisci App per la logica di Azure Standard su Kubernetes abilitato Azure Arc quando i flussi di lavoro necessitano di elaborazione locale, residenza dati o accesso a bassa latenza ai sistemi IBM. Le operazioni di connettore integrate si seguono con l'runtime locale, mentre il workflow può connettersi selettivamente ai servizi Azure quando l'architettura e la policy di rete lo consentono.
Passaggi successivi
- Creare flussi di lavoro Standard con Visual Studio Code
- Configurare un'infrastruttura di implementazione ibrida
- Rivedi i connettori integrati per i flussi di lavoro Standard
- Migra BizTalk Server con App per la logica di Azure Migration Agent
- Esplora le linee guida di Azure Architecture Center per mainframe e sistemi di fascia media