Le script de la logique applicative standard n'a pas accès aux tables de sortie externes. Il n'existe que deux destinations de sortie :
L'utilisation de la table externe T_SLALOM_OUTPUTS est requise lorsqu'une sortie supplémentaire est nécessaire sur et au-dessus du résultat du niveau de service périodique, lorsque vous ne pouvez pas fournir la sortie supplémentaire en ajoutant une autre métrique, ou lorsque l'ajout d'une autre métrique diminue la performance du calcul en traversant le même jeu d'enregistrements pour produire seulement une autre sortie.
Par exemple, considérez un cas où une métrique est définie pour calculer le pourcentage de tickets ayant été résolus en moins d'une journée et un rapport à produire contenant la liste de tous les tickets dont la résolution a échoué en moins d'un jour, il est nécessaire que la formule produise dans une table externe chaque ticket identifié comme défaillant et l'ajoute aux statistiques de calcul.
Dans le cadre de la condition ci-dessus, la table de niveau de service de sortie normale ne peut pas fournir cette sortie, parce que :
Les enregistrements sont écrits dans des tables de sortie utilisateur uniquement pour l'agent qui s'exécute pendant la période de suivi de la métrique et calcule les exceptions et les corrections. Par exemple, si la métrique est définie comme ayant une période de suivi mensuelle, les instructions de sortie (Tools.SaveRecord et Tools.SaveFields) ne sont PAS exécutées lorsque le moteur exécute la formule pour les autres granularités comme l'HEURE, le JOUR, la SEMAINE, le TRIMESTRE et l'ANNEE
L'avantage supplémentaire de cette table externe est qu'elle peut satisfaire à plusieurs exigences de génération de rapports. Vous pouvez créer d'autres exigences de génération de rapports typiques à partir de ces tables en plus des exigences contractuelles. Par exemple, une métrique calculant le nombre de tickets clôturés en un mois pourrait également calculer le temps de résolution de ticket et produire la sortie de l'ensemble de ces informations dans la table de sortie. Cela permettra une analyse plus détaillée des tickets individuels qui ont été clôturés pendant la période ainsi que les détails supplémentaires nécessaires dans le cadre d'une exigence de génération de rapports distincts.
Les informations dans ces tables sont également gérées par le mécanisme de nouveau calcul du moteur. Pendant ce processus de nouveau calcul, les enregistrements sont marqués comme inactifs, et une nouvelle ligne est écrite à la place. Il s'agit d'un point important puisque que toutes les instructions SQL de rapport en format libre doivent inclure une vérification du champ IS_ACTIVE dans la table de T_SLALOM_OUTPUTS (où is_active = 1) puisque seuls ces enregistrements sont actuels.
Remarque : Lors de l'exécution de la portée de la logique applicative pendant le processus de débogage des formules, les messages sont en fait écrits dans la table T_DEBUG_SLALOM_OUTPUTS au lieu de la table T_SLALOM_OUTPUTS.
Lors de la documentation des données à l'aide de T_SLALOM_OUTPUTS, les données insérées sont toujours du texte (puisque les champs de T_SLALOM_OUTPUTS sont tous varchar2). Par conséquent, les valeurs de date sont transformées en texte en appliquant le format du système d'exploitation qui peut changer pendant le cycle de vie de l'application. T_SLALOM_OUTPUTS peut par conséquent connaître des incohérences dans les formats de date. De plus, la logique applicative gère des dates UTC où il est possible que T_SLALOM_OUTPUTS contienne des horodatages locaux, ainsi dans certains cas il peut être nécessaire d'utiliser la fonction de conversion Tools.GetLocaleDate(date) pour résoudre le problème.
La fonction suivante transforme des dates en heures locales et conserve la cohérence du format de date en convertissant les dates au format "jj/mm/aaaa hh24:mi:ss" :
Function FormatDate(time)
Dim LocalTime
LocalTime=Tools.GetLocaleTime(time)
FormatDate=Day(LocalTime) & "/" & Month(LocalTime) & "/" &
Year(LocalTime) & " " & _
Hour(LocalTime) & ":" & Minute(LocalTime) & ":" & Second(LocalTime)
End Function
Vous pouvez faire appel aux deux méthodes suivantes pour écrire dans la table externe depuis la formule de logique applicative :
Ces deux méthodes de l'objet Tools sont décrites en détail ci-dessous :
Tools.SaveRecord tableName, key,[val1],[val2],…
Cette méthode sauvegarde un enregistrement dans une table appelée T_SLALOM_OUTPUTS. Le paramètre tableName spécifie la table (virtuelle) dans T_SLALOM_OUTPUTS dans laquelle les informations devraient être écrites. Chaque enregistrement dans la table d'utilisateur a une clé unique qui spécifie l'enregistrement dans lequel les informations devraient être écrites. Chaque enregistrement contient également jusqu'à 20 champs de valeur de type chaîne. La méthode SaveRecord reçoit le nom de la table utilisateur et une clé. Elle accepte également tous les champs de valeur dans la table utilisateur. (Ces paramètres de valeur sont facultatifs et peuvent être ignorés.) Si un enregistrement avec la même clé existe déjà, il est mis à jour. (Seuls les champs de valeur transférés en tant que paramètres sont mis à jour.) Si aucun enregistrement possédant cette clé n'existe, il est créé.
Tools.SaveFields tableName, key, [fieldName1,fieldVal1], [fieldName2,fieldVal2]
Cette méthode est similaire à SaveRecord, sauf qu'au lieu d'énumérer toutes les valeurs, elle fournit des paires de noms de champ et des valeurs de champ connexes. Vous pouvez remplacer les numéros de champ par les noms de champ. Les noms de champ doivent auparavant être manuellement définis dans la table T_SO_FIELD_NAMES. Cette table est utilisée pour enregistrer la structure des tables de sortie.
Il est recommandé que l'expert en logique applicative définisse la structure de la table de sortie avant d'écrire dans T_SLALOM_OUTPUTS car la structure et la signification des champs sont déjà correctement définies et simplifieront nettement la requête.
La structure de table est :
Il est préférable d'utiliser la méthode SaveFields car elle garde une documentation de la structure et la signification des valeurs insérées.
Exemple :
Considérez un cas où il est nécessaire de produire une liste de tous les incidents avec le temps de résolution plus élevé qu'un seuil défini, en plus du résultat de la métrique chargée de calculer le pourcentage de tickets qui ont été résolus en dessous ce seuil. L'écriture dans les tables de sortie se fera dans la procédure du gestionnaire d'événements OnXXXEvent après la validation de seuil.
Cette opération est illustrée par l'exemple suivant :
Sub OnIncidentEvent(eventDetails)
If eventDetails("RESOLUTION_TIME")<=SThreshold Then
CountSuccessIncident s= CountSuccessIncidents+1
Else
création de la clé unique d'enregistrement
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
Les éléments suivants sont des propositions associées à l'utilisation des tables T_SLALOM_OUTPUTS :
Remarque : Ecrire dans les tables de sortie peut avoir une influence sur la performance du moteur, car l'écriture dans une table est intensive sur le plan calculatoire par comparaison à un calcul en mémoire. Par conséquent réfléchissez s'il est nécessaire d'utiliser cette fonctionnalité et à quel emplacement elle est requise, et réduisez le nombre des accès aux tables.
Il n'est pas possible d'utiliser l'assistant de création de rapports CA Business Service Insight pour générer un rapport sur les informations écrites dans les tables de sortie. Afin de créer un rapport sur ces informations, il est nécessaire de créer un rapport au format libre. Il s'agit essentiellement de créer une requête SQL au-dessus de cette table. Comme cette table contient beaucoup de tables logiques qui font l'objet d'écriture par diverses formules, il est recommandé qu'un expert SQL (expert en sources de données) crée une vue sur T_SLALOM_OUTPUTS afin de mieux faire la différence entre les différentes tables logiques contenues dans celle-ci et de s'assurer également que les informations sont récupérées comme prévu.
La définition de vue aura déjà toute la diffusion des types de champs de chaîne en type d'informations pertinent et contiendra également l'ensemble des filtres nécessaires (table logique, enregistrements actifs, métrique pertinente, etc.).
Les éléments suivants sont un exemple de création de vue :
Créez ou remplacez la vue kpi_view comme
select
to_date(t...) comme fieldName,
to_number(t..)...
de t_slalom_outputs t,
t_rules r,
t_sla_versions sv,
t_slas s,
où table_name = 'TableName'
et is_active = 1
et t.rule_id = r.psl_rule_id
et r.sla_version_id = sv.sla_version_id
et sv.sla_id = s.sla_id
et sv.status = 'EFFECTIVE'
|
Copyright © 2013 CA.
Tous droits réservés.
|
|