Configurare il ripristino di emergenza tra aree per gli account di integrazione in App per la logica di Azure
Si applica a: App per la logica di Azure (consumo + Standard)
I carichi di lavoro B2B coinvolgono le transazioni di denaro, come ad esempio gli ordini e le fatture. In caso di un evento di emergenza, per un'azienda è essenziale eseguire rapidamente un ripristino per soddisfare i contratti di servizio a livello di business secondo gli accordi presi con i partner. In questo articolo viene illustrato come creare un piano di continuità aziendale per i carichi di lavoro B2B.
- Preparazione al ripristino di emergenza
- Eseguire il failover all'area secondaria durante un evento di emergenza
- Eseguire il failover all'area primaria dopo un evento di emergenza
Preparazione al ripristino di emergenza
Identificare un'area secondaria e crearvi un account di integrazione.
Aggiungere partner, schemi e contratti per i flussi di messaggi richiesti dove lo stato di esecuzione deve essere replicato nell'account di integrazione dell'area secondaria.
Suggerimento
Assicurare la coerenza degli elementi dell'account di integrazione secondo la convenzione di denominazione nelle aree.
Per eseguire il pull dello stato di esecuzione dall'area primaria, creare un'app per la logica nell'area secondaria,
che deve avere un trigger e un'azione. Il trigger deve connettersi all'account di integrazione dell'area primaria, mentre l'azione deve connettersi all'account di integrazione dell'area secondaria. In base all'intervallo di tempo, il trigger esegue il sondaggio della tabella sullo stato di esecuzione dell'area primaria ed esegue il pull dei nuovi record, se presenti. L'azione li aggiorna nell'account di integrazione dell'area secondaria. Questa operazione consente di ottenere lo stato di runtime incrementale dall'area primaria a quella secondaria.
La continuità aziendale nell'account di integrazione delle app per la logica è pensata per il supporto basato sui protocolli B2B - X12, AS2 ed EDIFACT. Per trovare la procedura dettagliata, selezionare i rispettivi collegamenti.
Si consiglia di distribuire tutte le risorse dell'area primaria anche in un'area secondaria.
Le risorse dell'area primaria includono il database SQL di Azure o Azure Cosmos DB, il bus di servizio di Azure e Hub eventi di Azure usati per la messaggistica, Gestione API di Azure e la funzionalità App per la logica di Azure di Servizio app di Azure.
Stabilire una connessione dall'area primaria a quella secondaria. Per eseguire il pull dello stato di esecuzione dall'area primaria, creare un'app per la logica nell'area secondaria,
che deve avere un trigger e un'azione. Il trigger deve connettersi all'account di integrazione dell'area primaria, mentre l'azione deve connettersi all'account di integrazione dell'area secondaria. In base all'intervallo di tempo, il trigger esegue il sondaggio della tabella sullo stato di esecuzione dell'area primaria ed esegue il pull dei nuovi record, se presenti. L'azione li aggiorna nell'account di integrazione dell'area secondaria. Questa operazione consente di ottenere lo stato di runtime incrementale dall'area primaria a quella secondaria.
La continuità aziendale nell'account di integrazione delle app per la logica offre il supporto basato sui protocolli B2B X12, AS2 ed EDIFACT. Per informazioni dettagliate sull'uso di X12 e AS2, vedere X12 e AS2 in questo articolo.
Eseguire il failover all'area secondaria durante un evento di emergenza
Durante un evento di emergenza, quando l'area primaria non è disponibile per la continuità aziendale, dirigere il traffico verso l'area secondaria. Un'area secondaria consente a un'azienda di ripristinare rapidamente le funzioni per soddisfare gli RPO/RTO concordati con i partner. Riduce al minimo gli sforzi per il failover da un'area a un'altra.
Esiste una latenza prevista durante la copia dei numeri di controllo dall'area primaria a quella secondaria. Per evitare l'invio ai partner di doppioni di numeri di controllo generati durante un evento di emergenza, è consigliabile incrementare i numeri di controllo negli accordi dell'area secondaria usando i cmdlet di PowerShell.
Eseguire il fallback all'area primaria dopo un evento di emergenza
Per eseguire il fallback a un'area primaria quando è disponibile, seguire questa procedura:
Interrompere l'accettazione dei messaggi dai partner nell'area secondaria.
Incrementare i numeri di controllo generati per tutti i contratti dell'area primaria usando i cmdlet di PowerShell.
Indirizzare il traffico dall'area secondaria all'area primaria.
Controllare che l'app per la logica creata nell'area secondaria per il pull dello stato di esecuzione dall'area primaria sia abilitata.
X12
La continuità aziendale per i documenti EDI X12 si basa sui numeri di controllo:
Suggerimento
È anche possibile usare il modello di avvio rapido X12 per creare app per la logica. La creazione degli account di integrazione primari e secondari è un prerequisito per l'uso del modello. Il modello consente di creare 2 app per la logica, una per i numeri di controllo ricevuti e l'altra per i numeri di controllo generati. I trigger e le azioni corrispondenti vengono creati nelle app per la logica collegando il trigger all'account di integrazione primario e l'azione a quello secondario.
Prerequisiti
Per abilitare il ripristino di emergenza per i messaggi in ingresso, selezionare le impostazioni per la verifica dei duplicati nelle impostazioni di ricezione dell'accordo X12.
Creare un flusso di lavoro dell'app per la logica di consumo di esempio in un'area secondaria.
Cercare in X12 e selezionare X12 - Quando viene modificato un numero di controllo.
Il trigger richiede di stabilire una connessione con l'account di integrazione. Il trigger deve connettersi all'account di integrazione dell'area primaria.
Inserire un nome di connessione, selezionare l'account di integrazione dell'area primaria dall'elenco e scegliere Crea.
L'impostazione DateTime per avviare la sincronizzazione dei numeri di controllo è facoltativa. Il campo Frequenza può essere impostato su Giorno, Ora, Minuto o Secondo con un intervallo.
Selezionare Nuovo passaggio>Aggiungi un'azione.
Cercare in X12 e selezionare X12 - Aggiungi o aggiorna numeri di controllo.
Per connettere un'azione a un account di integrazione dell'area secondaria, selezionare Modifica connessioneAggiungi nuova connessione> per un elenco degli account di integrazione disponibili. Inserire un nome di connessione, selezionare l'account di integrazione dell'area secondaria dall'elenco e scegliere Crea.
Passare agli input non elaborati facendo clic sull'icona nell'angolo in alto a destra.
Selezionare Corpo nell'utilità di selezione del contenuto dinamico e salvare l'app per la logica.
In base all'intervallo di tempo, il trigger esegue il sondaggio della tabella dei numeri di controllo ricevuti dell'area primaria ed esegue il pull dei nuovi record. L'azione aggiorna i record nell'account di integrazione dell'area secondaria. Se non ci sono aggiornamenti disponibili, lo stato del trigger appare come Ignorato.
In base all'intervallo di tempo, lo stato di runtime incrementale viene replicato dall'area primaria a quella secondaria. Durante un evento di emergenza, quando l'area primaria non è disponibile, dirigere il traffico verso l'area secondaria per assicurare la continuità aziendale.
EDIFACT
La continuità aziendale per i documenti EDI EDIFACT si basa sui numeri di controllo.
Prerequisiti
Per abilitare il ripristino di emergenza per i messaggi in ingresso, selezionare le impostazioni per la verifica dei duplicati nelle impostazioni di ricezione dell'accordo EDIFACT.
Creare un flusso di lavoro dell'app per la logica di consumo di esempio in un'area secondaria.
Cercare in EDIFACT e selezionare EDIFACT - Quando viene modificato un numero di controllo.
Il trigger richiede di stabilire una connessione con l'account di integrazione. Il trigger deve connettersi all'account di integrazione dell'area primaria.
Inserire un nome di connessione, selezionare l'account di integrazione dell'area primaria dall'elenco e scegliere Crea.
L'impostazione DateTime per avviare la sincronizzazione dei numeri di controllo è facoltativa. Il campo Frequenza può essere impostato su Giorno, Ora, Minuto o Secondo con un intervallo.
Selezionare Nuovo passaggio>Aggiungi un'azione.
Cercare in EDIFACT e selezionare EDIFACT - Aggiungi o aggiorna numeri di controllo.
Per connettere un'azione a un account di integrazione dell'area secondaria, selezionare Modifica connessioneAggiungi nuova connessione> per un elenco degli account di integrazione disponibili. Inserire un nome di connessione, selezionare l'account di integrazione dell'area secondaria dall'elenco e scegliere Crea.
Passare agli input non elaborati facendo clic sull'icona nell'angolo in alto a destra.
Selezionare Corpo nell'utilità di selezione del contenuto dinamico e salvare l'app per la logica.
In base all'intervallo di tempo, il trigger esegue il sondaggio della tabella dei numeri di controllo ricevuti dell'area primaria ed esegue il pull dei nuovi record. L'azione aggiorna i record per l'account di integrazione dell'area secondaria. Se non ci sono aggiornamenti disponibili, lo stato del trigger appare come Ignorato.
In base all'intervallo di tempo, lo stato di runtime incrementale viene replicato dall'area primaria a quella secondaria. Durante un evento di emergenza, quando l'area primaria non è disponibile, dirigere il traffico verso l'area secondaria per assicurare la continuità aziendale.
AS2
La continuità aziendale per i documenti che usano il protocollo AS2 si basai sull'ID di messaggio e sul valore MIC.
Suggerimento
È anche possibile usare il modello di avvio rapido AS2 per creare le app per la logica. La creazione degli account di integrazione primari e secondari è un prerequisito per l'uso del modello. Il modello consente di creare un'app per la logica, con un trigger e un'azione. L'app per la logica crea una connessione tra il trigger e l'account di integrazione primario e tra l'azione e l'account di integrazione secondario.
Creare un flusso di lavoro dell'app per la logica di consumo di esempio nell'area secondaria.
Cercare in AS2 e selezionare AS2 -When a MIC value is created (AS2 - Quando viene creato un valore MIC).
Il trigger richiede di stabilire una connessione con l'account di integrazione. Il trigger deve connettersi all'account di integrazione dell'area primaria.
Inserire un nome di connessione, selezionare l'account di integrazione dell'area primaria dall'elenco e scegliere Crea.
L'impostazione DateTime per avviare la sincronizzazione del valore MIC è facoltativa. Il campo Frequenza può essere impostato su Giorno, Ora, Minuto o Secondo con un intervallo.
Selezionare Nuovo passaggio>Aggiungi un'azione.
Cercare in AS2 e selezionare AS2 - Add or update MIC contents (AS2 - Aggiungi o aggiorna contenuti MIC).
Per connettere un'azione a un account di integrazione secondario, selezionare Modifica connessioneAggiungi nuova connessione> per un elenco degli account di integrazione disponibili. Inserire un nome di connessione, selezionare l'account di integrazione dell'area secondaria dall'elenco e scegliere Crea.
Passare agli input non elaborati facendo clic sull'icona nell'angolo in alto a destra.
Selezionare Corpo nell'utilità di selezione del contenuto dinamico e salvare l'app per la logica.
In base all'intervallo di tempo, il trigger esegue il sondaggio della tabella dell'area primaria ed esegue il pull dei nuovi record. L'azione li aggiorna nell'account di integrazione dell'area secondaria. Se non ci sono aggiornamenti disponibili, lo stato del trigger appare come Ignorato.
In base all'intervallo di tempo, lo stato di runtime incrementale viene replicato dall'area primaria a quella secondaria. Durante un evento di emergenza, quando l'area primaria non è disponibile, dirigere il traffico verso l'area secondaria per assicurare la continuità aziendale.
Passaggi successivi
Monitorare i messaggi B2B con i log di Monitoraggio di Azure