Vorheriges Thema: Daten-Modellierung (Datenexperte, Business-Logik-Experte)Nächstes Thema: Datenmodell - Übersicht


Ereignisse und ihr Flow

Der Datenfluss innerhalb des Systems erfolgt in Form von Ereignissen. Wobei ein Ereignis eine Informationsmeldung ist, die von dem Adapter basierend auf Quellendaten erstellt wird ist und die in einem Format vorliegt, das von CA Business Service Insight für seine Service Level-Berechnungen verwendet werden kann. Rohdaten bestehen immer aus Ereignissen.

Der Schwerpunkt des Entwurfs muss daher auf diesem Ereignisfluss innerhalb des Systems liegen.

Vor der Modellierung der Datenanforderungen müssen sowohl der Business-Logik-Experte als auch der Datenexperte ein gutes Verständnis für die Ereignisse und ihren Fluss innerhalb des CA Business Service Insight-Systems haben. Das folgende Diagramm veranschaulicht in hohem Maß diesen grundlegenden Ereignisfluss.

Ereignisse und ihr Flow

Das vorherige Diagramm stellt dar, wie Ereignisse von der Datenquelle durch die Adaptern abgerufen und in eine Standard-Ereignisstruktur, die als Event-Typ definiert ist, standardisiert werden. Diese Ereignisse werden von den Adaptern an CA Business Service Insight gesendet. Diese Ereignisse werden als Rohdatenereignisse bezeichnet.

Die Business-Logik-Kalkulationen in jeder Metrik basieren auf einer Teilmenge der Rohdatenereignisse. Die Business-Logik fordert diese Teilmenge daher mit der Durchführung der Registrierung an.

Basierend auf die Registrierungsbeschreibung sendet die Korrelations-Engine nur die Rohdatenereignisse, die für die Business-Logik-Berechnungen relevant sind.

Engine-Ereignisse sind weitere Event-Typen, die an die Business-Logik gesendet werden. Alle in diesen Prozess einbezogenen Begriffe werden in diesem Kapitel ausführlich behandelt.

Dieser Abschnitt konzentriert sich auf die folgenden Teile des Diagramms:

Das CA Business Service Insight-Datenmodell wurde entwickelt, um die Leistungsfähigkeit dieses Datenstroms innerhalb des Systems zu maximieren.

Im Allgemeinen funktioniert CA Business Service Insight auf zwei Ebenen: Der Infrastrukturebene und der Geschäftsmodellebene. Als eine simple HW-Störung schließt die Infrastrukturebene Adapter, Ressourcen und Event-Typ-Objekte ein, während die Geschäftsebene Verträge, Metriken und Service-Objekte umfasst. Zwischen den beiden Ebenen gibt es eine virtuelle Shim-Ebene, die so genannte Korrelationsebene.

Eine Ereigniskennung ist das Event-Typ-Objekt. Der Event-Typ legt fest, wie Ereignisse definiert werden und wie sie CA Business Service Insight gemeldet werden. Er legt zudem die Struktur des Feldes für Ereignisdaten fest, sodass dieses während der Verarbeitung durch die Business-Logik interpretiert werden kann.

Eine andere Ereigniskennung ist die Ressource, die kleinste in Kalkulationen verwendete Entität. Beispiel: Bei der Berechnung der Serververfügbarkeit kann die logische Definition der kleinsten Entität, über die eine Berichterstellung erforderlich ist, ein spezieller Server sein, oder es kann ein Kunde sein, wenn über die Handhabung des Anfragetickets dieses Kunden berichtet wird. Die Ressource ist eine Definition einer CA Business Service Insight-Entität, die sowohl von der Datenquelle als auch von der Berechnungsanforderung abgeleitet wird. Jeder Ressource wird ein Ressourcentyp zugewiesen, eine Ressourcenkennung, die genau festlegt, welcher "Typ" Ressource definiert wird. Jeder Ressource muss ein Ressourcentyp zugewiesen sein, was zudem das Hinzufügen von individuellen Attributen zu jeder Ressource ermöglicht. Weitere Informationen zu diesen Attributen finden Sie unter Ressourcen und ihre Verwaltung.

Die Korrelation tritt zwischen eingehenden Adapterereignissen und Vertragsmetriken auf. Das Kernstück dieses Korrelationsprozesses sind die Ressourcenzuordnung und die Metrikerfassung.

Ressourcenzuordnung und Metrik-Registrierung legen fest, welche Ressourcenereignis-Streams gemessen werden, und von welcher Metrik.

Zu beachten ist, dass es durch die Metrikerfassung zu einem gewissen Grad von Wiederverwendung und Coabhängigkeit mit anderen Metriken kommen kann, da es möglich ist, die Ausgabe einer Metrik als Eingabe bei einer anderen zu verwenden. Entsprechend gibt es Übergangsereignisse, die nicht als Ausgabe einer Metrik zur Service Level-Messung verwendet werden, sondern eher als Berechnungszwischenschritt, der dann von anderen Metriken verwendet werden kann.