Informazioni sulla creazione di integrazioni asincrone resilienti

A volte potresti scoprire che le tue integrazioni sono fragili, incapaci di gestire anche brevi o temporanee interruzioni. La tua integrazione asincrona deve essere scalabile in modo efficiente e sono necessarie opzioni per sviluppare e testare tali integrazioni per garantire che funzionino come previsto nella produzione. Questa guida alle soluzioni presenta gli approcci suggeriti per la creazione di integrazioni asincrone resilienti alle realtà delle reti e delle infrastrutture moderne.

Ad esempio, quando si creano entità in un cloud finanziario utilizzando le API REST, potrebbero verificarsi interruzioni temporanee durante la creazione di note spese, conti bancari o altre entità. Per limitare dinamicamente tali richieste che colpiscono Financial Cloud, il modello di parcheggio viene discusso in questa guida. Con il modello di parcheggio, è possibile memorizzare i dati in una fase intermedia prima di elaborare i dati per evitare problemi di elaborazione quali batch, correlazione/flussi di messaggi complessi e limitazione.

Informazioni sulle integrazioni in Oracle Integration

Le integrazioni sono l'ingrediente principale di Oracle Integration. Un'integrazione include almeno una connessione trigger (origine) (per le richieste inviate a Oracle Integration) e una connessione di richiamo (destinazione) (per le richieste inviate da Oracle Integration alla destinazione) e il mapping dei campi tra queste due connessioni.

Quando si creano le integrazioni, si basano sulle connessioni già create definendo le modalità di elaborazione dei dati per le connessioni trigger (origine) e richiamo (destinazione). Ciò può includere la definizione del tipo di operazioni da eseguire sui dati, sui business object e sui campi in base ai quali eseguire tali operazioni, sugli schemi richiesti e così via. Per semplificare l'operazione, i task di configurazione più complessi vengono gestiti da Oracle Integration. Una volta configurate le connessioni trigger (origine) e richiamo (destinazione), i mapper tra i due vengono abilitati in modo da poter definire la modalità di trasferimento delle informazioni tra il trigger (origine) e le strutture dati richiamo (destinazione) sia per i messaggi di richiesta che per i messaggi di risposta.

Informazioni sul modello di parcheggio

Nel pattern del parcheggio, i dati vengono memorizzati in una fase intermedia prima del completamento dell'elaborazione dei dati dalla fase intermedia al sistema finale.

Ecco alcune delle possibili alternative per memorizzare i dati effettivi all'interno del parcheggio. Ogni opzione ha proprietà diverse che devono essere considerate:

L'approccio più semplice è quello di memorizzare i dati come CLOB in formato XML. Questo metodo aggiunge un ulteriore sovraccarico di scrittura e lettura del CLOB, nonché la trasformazione tra l'XML e il CLOB.
È possibile memorizzare i dati separatamente in altre tabelle con colonne completamente realizzate. Questo metodo è più appropriato se all'interno dell'applicazione il processo di de-batching sta già copiando il payload di input in un formato tabulare nella tabella del database. In modo che il formato dei dati possa essere utilizzato per il parcheggio.
Combinare il tavolo con il parcheggio stesso. Sebbene questa soluzione possa rivelarsi la più performante, può funzionare solo per strutture di dati semplici nel parcheggio.

Informazioni sulla resilienza

Prima di immergerti in ciò che renderà il tuo ambiente resiliente, devi prima definire cosa significa resilienza per te e la tua azienda.

In altre parole, qual è il costo associato a un'indisponibilità dei processi di integrazione? Per alcuni clienti, un'interruzione di alcuni minuti è perfettamente accettabile e ritarda solo parzialmente un processo batch che viene eseguito correttamente nella relativa finestra di elaborazione. Per altri, anche pochi secondi di interruzione comportano perdite finanziarie che hanno un impatto diretto sul business.

Da questa prospettiva, è importante esaminare i seguenti elementi:

Qual è la durata di un'indisponibilità accettabile nell'ambiente in uso? Qui è necessario definire il costo per l'azienda in caso di interruzione e delineare l'evoluzione di tale interruzione con la durata dell'interruzione.
Quali tecnologie vengono utilizzate e come possono soddisfare l'accordo sul livello di servizio previsto? Stai adottando un approccio in tempo reale o batch? O una combinazione dei due? Quanti dati vengono elaborati?