Consultas del panel de resultados

Este artículo contiene los siguientes temas:
casm173
Este artículo contiene los siguientes temas:
Una de las tablas de la base de datos, Cr_Stored_Queries, define las consultas almacenadas. Estas consultas almacenadas, que son muy similares a las consultas SQL, se pueden utilizar para personalizar los campos de contadores en los nodos del área del panel de resultados de las interfaces administrativa y Web. Los campos de contadores indican cuántos registros coinciden con la consulta. Por ejemplo, pueden indicar cuántas solicitudes de distintos tipos se han asignado al usuario conectado.
Cada usuario puede personalizar los campos de contadores que aparecen en su panel de resultados (esto se explica en la ayuda en línea.) Sin embargo, el administrador del sistema primero debe definir los diversos tipos de solicitudes que se pueden contar en estos campos de contadores como consultas almacenadas.
Los recuentos del panel de resultados serán incorrectos si los valores de consulta de la base de datos son NULL. Por ejemplo, si la consulta del panel de resultados especifica que assignee.organization = xyz y un campo de asignatario está en blanco (NULL) para un registro, dicho registro no se incluirá en el recuento del panel de resultados.
Consultas almacenadas para el usuario conectado
Dos de los campos que se deben definir en la ventana Detalles de consulta almacenada son Cláusula Where y Etiqueta. Estos dos campos pueden contener expresiones personalizadas para el usuario conectado. Las consultas almacenadas hacen referencia a objetos y atributos, no a nombres de tablas y columnas. Las consultas almacenadas personalizadas para el usuario conectado constan de dos partes:
  • El objeto (por ejemplo, cr para una solicitud)
    Se suele especificar a la izquierda del signo igual (=). La sintaxis para esta parte de la consulta almacenada es:
    att_name[.att_name...].SREL_att_name
Las consultas almacenadas siempre tienen un tipo, que es el nombre del objeto sobre el que se ejecuta la consulta y proporciona el contexto para la consulta. En la sintaxis anterior, el primer nombre_atributo debe ser el nombre de un atributo del objeto de contexto.
  • El usuario conectado (la instancia del objeto cnt para este usuario)
    Se debe especificar a la derecha del signo igual (=) si los tickets se deben seleccionar en función de un atributo del usuario conectado. La sintaxis para esta parte de la consulta almacenada es:
    @
    nombre_atributo
    [.
    nombre_atributo
    ...].
    nombre_atributo_SREL
Para obtener más información sobre objetos y atributos, consulte la sección Comandos de referencia de CA Service Desk Manager.
Sintaxis del objeto cr
Utilice esta sintaxis si se hace referencia al objeto de solicitud (cr):
att_name[.att_name...].SREL_att_name
Este ejemplo identifica la ubicación de la persona a la que se ha asignado el control de un parte. En este ejemplo, se omite el nombre del objeto, ya que el tipo de la consulta almacenada implica el objeto cr:
[email protected] AND active=1
  • assignee
    El atributo del objeto de solicitud que se asigna al campo del asignatario en la tabla correspondiente. Por ejemplo, el atributo assignee se define en el objeto cr mediante la SREL agt, que significa que hace referencia a la tabla agt. La tabla agt forma parte de la definición del objeto cnt.
  • location
    El atributo del objeto cnt que se asigna al campo c_l_id en la tabla Contact. El atributo location se define en el objeto cnt mediante la SREL loc, que significa que hace referencia al objeto loc.
Cláusula WHERE
El ejemplo siguiente muestra un valor que se puede codificar en las cláusulas WHERE:
[email protected] AND active=1
Ya que el tipo Consultas almacenadas es una solicitud, esta consulta selecciona todas las solicitudes activas en las que la ubicación del asignatario es la misma que la ubicación del usuario conectado.
Etiqueta
Los atributos del objeto cnt se pueden incluir en etiquetas, de la misma forma que se incluyen en las cláusulas WHERE. A continuación se ofrece un ejemplo del uso de un atributo del objeto cnt en una etiqueta:
@cnt.location.name Calls
Esta etiqueta incluirá el nombre de una ubicación, por ejemplo Pontevedra, donde @cnt.location.name se sustituye por Pontevedra cuando se muestra la etiqueta en una ventana. La etiqueta se mostrará como Llamadas Pontevedra.
Palabra clave IN
La palabra clave IN permite que las consultas almacenadas hagan referencia a dos (o más) tablas sin crear ninguna unión. Esto puede producir una importante eficacia en la ejecución de la consulta. Se codifica como sigue:
SREL_att_name IN ( value1 [, value2 [,...]] )
Por ejemplo, una consulta de solicitud se podría codificar como sigue:
category.sym IN (\'Soft%\', \'Email\')
Esto tiene como resultado la siguiente cláusula WHERE de SQL:
category IN (SELECT persid FROM prob_ctg WHERE sym LIKE 'Soft%' OR sym = 'Email')
Un uso de IN es evitar productos cartesianos. Por ejemplo, la consulta siguiente crea un producto cartesiano y es muy ineficaz:
assignee.last_name LIKE 'MIS%' OR group.last_name LIKE 'MIS%'
Mediante el uso de IN, la consulta no crea un producto cartesiano; de hecho, no crea ninguna unión, tal y como muestra el siguiente ejemplo:
assignee.last_name IN 'MIS%' OR group.last_name IN 'MIS%'
Se pueden omitir los paréntesis que normalmente encierran la lista de valores situados a la derecha de IN si solo hay un valor en la lista. De igual forma, se deben evitar las uniones en las particiones de datos mediante la conversión de una partición de datos, tal y como se muestra a continuación:
assignee.last_name LIKE 'Smith' to: assignee = U'374683AA82ACE34AB999A042F3A0BA2E'
donde:
  • U
    Indica que el valor es un UUID.
  • '374683AA82ACE34AB999A042F3A0BA2E'
    Los 32 caracteres delimitados por comillas simples indican la representación de cadena de un UUID real.
Esto evita la unión con algunas pérdidas en CA. Con el uso de IN, se puede escribir la misma partición que se muestra en el siguiente ejemplo, conservando CA de la primera versión y casi la misma eficacia de la segunda:
assignee.last_name IN 'Smith'
CA SDM admite la aplicación de la cláusula IN a listas QREL o BREL. Por ejemplo, si desea hallar todas las solicitudes con activos que sean principales de otro activo concreto (con el ID 374683AA82ACE34AB999A042F3A0BA2E), la cláusula WHERE apropiada es la siguiente:
affected_resource.[parent]child_hier.child IN (U’374683AA82ACE34AB999A042F3A0BA2E’)
La primera parte de la cláusula,
affected_resource
, es una SREL (clave externa) del objeto cr (solicitud) que apunta a la tabla Network_Resource. La parte
child_hier
es una lista de objetos hier que apuntan a las relaciones jerárquicas. La última parte,
child
, forma la primera parte de la cláusula WHERE para la subconsulta IN. La parte
374683AA82ACE34AB999A042F3A0BA2E
es el valor de clave externa que debe coincidir con
child
.
[parent]
especifica la devolución de la subconsulta. Ya que el valor de ID es una representación de cadena de un UUID, se debe indicar como tal y escribirse como U’374683AA82ACE34AB999A042F3A0BA2E’.
A continuación se muestra un ejemplo de la consulta SQL generada que proporciona todas las solicitudes en las que el activo es principal de un activo concreto:
SELECT Call_Req.id FROM Call_Req WHERE Call_Req.affected_rc IN (SELECT hier_parent FROM Asset_Assignment WHERE hier_child = U'374683AA82ACE34AB999A042F3A0BA2E')
Para realizar la consulta en varios principales, se puede proporcionar una lista separada por comas en la parte () de la consulta SQL, tal y como se muestra en el siguiente ejemplo:
affected_resource.[parent]child_hier.child IN (U'374683AA82ACE34AB999A042F3A0BA2E', U'374683AA82ACE34AB999A042F3A0BA2E')
El nombre de atributo situado entre corchetes ([]) se utiliza para formar la parte SELECT de la subcláusula. La notación con corchetes no se utiliza para el grupo Consultas almacenadas proporcionado con CA Service Desk Manager versión 6.0, tal y como se muestra en este ejemplo:
(assignee = @cnt.id OR group.group_list.member IN (@cnt.id)) AND active = 1
Si no se utiliza la notación mediante corchetes, el subsistema de SQL da por hecho que se trata del nombre de atributo del primer símbolo de la parte expresada mediante la notación con puntos. En este caso funciona, por suerte, ya que el objeto group_list incluye un atributo denominado “group”. Si se llamara de otra forma, la cláusula WHERE no se podría analizar. La cláusula equivalente con corchetes sería como sigue:
(assignee = @cnt.id OR group.[group]group_list.member IN (@cnt.id)) AND active = 1
No es posible ampliar la notación con puntos. Por ejemplo, lo siguiente no funcionaría:
affected_resource.[parent]child_hier.child.name IN ('chicago1')
Consultas basadas en prioridades
En la base de datos, la tabla Priority tiene dos columnas denominadas sym y enum. Los valores que ve el usuario son los correspondientes a sym. No obstante, la aplicación detecta los valores de sym basados en los valores de enum. Actualmente, los valores predeterminados de sym del 1 al 5 se invierten en los valores correspondientes de enum.
Ejemplo
Símb.
Número
1
5
2
4
3
3
4
2
5
1
Por tanto, al escribir la consulta almacenada, si se hace referencia al valor 5 en realidad se busca la prioridad 1, a menos que se utilice .sym para especificar el atributo que se buscará.
No cambie los valores predeterminados de enum que asigna el producto. En su lugar, si se agregan valores de sym nuevos, continúe a partir del valor de enum más alto y así sucesivamente.
Consultas basadas en tiempo
Se pueden emplear espacios de tiempo para crear consultas almacenadas basadas en tiempo. Los espacios de tiempo especifican períodos de tiempo, que pueden hacer referencia a la fecha actual. Por ejemplo, un espacio de tiempo podría hacer referencia a hoy, ayer, la semana pasada o el mes pasado. Los espacios de tiempo tienen nombre, como por ejemplo TODAY o YESTERDAY. En las consultas almacenadas se hace referencia a los espacios de tiempo mediante el uso de una de estas dos funciones integradas:
  • StartAtTime (
    nombre-espaciotiempo
    )
    Hace referencia al principio del período descrito por el espacio de tiempo.
  • EndAtTime (nombre-espaciotiempo)
    Hace referencia al final del período descrito por el espacio de tiempo.
Las reglas de sintaxis para las consultas almacenadas requieren que el nombre del espacio de tiempo esté delimitado por comillas simples, delante de las cuales se incluye una barra inversa. Por ejemplo, para hacer referencia al principio de la semana pasada, habría que especificar:
StartAtTime(\'PAST_WEEK\')
El paso del tiempo hace necesaria la actualización periódica de las consultas almacenadas que contienen referencias a espacios de tiempo. Por ejemplo, el intervalo descrito por “YESTERDAY” cambia a medianoche. La Hora de inicio, la Hora de finalización y la Fecha de activación para las actualizaciones se especifica en la ventana Detalles de espacio de tiempo.
Hora de inicio
La hora de inicio especifica el principio del espacio de tiempo en términos absolutos o relativos. En la tabla siguiente se describen los campos de la sección Hora de inicio de la ventana Detalles de espacio de tiempo:
  • Año
    Un año explícito, como 2000, o un año relativo como +1 (año siguiente) o –1 (año pasado).
  • Mes
    Un mes explícito del 1 (enero) al 12 (diciembre), o bien un mes relativo como +1 (mes siguiente) o –1 (mes pasado).
  • Día
    Un día explícito del 1 al 31, o bien un día relativo como +1 (mañana) o –1 (ayer).
  • Hora
    Una hora explícita entre 0 y 24, o bien una hora relativa como +1 (hora siguiente) o –1 (hora anterior).
  • Minuto
    Un minuto explícito entre 0 y 59, o bien un minuto relativo como +1 o –1.
Hora de finalización
La hora de finalización especifica el final del espacio de tiempo en términos absolutos o relativos. Los campos correspondientes a Hora de finalización de la ventana Detalles de espacio de tiempo son los mismos que los campos correspondientes a Hora de inicio de dicha ventana.
Fecha de activación
El campo Fecha de activación especifica cuándo se crea la cláusula WHERE de una consulta almacenada que contiene una referencia al espacio de tiempo y cuándo se actualiza la consulta almacenada. La fecha de activación debe ser relativa a la hora actual, tal y como se describe en la siguiente tabla:
  • Año
    Debe ser un año relativo entre –1 (año pasado) y +36 (36 años a partir de ahora).
  • Mes
    Debe ser un mes relativo entre –1 (mes pasado) y +11 (11 meses a partir de ahora).
  • Día
    Debe ser un día relativo entre –1 (ayer) y +31 (31 días a partir de ahora).
  • Hora
    Debe ser una hora relativa entre –1 (hora anterior) y +23 (23 horas a partir de ahora).
  • Minuto
    Debe ser un número de minutos relativo entre +9 (9 minutos a partir de ahora) y +59 (59 minutos a partir de ahora).