|
|
|
Das Standard-Business-Logik-Skript hat keinen Zugriff auf externe Ausgabetabellen. Es gibt nur zwei Ausgabeziele:
Die Verwendung der externen Tabelle T_SLALOM_OUTPUTS ist erforderlich, wenn eine zusätzliche Ausgabe über das periodische Service Level-Ergebnis hinaus benötigt wird, diese zusätzliche Ausgabe jedoch nicht durch das Hinzufügen einer weiteren Metrik erreicht werden kann, oder wenn durch das Hinzufügen einer weiteren Metrik die Rechenleistung verringert wird, indem dieselbe Datensatzgruppe durchgegangen wird, nur um eine andere Ausgabe zu liefern.
Angenommen eine Metrik ist auf die Berechnung des Prozentsatzes an Tickets eingestellt, die in weniger als einem Tag gelöst wurden, und es soll ein Bericht mit einer Liste aller Tickets, die nicht in weniger als einem Tag gelöst wurden, erstellt werden. In diesem Fall ist muss die Formel jedes Ticket, das die Kriterien nicht erfüllt, in eine externe Tabelle ausgeben und es gleichzeitig zur Rechenstatistik hinzufügen.
Mit der oben aufgeführten Anforderung kann die reguläre Service Level-Ausgabetabelle diese Ausgabe nicht bieten, da:
Datensätze werden nur für den Agenten in die Benutzerausgabetabellen geschrieben, der für den Kontrollzeitraum der Metrik ausgeführt wird, und der die Ausnahmen und Korrekturen berechnet. Beispiel: Wenn die Beispielsweise so definiert wird, das sie über einen monatlichen Kontrollzeitraum verfügt, werden die Ausgabeerklärungen (Tools.SaveRecord und Tools.SaveFields) NICHT ausgeführt, wenn die Engine die Formel für die anderen Granularitäten, wie STUNDE, TAG, WOCHE, QUARTAL und JAHR, ausführt.
Ein zusätzlicher Nutzen einer externen Tabelle ist, dass sie für mehrere Berichterstellungsanforderungen verwendet werden kann. Von diesen Tabellen lassen sich zusätzlich zu den vertraglichen Anforderungen andere typische Berichterstellungsanforderungen generieren. Eine Metrik, die beispielsweise die "Anzahl der geschlossenen Tickets" in einem Monat berechnet, könnte auch die Ticket-Problemlösungszeit berechnen und all diese Daten in die Ausgabetabelle ausgeben. Dies ermöglicht eine detailliertere Analyse der einzelnen Tickets, die innerhalb des Zeitraums geschlossen wurden, sowie zusätzlicher Einzelheiten, die in Bezug auf eine separaten Berichterstellungsanforderung möglicherweise erforderlich sind.
Die Daten in diesen Tabellen werden ebenfalls über den Engine-Neuberechnungsmechanismus verwaltet. Während dieses Neuberechnungsprozesses werden Datensätze als inaktiv gekennzeichnet, und stattdessen wird eine neue Zeile geschrieben. Dies ist ein wichtiger Punkt, den es zu bedenken gilt, da alle Freibericht-SQL-Erklärungen eine Überprüfung des Feldes IS_ACTIVE-Feld in der T_SLALOM_OUTPUTS-Tabelle umfassen müssen (wobei is_active = 1), da nur diese Datensätze aktuell sind.
Hinweis: Wenn der Business-Logik-Umfang während des Fehlerbehebungsprozesses der Formeln ausgeführt wird, werden die Meldungen tatsächlich in die Tabelle T_DEBUG_SLALOM_OUTPUTS und nicht in die Tabelle T_SLALOM_OUTPUTS geschrieben.
Bei der Dokumentation von Daten mit T_SLALOM_OUTPUTS handelt es sich bei den eingegebenen Daten stets um Text (da die Felder von T_SLALOM_OUTPUTS alles varchar2 sind). Daher werden Datumswerte unter Anwendung des Betriebssystemformats in Text konvertiert, welches sich während des Lebenszyklus der Anwendung ändern kann. Bei T_SLALOM_OUTPUTS kann es daher zu Inkonsistenzen in den Datumsformaten kommen. Zudem verarbeitet die Business-Logik UTC-Daten, wobei zu erwarten ist, dass T_SLALOM_OUTPUTS lokale Zeitstempel umfasst, sodass es in einigen Fällen erforderlich sein kann, die Konvertierungsfunktion Tools.GetLocaleDate(date) als Umgehungslösung zu verwenden.
Mit der folgenden Funktion werden Datumsangaben in lokale Uhrzeiten konvertiert, wobei die Datumsformat-Konsistenz durch die Formatierung der Datumsangaben in das Format "dd/mm-/yyyy-hh24:mi:ss-" gewahrt bleibt:
Function FormatDate(time)
Dim LocalTime
LocalTime=Tools.GetLocaleTime(time)
FormatDate=Day(LocalTime) & "/" & Month(LocalTime) & "/" &
Year(LocalTime) & " " & _
Hour(LocalTime) & ":" & Minute(LocalTime) & ":" & Second(LocalTime)
End Function
Es kann auf zwei Arten aus der Business-Logik-Formel heraus in die externe Tabelle geschrieben werden:
Beide Methoden des Tool-Objekts sind nachfolgend ausführlicher beschrieben:
Tools.SaveRecord tableName, key,[val1],[val2],…
Diese Methode speichert einen Datensatz in einer Tabelle namens T_SLALOM_OUTPUTS. Der Parameter tableName legt die (virtuelle) Tabelle in T_SLALOM_OUTPUTS fest, in die die Daten geschrieben werden sollen. Jeder Datensatz in der Benutzertabelle verfügt über einen eindeutigen Schlüssel, der angibt, in welchen Datensatz die Daten geschrieben werden sollen. Jeder Datensatz verfügt darüber hinaus über bis zu 20 Zeichenfolge-Wertfelder. Bei der Methode SaveRecord werden ein Benutzertabellenname und ein -schlüssel erhalten. Darüber hinaus werden alle Wertfelder in der Benutzertabelle akzeptiert. (Diese Wertparameter sind optional und können weggelassen werden.) Wenn bereits ein Datensatz mit demselben Schlüssel vorhanden ist, wird er aktualisiert. (Es werden nur die als Parameter übertragenen Wertfelder aktualisiert.) Existiert kein Datensatz mit diesem Schlüssel, wird einer angelegt.
Tools.SaveFields tableName, key, [fieldName1,fieldVal1], [fieldName2,fieldVal2]
Diese Methode ist ähnlich wie die Methode SaveRecord, anstatt jedoch alle Werte zu nummerieren, werden hier Feldnamenpaare und diesbezügliche Feldwerte bereitgestellt. Die Feldnamen können durch Feldnummern ersetzt werden. Die Feldnamen sollten zuvor in der Tabelle T_SO_FIELD_NAMES manuell definiert werden. Diese Tabelle wird verwendet, um die Struktur der Ausgabetabellen aufzuzeichnen.
Es wird empfohlen, dass der Business-Logik-Experte die Struktur der der Ausgabetabelle definiert, bevor in T_SLALOM_OUTPUTS geschrieben wird, da die Struktur und die Bedeutung des Feldes in diesem Fall bereits ausreichend definiert sind, wodurch sich die Abfragen erheblich einfacher gestalten.
Die Tabellenstruktur ist:
Die Verwendung der Methode SaveFields ist vorzuziehen, da die Struktur und die Bedeutung des eingegebenen Wertes dokumentiert werden.
Beispiel:
Angenommen, es ist erforderlich, eine Liste aller Vorfälle mit einer Problemlösungszeit über dem definierten Schwellenwert zu erstellen, und gleichzeitig muss das Metrik-Ergebnis den Prozentsatz an Tickets berechnen, die sich unterhalb dieses Schwellenwertes lösen ließen. Das Schreiben in Ausgabetabellen erfolgt in der Event-Handler-Prozedur OnXXXEvent nach der Schwellenwertvalidation.
Dies wird vom folgenden Beispiel verdeutlicht:
Sub OnIncidentEvent(eventDetails)
If eventDetails("RESOLUTION_TIME")<=SThreshold Then
CountSuccessIncident s= CountSuccessIncidents+1
Else
building the record unique key
KeyString= eventDetails("IncidentID") &eventDetails.Time
Tools.SaveFields "IncidentsTable", KeyString, "CASE_ID",
eventDetails("CASE_ID"),_
"CUSTOMER_REF",eventDetails("CUSTOMER_REF"),_
"TICKET_CREATOR",eventDetails("TICKET_CREATOR"),_
"CREATION_TIME",eventDetails("CREATION_TIME"),_
"SEVERITY",eventDetails("SEVERITY"),_
" RESOLUTION_TIME ",eventDetails("RESOLUTION_TIME "),_
"CLOSE_TIME",eventDetails("CLOSE_TIME")
End If
End Sub
Nachfolgend finden Sie einige auf die Verwendung der Tabellen T_SLALOM_OUTPUTS bezogene Vorschläge:
Hinweis: Das Schreiben in die Ausgabetabellen kann Auswirkungen auf die Leistung der Engine haben, da das Schreiben in eine Tabelle im Vergleich mit einer Berechnung im Arbeitsspeicher rechenintensiv ist. Überlegen Sie sich daher genau, ob diese Funktionalität benötigt wird, und was dafür erforderlich ist. Minimieren Sie dann die Zugriffshäufigkeit auf die Tabellen.
Zur Berichterstellung über Daten, die in die Ausgabetabellen geschrieben werden, kann der standardmäßige CA Business Service Insight-Berichtassistent nicht verwendet werden. Zur Berichterstellung über diese Daten muss zunächst ein Freiformbericht erstellt werden. Im Wesentlichen bedeutet dies die Generierung einer SQL-Abfrage auf der Grundlage dieser Tabelle. Da diese Tabelle viele logische Tabellen enthält, die von einer Vielzahl von Formeln in diese Tabellen geschrieben werden, wird empfohlen, dass jemand, der sich mit SQL auskennt (Datenexperte) eine Maske über T_SLALOM_OUTPUTS erstellt, um die Differenzierung zwischen den darin enthaltenen logischen Tabellen zu vereinfachen, und um sicherzustellen, dass die Daten plangemäß abgerufen werden.
Die Definition der Ansicht entspricht in ihrer Form bereits ganz den Zeichenfolge-Feldtypen, und sie umfasst auch bereits die gesamte erforderliche Filterung (logische Tabelle, aktive Datensätze, relevante Metrik usw.).
Nachfolgend finden Sie ein Beispiel für die Ansichterstellung:
create or replace view kpi_view as
select
to_date(t...) as fieldName,
to_number(t..), …
from t_slalom_outputs t,
t_rules r,
t_sla_versions sv,
t_slas s,
where table_name = 'TableName'
and is_active = 1
and t.rule_id = r.psl_rule_id
and r.sla_version_id = sv.sla_version_id
and sv.sla_id = s.sla_id
and sv.status = 'EFFECTIVE'
| Copyright © 2012 CA. Alle Rechte vorbehalten. | Senden Sie CA Technologies eine E-Mail zu diesem Thema. |