El script de lógica de negocios estándar no tiene acceso a tablas de salida externas. Hay solamente dos destinos de salida:
Es necesario usar la tabla externa T_SLALOM_OUTPUTS cuando se necesitan salidas adicionales para el resultado de nivel de servicio periódico y por encima de él, cuando no se pueden proporcionar salidas adicionales agregando otra métrica, o cuando al añadir otra métrica se reduce el rendimiento del cálculo al pasar por el mismo conjunto de registros solamente para proporcionar una salida diferente.
Supongamos por ejemplo un caso donde se ha definido una métrica para calcular el porcentaje de tickets que se resolvieron en menos de un día y que debe producir un informe con la lista de todos los tickets de resolución fallida en menos de un día; es necesario que la fórmula proporcione cada ticket con error en una tabla externa, además de añadirlo a las estadísticas de cálculo.
Con el requisito anterior, la tabla de nivel de servicio de salida normal no puede proporcionar esta salida porque:
Los registros se escriben en las tablas de salida de usuario solamente para el agente que se está ejecutando para el período de seguimiento de la métrica y que calcula las excepciones y las correcciones. Por ejemplo, si la métrica se define con un período de seguimiento mensual, entonces las declaraciones de salida (Tools.SaveRecord y Tools.SaveFields) NO se ejecutan cuando el motor está ejecutando la fórmula para las otras granularidades como HOUR, DAY, WEEK, QUARTER y YEAR.
Una ventaja adicional de contar con esta tabla externamente es que se puede utilizar para varios requisitos de elaboración de informes. Además de los requisitos contractuales, se pueden generar otros requisitos de elaboración de informes típicos a partir de estas tablas. Por ejemplo, una métrica que calcule el número de tickets cerrados en un mes podría calcular también el tiempo de resolución de los tickets y enviar toda esta información a la tabla de salida. Esto permitirá realizar un análisis más detallado de los tickets individuales que se cerraron durante el período, junto con otros detalles adicionales que se puedan requerir a través de un requisito de informe aparte.
El mecanismo de recálculo del motor gestiona también la información en estas tablas. Durante este proceso de recálculo, los registros se marcan como inactivos y se escribe en su lugar una nueva fila. Esto es un punto importante que tener en cuenta, ya que todas las declaraciones SQL de informes de formato libre tienen que incluir una marca en el campo IS_ACTIVE en la tabla T_SLALOM_OUTPUTS (donde is_active = 1), ya que solamente son actuales estos registros.
Nota: Al ejecutar el ámbito de la lógica de negocios durante el proceso de depuración de fórmulas, los mensajes se escriben realmente en la tabla T_DEBUG_SLALOM_OUTPUTS, en lugar de en la tabla T_SLALOM_OUTPUTS.
Al documentar datos mediante T_SLALOM_OUTPUTS, los datos insertados son siempre texto (ya que los campos de T_SLALOM_OUTPUTS son todos varchar2). Por lo tanto, los valores de fecha se convierten a texto aplicando el formato del sistema operativo, el cual puede cambiar durante el ciclo de vida de la aplicación. T_SLALOM_OUTPUTS puede sufrir por lo tanto inconsistencias en los formatos de fecha. Además, la lógica de negocios gestiona fechas UTC, mientras que se podría esperar que T_SLALOM_OUTPUTS guardara las marcas de hora locales. Así, en algunos casos puede ser necesario utilizar la función de conversión Tools.GetLocaleDate(date) para solucionar este problema.
La función siguiente convierte las fechas en horas locales y mantiene la coherencia del formato de fecha aplicando a las fechas el formato "dd/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
Se pueden utilizar dos métodos para escribir en la tabla externa desde dentro de la fórmula de la lógica de negocios:
Estos dos métodos del objeto de herramientas se describen a continuación en más detalle:
Tools.SaveRecord tableName, key,[val1],[val2],…
Este método guarda un registro en una tabla llamada T_SLALOM_OUTPUTS. El parámetro tableName especifica la tabla (virtual) dentro de T_SLALOM_OUTPUTS donde escribir la información. Cada registro en la tabla de usuario tiene una clave única que especifica el registro donde se debe escribir la información. Cada registro tiene también hasta 20 campos de valores de tipo cadena. El método SaveRecord recibe un nombre de tabla de usuario y una clave. También acepta todos los campos de valores en la tabla de usuario. (Estos parámetros de valores son opcionales y se pueden omitir.) Si ya existe un registro con la misma clave, se actualiza. (Solamente se actualizan los campos de valores transferidos como parámetros). Si no existe un registro con esta clave, se crea.
Tools.SaveFields tableName, key, [fieldName1,fieldVal1], [fieldName2,fieldVal2]
Este método es similar a SaveRecord, excepto en que en lugar de enumerar todos los valores, proporciona pares de nombres de campos y valores de campos relacionados. Los números de campo pueden sustituirse por nombres de campo. Los nombres de los campos deberán definirse previamente en la tabla T_SO_FIELD_NAMES. Esta tabla se utiliza para registrar la estructura de las tablas de salida.
Se recomienda que el experto en la lógica de negocios defina la estructura de la tabla de salida antes de escribir en T_SLALOM_OUTPUTS, ya que entonces la estructura y el significado de los campos estará ya bien definida y será mucho más sencillo consultarlos.
La estructura de la tabla es:
Es preferible utilizar el método SaveFields, ya que guarda una documentación de la estructura y el significado de los valores insertados.
Ejemplo:
Supongamos un caso donde es necesario producir una lista de todos los incidentes con tiempo de resolución superior al umbral definido, además del resultado de la métrica que calcula el porcentaje de tickets resueltos por debajo de ese umbral. La escritura en las tablas de salida se hará en el procedimiento del controlador de eventos OnXXXEvent tras validar el umbral.
El ejemplo siguiente ilustra este caso:
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
Unas cuantas sugerencias relacionadas con el uso de las tablas T_SLALOM_OUTPUTS:
Nota: El hecho de escribir en las tablas de salida puede afectar al rendimiento del motor, ya que ésta es una operación computacionalmente intensiva en comparación con realizar un cálculo en la memoria. Por lo tanto, determine cuidadosamente si es necesario utilizar esta funcionalidad y donde será necesario y, a continuación, minimice el número de veces que se accede a las tablas.
El asistente de informes de CA Business Service Insight estándar no se puede usar para elaborar informes sobre lo escrito en las tablas de salida. Para elaborar informes con esta información es necesario crear un informe de formato libre. Esto significa fundamentalmente crear una consulta SQL sobre esta tabla. Dado que esta tabla contiene muchas tablas lógicas que se están escribiendo en diversas fórmulas, se recomienda que alguien familiarizado con SQL (experto en el origen de datos) cree una vista sobre la tabla T_SLALOM_OUTPUTS para que sea más fácil distinguir entre las diferentes tablas lógicas contenidas dentro de ella, y también para garantizar que la información se recupere según lo programado.
La definición de vista tendrá ya todos los tipos de campos de cadena para el tipo de información relevante y tendrá también todos los filtros necesarios (tabla lógica, registros activos, métrica relevante, etc.).
A continuación se incluye un ejemplo de creación de la vista:
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 © 2013 CA.
Todos los derechos reservados.
|
|