Rilevamento eventi di business asincroni
Asincrona (con BufferedEventStream) : questo modello offre miglioramenti significativi delle prestazioni. Il modello utilizza un'API simile al modello sincrono che invece utilizza solo un diverso costruttore. Anziché eseguire il push dei dati nel database di importazione primaria, BufferedEventStream accumula i dati degli eventi in memoria in formato binario e quindi li inserisce come singoli record di tabella in un database provvisorio (MessageBox). Nel servizio bus di eventi viene eseguita la lettura dei dati accodati nel database MessageBox da BizTalk, quindi i dati vengono importati nel database di importazione primaria.
Per configurare l'operazione asincrona in BAM, è necessario che il servizio bus di eventi e l'applicazione chiamante (ad esempio Host orchestrazioni) vengano eseguiti su computer diversi. Ciò consente all'applicazione chiamante di eliminare immediatamente i dati degli eventi da elaborare utilizzando la CPU su un diverso computer.
Questa topologia BAM è anche coerente a livello di transazioni. Non verranno mai recuperati dati BAM di transazioni di cui si è eseguito il rollback nell'applicazione chiamante perché nel servizio bus di eventi viene effettuata solo la lettura dei dati di cui si è eseguito il commit nel database MessageBox. I dati BAM delle transazioni di cui è stato eseguito il commit verranno visualizzati per query e aggregazioni con una latenza minima.
In caso di errori, nel servizio bus di eventi verranno eseguiti alcuni tentativi in successione, si ricorrerà all'utilizzo di timeout, della logica di ripristino a seguito dell'arresto anomalo del sistema, e così via. Ciononostante, se il formato dei dati non risulta valido, i dati verranno inseriti in alcune tabelle speciali. Nel registro eventi è incluso un evento per indicare questa condizione. Questo ulteriore punto di errore aumenta le difficoltà di gestione del sistema.
L'utilizzo dell'approccio asincrono tramite codice è in genere semplice in quanto prevede la sostituzione di DirectEventStream con BufferedEventStream e il passaggio della stringa di connessione al MessageBox nel costruttore anziché di quella per il database di importazione primaria.
Per il rilevamento di eventi di business asincroni tramite codice, utilizzare le indicazioni riportate di seguito:
Utilizzare sempre una continuazione quando l'attività interessa più applicazioni e si esegue l'invio asincrono dei dati per BAM, anche se si propaga l'ActivityID a tutti i componenti. In questo caso, utilizzare un diverso ActivityID in ogni applicazione aggiungendo una stringa univoca come prefisso (ad esempio, Nome applicazione). Questa soluzione è necessaria perché potrebbero arrivare a BAM dati di diverse applicazioni in ordine casuale e rendere necessaria la gestione degli eventi non ordinati per garantire risultati corretti di query e aggregazioni.
I metodi comuni per il monitoraggio degli eventi (ad esempio, eventi WMI o eventi loosely coupled) non sono applicabili per BAM in quanto i dati degli eventi sono indipendenti dalla transazione. Potrebbe risultare ad esempio che si siano ricevuti 10 ordini di acquisto per un totale di € 10.000 mentre è presente solo un ordine di acquisto in ingresso pari a € 1.000, ma che si verifichino 10 tentativi di salvataggio nel database non riusciti.