Abbiamo 2 sistemi che scambiano i ticket in base a un flusso transazionale, hanno un ordine negli stati del ticket se uno stato non raggiunge un sistema tutto il flusso è bloccato. Il problema è che utilizziamo un broker di messaggi multi-threaded con carico bilanciato tra questi sistemi e potremmo avere casi in cui uno stato di update1 può essere elaborato più rapidamente di un create o update2 più veloce di update1.
Sto cercando una best practice per questo tipo di integrazione.
Il tuo problema è che hai un'applicazione di intermediazione dei messaggi che l'applicazione comunica in modo asincrono, tuttavia i tuoi requisiti tecnici sono tali che i messaggi devono essere elaborati in ordine sincrono.
A seconda del pacchetto software che si utilizza come Message Broker, molti di questi prodotti avranno funzionalità incorporate per il recapito dei messaggi ai destinatari in base a un ordine di sequenza appropriato. Questo è un argomento di discussione, ma ritengo che l'utilizzo o il ricorso a tale funzione in un'applicazione di intermediazione di messaggi sia un segno di "odore del design".
Che cosa intendo quando dico "odore del design", in pratica si tratta di una funzionalità fornita in questo strumento che aiuta a nascondere il fatto che la logica dell'applicazione non è in grado di gestire tali scenari in cui i messaggi vengono ricevuti senza ordine. Hai chiaro i requisiti dell'utente che questi messaggi devono essere elaborati in un certo ordine, tuttavia non ti stai affidando al codice della tua applicazione per assicurarti di ciò, ma su una funzionalità di uno strumento che ora è strettamente connesso al corretto funzionamento della tua applicazione. Non sto dicendo che questa funzionalità del tuo strumento di intermediazione dei messaggi è una cosa negativa, tuttavia, può essere incredibilmente utile per garantire che il destinatario di un broker di messaggi riceva i messaggi nell'ordine corretto se l'applicazione del destinatario è un prodotto più fragile o un prodotto precedente legacy in cui non si ha il tempo o la capacità di migliorare la progettazione di detta applicazione.
Quindi, se sei d'accordo con la mia valutazione che l'utilizzo di tale funzione in uno strumento di brokering dei messaggi introduce un strong accoppiamento con la tua applicazione, OPPURE se semplicemente non hai alcun controllo per modificare o influenzare il tuo strumento di broker dei messaggi, allora un modo in cui ho visto questo gestito è quello di creare un'area di staging nel database per i messaggi da ricevere. Non è necessario che si tratti di una struttura di database relazionale normalizzata, il punto importante è che si ricevono messaggi dal proprio broker, si mantengono in un'area di gestione temporanea e si specifica l'elaborazione corretta sequenza in questo momento. In un thread dell'applicazione o un'attività pianificata separata è possibile verificare regolarmente le tabelle di staging per i messaggi che possono essere elaborati dall'applicazione.
Il punto importante da ricordare è che l'applicazione in quanto il destinatario non richiede REQUISITO EFFETTIVAMENTE che i messaggi siano ricevuti nell'ordine corretto, richiede che vengano elaborati nell'ordine corretto. Inoltre, la responsabilità del broker di messaggi NON è di garantire al sistema di invio che il sistema di ricezione abbia elaborato il messaggio correttamente. L'unica responsabilità del broker dei messaggi qui è quella di garantire che il messaggio sia stato consegnato correttamente alle applicazioni del destinatario e che abbia restituito un messaggio di conferma in cui dichiara di averlo ricevuto e TENTARÀ di elaborarlo.
Leggi altre domande sui tag multithreading integration eai