Progetta per la resilienza utilizzando Oracle Integration

Utilizza queste best practice durante la progettazione delle integrazioni resilienti.

Integrazioni progettazione

Di seguito è riportato un flusso di integrazione in entrata di base che riceve le richieste da un'applicazione a monte tramite un'API REST, analizza, convalida e le invia all'applicazione a valle.

Potrebbe verificarsi un caso in cui l'applicazione a valle non risponde quando l'applicazione a monte invia richieste. Queste richieste non saranno riconosciute dal downstream. Ci saranno molte sfide di elaborazione come batch, correlazione/flussi di messaggi complessi e limitazione.

Di seguito è riportato un esempio di creazione di entità in Oracle Financials Cloud mediante le API REST. Le richieste devono essere ricevute da un endpoint REST di integrazione. Dovresti essere in grado di limitare dinamicamente le richieste che arrivano a Financials Cloud e tenere traccia dello stato delle richieste, quindi sottomettere di nuovo le richieste non riuscite. Per questa soluzione, vengono visualizzate tre integrazioni e un database Autonomous Transaction Processing. L'implementazione del parcheggio può essere eseguita utilizzando varie tecnologie di storage come database o Coherence. Tuttavia, stiamo utilizzando una tabella di database Autonomous Transaction Processing per semplicità.

Descrizione dell'immagine oic_extended_parkinglot_eh.png

Nell'immagine mostrata, quando l'applicazione a monte invia la richiesta, l'interazione Richiesta Persister la invia al database e conferma l'applicazione a monte. Nel database, il pattern del parcheggio memorizza i metadati delle richieste e le informazioni sullo stato ed elabora la richiesta di input in base all'ordine in cui entrano. Ogni messaggio viene parcheggiato nello storage per x minuti (tempo di parcheggio), quindi il flusso di integrazione ha la possibilità di limitare il numero di messaggi elaborati contemporaneamente.

Un'integrazione del dispatcher di pianificazione orchestrata viene attivata da una pianificazione. È possibile pianificare l'esecuzione di questa integrazione per copiare le richieste dal database in una data e ora di propria scelta. È inoltre possibile definire la frequenza dell'integrazione. Queste richieste vengono trasferite all'integrazione del processore asincrono. L'integrazione del processore asincrono elaborerà le richieste in entrata e le invierà all'applicazione a valle.

Componenti progettazione

Il design di alto livello ha tre integrazioni e un database. Stiamo prendendo in considerazione la creazione come esempio, ma in realtà potrebbe trattarsi di qualsiasi business object esposto da qualsiasi API REST Oracle SaaS.

Invia richieste

L'integrazione Request Persister espone un endpoint trigger REST, che può essere richiamato da un'applicazione a monte (client) per eseguire il comando POST sulle richieste di creazione dell'account.

Questa integrazione persistente carica le richieste di creazione degli account nel database Autonomous Transaction Processing immediatamente alla ricezione dalle applicazioni client e conferma una ricevuta con HTTP 202/Accepted. L'ID account e l'intero payload vengono resi persistenti nella tabella dei parcheggi per l'elaborazione successiva.

Carica richieste in tabella parcheggio

Il database Autonomous Transaction Processing contiene la tabella dei parcheggi in cui vengono parcheggiate tutte le richieste ricevute prima dell'elaborazione. Per semplicità, viene visualizzata una tabella semplice per rendere persistente il payload e tenere traccia dello stato della richiesta e di eventuali informazioni sugli errori.

Il payload della richiesta JSON di creazione dell'account viene interamente memorizzato nella tabella dei parcheggi sotto forma di stringa. Potrebbero esserci casi d'uso da memorizzare come CLOB o stringa codificata in cui non è auspicabile avere un payload visibile nella tabella. Tuttavia, la memorizzazione del payload come json consente di modificare il payload durante le risottomissioni degli errori.

Se lo desideri, puoi memorizzare l'intera richiesta JSON nella tabella. È possibile eseguire questa operazione in due fasi:

• Una fase Write che utilizza l'esempio JSON del payload richieste per la creazione del file di schema.
• Fase Read Entire File che utilizza uno schema opaco.

  Fornisce il valore con codifica base64 della stringa di payload JSON. Quindi la funzione incorporata decodebase64(opaqueElement) può essere utilizzata nel mapper (o nell'assegnazione) per ottenere il valore della stringa JSON !. Il file di schema opaco xsd utilizzato durante la lettura della fase è disponibile nel file GitHub, che viene descritto più avanti in questa soluzione.

Richieste di invio in base a schedulazione

L'esecuzione dell'integrazione pianificata è pianificata in base alla frequenza richiesta. In ogni esecuzione recupera un numero configurato di richieste e loop inviando ogni richiesta a un'integrazione del processore asincrono per l'elaborazione.

È possibile eseguire la configurazione per recuperare un numero di richieste come parametro schedulato per limitare o accelerare l'elaborazione delle richieste e anche per modificare dinamicamente il valore. Ad esempio, è possibile impostare una tabella in modo che le richieste dalla tabella dei parcheggi vengano recuperate in base allo stato delle richieste. È possibile recuperare le richieste di stato NEW e ERROR_RETRY e passare all'elaborazione.

Questo Dispatcher pianificato esegue quindi il loop attraverso il numero di richieste recuperate e trasmette ogni richiesta al processore asincrono per la creazione dell'account. Assicurarsi che il flusso Scheduler (padre) richiami un flusso di integrazione asincrona (figlio) unidirezionale. Il processore Async non restituisce alcuna risposta, quindi il thread dello scheduler viene liberato per tornare indietro e scorrere in loop il resto delle richieste e inviarle. Ciò garantisce che i thread dello scheduler destinati al caso d'uso speciale della pianificazione non vengano bloccati nell'elaborazione a lungo termine. La business logic dell'elaborazione delle richieste è gestita dalle risorse di elaborazione asincrona disponibili in Oracle Integrations.

Di seguito sono riportate alcune best practice per l'orchestrazione pianificata: disaccoppiare sempre la logica di pianificazione con la business logic utilizzando un trasferimento asincrono dall'integrazione pianificata. Ciò garantisce che i thread dello scheduler non vengano utilizzati per la creazione dell'account.

• Le orchestrazioni pianificate hanno lo scopo di soddisfare particolari requisiti di pianificazione dei flussi e la loro liberazione mediante Async-handoff rende la soluzione scalabile e performante durante l'elaborazione di un gran numero di richieste.
• Le orchestrazioni pianificate non devono essere utilizzate come sostituto delle orchestrazioni basate su applicazione.

È possibile aggiungere azioni all'integrazione orchestrata. Se si utilizza l'azione for-each, è possibile eseguire un loop su un elemento ripetuto ed eseguire una o più azioni nell'ambito dell'azione for-each. Il numero di iterazioni del loop si basa su un elemento di ripetizione selezionato dall'utente. Ad esempio, si potrebbe avere un'integrazione in cui è stato scaricato un certo numero di file e si desidera eseguire un loop sull'output dei file. L'azione for-each consente di eseguire questo task. Tenere presente che è possibile selezionare Elementi processo in parallelo per alcuni loop for-each. Ciò garantirà che le attività all'interno del ciclo for-each vengano raggruppate in batch in base all'integrazione ed eseguite in parallelo. Ci sono alcune condizioni in cui l'integrazione ignorerà il parallelismo. In questi casi, il grado di parallelismo sarà impostato su 1 per evitare problemi di concorrenza.

Crea un account

L'integrazione del processore asincrono elaborerà le richieste in entrata dal dispatcher pianificato e le invierà all'applicazione a valle.

Il processore asincrono espone un'interfaccia REST. È importante che questa integrazione sia modellata come un flusso asincrono unidirezionale per liberare l'integrazione dello scheduler. Quando si imposta l'integrazione asincrona in un modo, assicurarsi che il trigger REST esponga un metodo POST e che il flusso REST non restituisca una risposta al client.

1. È possibile configurare questi due elementi nella procedura guidata Configura endpoint di ripristino.
   1. Nell'area di creazione dell'integrazione, nel riquadro Trigger fare clic su REST se gli adattatori REST non sono già elencati.
   2. Trascinare la connessione di integrazione sull'icona con il segno più sotto AVVIA nell'area di creazione. Viene visualizzata la configurazione guidata Configura endpoint REST.
2. Nella pagina Informazioni di base della procedura guidata, selezionare POST dall'elenco a discesa per Quale azione si desidera eseguire sull'endpoint?
3. Selezionare Configura un payload di richieste per questo endpoint.

Poiché il flusso asincrono esegue la creazione effettiva del conto, sarà responsabilità dell'aggiornamento dello stato della richiesta nella tabella dei parcheggi. Dopo la creazione di un conto riuscita, la colonna STATUS nella tabella dei parcheggi viene aggiornata a PROCESSED.

Gestisci richieste non riuscite

La risottomissione delle richieste non riuscite può essere controllata dalla tabella dei parcheggi. Un handler di errori a livello di ambito gestisce eventuali errori durante la creazione dell'account e aggiorna lo stato su ERRORED per individuare eventuali errori. I dettagli relativi al motivo e all'errore vengono aggiornati anche nella tabella dei parcheggi. Ciò è utile per determinare se la richiesta può essere risottomessa in un secondo momento. È inoltre possibile inviare e-mail di notifica degli errori agli amministratori dell'integrazione.

Gli handler di errori impostano le richieste non riuscite sullo stato ERRORED nella tabella dei parcheggi. Queste richieste possono essere aggiornate nella tabella allo stato ERROR_RETRY e verranno selezionate nella pianificazione successiva per la rielaborazione a causa dei criteri di selezione del richiamo del database Autonomous Transaction Processing del dispatcher pianificato.

Sono disponibili diverse opzioni per attivare tali risottomissioni:

• L'aggiornamento delle richieste ERRORED a ERROR_RETRY può essere eseguito da un amministratore del database.
• È inoltre possibile aggiungere un flusso di integrazione Risottomissione che viene eseguito giornalmente o con qualsiasi frequenza desiderata e aggiornare tutti i record ERRORED in ERROR_RETRY.
• L'handler di errori dell'integrazione del processore asincrono può impostare lo stato direttamente su ERROR_RETRY, in modo che ogni errore venga risottomesso automaticamente nella pianificazione successiva.

Correzione payload

La memorizzazione del payload di creazione dell'account nella tabella dei parcheggi ci ha fornito un modo per correggere il payload degli errori di dati prima della risottomissione. Aggiornare il payload e impostare la colonna dello stato su ERROR_RETRY per risottomettere una richiesta con il payload corretto.