Gestione del servizio bus di eventi BAM
Nel servizio bus di eventi BAM, anche noto come servizio TDDS (Tracking Data Decode Service), vengono elaborati i dati di rilevamento (flussi) archiviati in un database di origine, quindi tali dati vengono resi persistenti in modo che risulti semplice eseguire query su di essi successivamente.
Il servizio bus di eventi BAM sposta i dati Business Intelligence nel database di importazione primaria e i dati sul monitoraggio dello stato BizTalk nel database DTA. Il servizio bus di eventi BAM viene eseguito come servizio secondario all'interno del servizio BizTalk.
Per monitorare le attività di un’applicazione transazionale, ad esempio Microsoft BizTalk® Server, è sufficiente raccogliere i dati degli eventi durante l'esecuzione e archiviarli temporaneamente nello stesso database dello stato dell'applicazione, ad esempio il database MessageBox.
Nota
Evitare la creazione di più istanze dell'applicazione contenenti il rilevamento di diversi gruppi BizTalk nello stesso computer. Se nello stesso computer sono presenti istanze in cui vengono rilevati gruppi BizTalk diversi, non sarà possibile distinguere gli eventi appartenenti ai gruppi BizTalk nella Console di amministrazione BizTalk o nel registro eventi perché tutti i gruppi BizTalk vengono visualizzati con lo stesso nome.
Nel servizio bus di eventi BAM vengono letti, decodificati e quindi archiviati i dati in un database Microsoft SQL Server™ in cui possono essere facilmente sottoposti a query.
Il servizio bus di eventi BAM offre i seguenti vantaggi:
I dati degli eventi risultano sempre corrispondenti allo stato dell'applicazione e non presentano mai lo stato non eseguito.
L’impatto sulle prestazioni dell'applicazione in esecuzione è minimo perché per i dati degli eventi viene salvato un numero minimo di record nella stessa transazione locale della modifica di stato dell'applicazione.
L’archiviazione dello stato dell'applicazione in SQL Server è ulteriormente ottimizzata in termini di prestazioni dell'esecuzione. I dati vengono decodificati da TDDS e memorizzati in un database distinto, vale a dire il database di importazione primaria BAM o il database DTA. Quando vengono generati report, i dati vengono letti dal database, senza alcun impatto sul database MessageBox, in cui è memorizzato lo stato dell'applicazione.
Il processo di archiviazione dei dati degli eventi in un formato appropriato per le query non viene eseguito né nei server né nei database dell'applicazione, ma viene assegnato ai computer in cui vengono eseguiti il servizio bus di eventi BAM e il database SQL Server di destinazione.
I dati degli eventi vengono elaborati con una latenza bassa e questo consente un'elaborazione più veloce delle query TDDS. Le risorse dei servizi bus di eventi BAM vengono coordinate in modo da ottenere la minore latenza possibile.
Le risorse del server bus di eventi BAM vengono coordinate mediante l'utilizzo di una connessione a un database centrale in cui sono contenute le informazioni di configurazione. Da ogni servizio bus di eventi BAM attivo viene inviato un messaggio al minuto al database centrale in cui è contenuto lo stato del servizio bus di eventi BAM in quel momento specifico.
Questo messaggio viene definito messaggio di heartbeat. In ogni servizio bus di eventi BAM vengono inoltre rilevati i nuovi processi da eseguire. Nel servizio bus di eventi BAM, ad esempio, vengono rilevate le sessioni non utilizzate, ad esempio il database MessageBox che è stato aggiunto.
La sessione bus di eventi BAM rappresenta lo spostamento dei dati degli eventi dal database di origine, ad esempio MessageBox, al database di destinazione contenente i dati degli eventi in un formato appropriato per le query. Lo stesso servizio bus di eventi BAM è in grado di elaborare una o più sessioni.
Nella figura seguente viene illustrato un gruppo di server bus di eventi BAM che costituisce un pool di server bus di eventi BAM.
Diagramma di un pool di server bus di eventi BAM