Asynchrone Überwachung von Geschäftsereignissen
Asynchron (mit BufferedEventStream) : Dieses Modell bietet erhebliche Leistungsverbesserungen. Es verwendet eine ähnliche API wie das synchrone Modell, wobei lediglich ein anderer Konstruktor zum Einsatz kommt. Statt die Daten in die primäre Importdatenbank zu verschieben, kumuliert BufferedEventStream die Ereignisdaten in binärer Form im Speicher und fügt sie dann als einzelnen Tabellendatensatz in eine Datenbank zur Zwischenspeicherung (MessageBox) ein. Der Ereignisbusdienst liest die Daten, die von BizTalk in der MessageBox-Datenbank in die Warteschlange gestellt wurden, und importiert sie in die primäre Importdatenbank.
Wenn Sie BAM für den asynchronen Betrieb konfigurieren möchten, sollten der Ereignisbusdienst und die aufrufende Anwendung (z. B. der Orchestrierungshost) auf verschiedenen Computern ausgeführt werden. Dadurch kann die aufrufende Anwendung die Ereignisdaten sofort weiterleiten, damit sie mithilfe der CPU eines anderen Computers verarbeitet werden.
Diese Topologie von BAM ist auch transaktionskonsistent. Sie rufen niemals BAM-Daten für Transaktionen ab, für die in der aufrufenden Anwendung ein Rollback ausgeführt wurde, weil der Ereignisbusdienst nur die festgeschriebenen Daten aus der MessageBox-Datenbank liest. Die BAM-Daten für festgeschriebene Transaktionen werden mit geringer Wartezeit für Abfragen und zur Aggregation angezeigt.
Beim Auftreten von Fehlern führt der Ereignisbusdienst unter Verwendung von Timeouts und Logik zur Wiederherstellung nach Systemabstürzen o. ä. mehrere Versuche durch. Wenn die Daten jedoch in einem ungültigen Format vorliegen, werden sie in speziellen Tabellen abgelegt. Es wird ein Ereignis in das Ereignisprotokoll eingetragen, das diese Bedingung anzeigt. Durch diese zusätzliche Fehlerquelle gestaltet sich die Verwaltung des Systems schwieriger.
Bei Anwendung des asynchronen Ansatzes aus dem Code brauchen Sie gewöhnlich nur DirectEventStream durch BufferedEventStream zu ersetzen und die Verbindungszeichenfolge an die MessageBox im Konstruktor statt an die MessageBox in der primären BAM-Importdatenbank zu übergeben.
Beachten Sie für die asynchrone Überwachung von Geschäftsereignissen die folgenden Richtlinien:
Verwenden Sie stets die Fortsetzung, wenn die Aktivität mehrere Anwendungen umfasst und Sie Daten asynchron an BAM senden, und zwar auch dann, wenn Sie die Aktivitäts-ID (ActivityID) an alle Komponenten weitergeben. Verwenden Sie in diesem Fall für jede Anwendung eine andere ActivityID, indem Sie dieser eine eindeutige Zeichenfolge (z. B. den Anwendungsnamen) als Präfix voranstellen. Dies ist erforderlich, weil die Daten aus verschiedenen Anwendungen unter Umständen in beliebiger Reihenfolge bei BAM eintreffen und BAM diese nach dem Zufallsprinzip eingehenden Ereignisse verarbeiten muss, um richtige Abfrage- und Aggregationsergebnisse zu gewährleisten.
Die gängigen Methoden der Ereignisüberwachung (z. B. LCE-Ereignisse (Loosely Coupled Events) von COM+ oder WMI-Ereignisse) gelten nicht für BAM, weil die Ereignisdaten von der Transaktion unabhängig sind. So kann es beispielsweise den Anschein haben, als hätten Sie zehn Bestellungen mit einem Gesamtwert von 10.000 € empfangen, obwohl nur eine Bestellung mit einem Wert von 1.000 € eingegangen ist, deren Speicherung in der Datenbank zehn Mal fehlgeschlagen ist.