Consultas ao placar

Este artigo contém os seguintes tópicos:
casm173
Este artigo contém os seguintes tópicos:
Uma das tabelas do banco de dados, Cr_Stored_Queries, define consultas armazenadas. Essas consultas armazenadas, que são muito semelhantes a consultas SQL, podem ser usadas para personalizar os campos de contadores nos nós localizados na área de gerenciador de filas das interfaces administrativa e da web. Os campos de contadores informam quantos registros correspondem à consulta. Por exemplo, eles podem informar quantos dos diversos tipos de solicitações foram atribuídos ao usuário conectado.
Cada usuário pode personalizar os campos de contadores que aparecem no gerenciador de filas (isso é explicado na ajuda online). No entanto, o administrador do sistema deve definir primeiro os diversos tipos de requisições que podem ser contadas nesses campos de contadores como consultas armazenadas.
As contagens do gerenciador de filas estarão incorretas se os valores de consulta ao banco de dados forem iguais a NULL. Por exemplo, se a consulta ao placar especificar que assignee.organization = xyz e um campo Destinatário de um registro estiver vazio (NULL), este registro não fará parte da contagem do placar.
Consultas armazenadas para usuários conectados
Dois dos campos que devem ser definidos na janela Detalhes da consulta armazenada são Cláusula Where e Label. Ambos podem conter expressões que são personalizadas para o usuário conectado. As consultas armazenadas fazem referência a objetos e atributos, e não a nomes de tabela e colunas. Uma consulta armazenada personalizada para o usuário conectado consiste nas duas seguintes partes:
  • O objeto (como cr para uma solicitação).
    Em geral é especificado à esquerda do sinal de igual (=). A sintaxe para esta parte da consulta armazenada é:
    att_name[.att_name...].SREL_att_name
Uma consulta armazenada sempre tem um Tipo, que é um nome de objeto em que a consulta é executada e fornece o contexto da consulta. Na sintaxe acima, o primeiro att_name deve ser um nome de atributo do objeto de contexto.
  • O usuário conectado (a instância do objeto cnt para este usuário).
    Este item deverá ser especificado à direita do sinal de igual (=) se os tickets forem selecionados com base em um atributo do usuário conectado. A sintaxe para esta parte da consulta armazenada é:
    @
    nome_do_astributo
    [.
    nome_do_atributo
    ...].
    nome_do_atributo_SREL
Para obter mais informações sobre objetos e atributos, consulte a seção Comandos de referência do CA Service Desk Manager.
Sintaxe para o objeto cr
Use esta sintaxe se for feita referência ao objeto de solicitação (cr):
att_name[.att_name...].SREL_att_name
Este exemplo identifica a localização da pessoa designada para lidar com um ticket. Nesse exemplo, o nome do objeto é omitido, pois o tipo da consulta armazenada implica o objeto cr:
[email protected] AND active=1
  • responsável
    O atributo no objeto de solicitação que mapeia para o campo Destinatário na tabela correspondente. Por exemplo, o atributo assignee é definido no objeto cr com SREL agt, o que significa que ele se refere à fábrica agt. A fábrica agt faz parte da definição do objeto cnt.
  • local
    O atributo do objeto cnt que mapeia para o campo c_l_id na tabela Contact. O atributo location é definido no objeto cnt com SREL loc, o que significa que ele se refere ao objeto loc.
Cláusula WHERE
O exemplo a seguir demonstra um valor que pode ser codificado em uma cláusula WHERE:
[email protected] AND active=1
Se o tipo de Consultas armazenadas for uma Solicitação, esta consulta selecionará todas as solicitações ativas cujo local do destinatário é o mesmo do usuário conectado.
Rótulo
Os atributos do objeto cnt podem ser incluídos em rótulos do mesmo modo que são incluídos nas cláusulas WHERE. A seguir é apresentado um exemplo do uso de um atributo do objeto cnt em um rótulo:
@cnt.location.name Calls
Esse rótulo incluirá o nome de um local, por exemplo, Phoenix.Quando o rótulo for exibido em uma janela, @cnt.location.name será substituído por Phoenix. O rótulo será exibido como Chamadas de Phoenix.
Palavra-chave IN
A palavra-chave IN permite que uma consulta armazenada faça referência a duas (ou mais) tabelas sem criar uma união. Isso pode resultar em maior eficiência na execução da consulta. Ela é codificada do seguinte modo:
SREL_att_name IN ( value1 [, value2 [,...]] )
Por exemplo, uma consulta de solicitação poderia ser codificada como:
category.sym IN (\'Soft%\', \'Email\')
Isso resulta na seguinte cláusula WHERE de SQL:
category IN (SELECT persid FROM prob_ctg WHERE sym LIKE 'Soft%' OR sym = 'Email')
Um uso de IN deve evitar produtos cartesianos. Por exemplo, a seguinte consulta resulta em um produto cartesiano e é muito ineficiente:
assignee.last_name LIKE 'MIS%' OR group.last_name LIKE 'MIS%'
Usando a palavra-chave IN, a consulta não cria um produto cartesiano; na verdade, não cria nenhuma união, conforme ilustrado pelo seguinte exemplo:
assignee.last_name IN 'MIS%' OR group.last_name IN 'MIS%'
Os parênteses que normalmente envolvem a lista de valores do lado direito do IN poderão ser omitidos se houver somente um valor na lista. De modo semelhante, é necessário evitar uniões em partições de dados convertendo uma partição de dados, como indicado a seguir:
assignee.last_name LIKE 'Smith' to: assignee = U'374683AA82ACE34AB999A042F3A0BA2E'
em que:
  • U
    indica que o valor é um UUID.
  • '374683AA82ACE34AB999A042F3A0BA2E'
    Os 32 caracteres entre aspas simples indicam a representação de seqüência de caracteres de um UUID real.
Isso evita a união com alguma perda na CA. Usando IN, a mesma partição pode ser gravada como ilustrado no próximo exemplo, com a CA da primeira versão e quase a mesma eficiência da segunda versão:
assignee.last_name IN 'Smith'
O CA SDM aceita a cláusula IN aplicada às listas QREL ou BREL. Por exemplo, para localizar todas as Solicitações com Ativos que são pais de outro Ativo específico (com ID 374683AA82ACE34AB999A042F3A0BA2E), a cláusula WHERE apropriada será a seguinte:
affected_resource.[parent]child_hier.child IN (U’374683AA82ACE34AB999A042F3A0BA2E’)
A primeira parte da cláusula,
affected_resource
, é uma SREL (chave estrangeira) do objeto cr (Solicitação), que aponta para a tabela Network_Resource. A parte
child_hier
é uma lista de objetos hier que aponta para os relacionamentos hierárquicos. A última parte,
child
, forma a primeira parte da cláusula Where para a subconsulta IN. A parte
374683AA82ACE34AB999A042F3A0BA2E
é o valor da chave estrangeira que deve corresponder a
child
.
[pai]
especifica o retorno da subconsulta. Como o valor da ID é uma representação de sequência de caracteres de uma UUID, ele deve ser indicado como tal e escrito como U’374683AA82ACE34AB999A042F3A0BA2E’
A seguir está um exemplo do SQL real gerado, que fornece todas as Solicitações em que o Ativo é pai de um Ativo específico:
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 consultar vários pais, você pode fornecer uma lista separada por vírgulas na parte () do SQL, conforme mostrado pelo seguinte exemplo:
affected_resource.[parent]child_hier.child IN (U'374683AA82ACE34AB999A042F3A0BA2E', U'374683AA82ACE34AB999A042F3A0BA2E')
O nome de atributo entre colchetes ([]) é usado para formar a parte SELECT da subcláusula. A notação por colchetes não é usada para o grupo Consultas armazenadas fornecido com o CA Service Desk Manager Version 6.0, conforme ilustrado neste exemplo:
(assignee = @cnt.id OR group.group_list.member IN (@cnt.id)) AND active = 1
Se a notação por colchetes não for usada, o subsistema SQL assumirá que este é o nome de atributo do primeiro símbolo na parte da notação de ponto. O que ajuda neste caso, por um mero acaso, é que o objeto group_list tem nele um atributo chamado ‘group'. Se tivesse qualquer outro nome, a cláusula Where não poderia fazer a análise! A seguir é mostrada a cláusula equivalente entre colchetes:
(assignee = @cnt.id OR group.[group]group_list.member IN (@cnt.id)) AND active = 1
Não é possível estender a notação de ponto. O exemplo a seguir não funcionaria:
affected_resource.[parent]child_hier.child.name IN ('chicago1')
Consulta com base na prioridade
No banco de dados, a tabela Priority tem duas colunas: sym e enum. Os valores visualizados pelos usuários são os valores symb Mas o aplicativo vê os valores symb com base nos valores enum No momento, os valores symb padrão de 1 a 5 são invertidos para seu valor enum
Exemplo:
Symb
Enum
1
5
2
4
3
3
4
2
5
1
Assim, ao gravar a consulta armazenada, ao referir-se ao valor 5 na verdade você estará procurando a prioridade 1, a menos que use um arquivo .sym para especificar qual atributo será procurado.
Não altere os valores enum padrão que o produto atribui. Em vez disso, ao adicionar novos valores sym, basta continuar do valor enum mais alto em diante.
Consultas com base no tempo
É possível usar períodos para criar consultas armazenadas com base no tempo. Um período especifica um período de tempo, que pode ser relativo à data atual. Por exemplo, um período pode referir-se a hoje, ontem, semana passada ou o mês passado. Um período tem um nome, como TODAY ou YESTERDAY. Para referir-se a um período em uma consulta armazenada, use qualquer das duas seguintes funções internas:
  • StartAtTime (
    nome_do_período
    )
    Essa função refere-se ao início do período de tempo descrito pelo período.
  • EndAtTime (nome_do_período)
    Essa função refere-se ao fim do período de tempo descrito pelo período.
As regras de sintaxe para consultas armazenadas exigem que o nome do período seja colocado entre aspas simples, precedidas por uma barra invertida. Por exemplo, para referir-se ao início da semana passada, especifique:
StartAtTime(\'PAST_WEEK\')
O decorrer do tempo torna necessário atualizar periodicamente uma consulta armazenada que contenha referência a um período. Por exemplo, o intervalo descrito por “ontem” muda à meia-noite. Especifique as atualizações de Hora de início, Hora de término e Hora do acionador na janela Detalhes do período.
hora de início
A Hora de início especifica o início do período em termos absolutos ou relativos. A tabela a seguir descreve os campos da seção Hora de início da janela Detalhes do período:
  • Ano
    Um ano explícito, como 2000, ou um ano relativo, como + 1 (ano que vem) ou – 1 (ano passado)
  • Mês
    Um mês explícito de 1 (Janeiro) a 12 (Dezembro) ou um mês relativo, como + 1 (mês que vem) ou – 1 (mês passado)
  • Dia
    Um dia explícito, de 1 a 31, ou um dia relativo, como +1 (amanhã) ou –1 (ontem)
  • Hora
    Uma hora explícita, de 0 a 24, ou uma hora relativa, como +1 (hora seguinte) ou –1 (hora passada)
  • Minuto
    Um minuto explícito, de 0 a 59, ou um minuto relativo, como +1 ou –1.
Hora de término
A Hora de término especifica o fim do período em termos absolutos ou relativos. Os campos Hora de término da janela Detalhes do período são os mesmos campos de Hora de início da janela Detalhes do período.
Hora do acionador
O campo Hora do acionador especifica quando a cláusula WHERE de uma consulta armazenada que contém uma referência ao período é recriada e quando a consulta armazenada é atualizada. A Hora do acionador deve ser relativa à hora atual, conforme descrito na seguinte tabela:
  • Ano
    Deve ser um ano relativo, de –1 (ano passado) a +36 (daqui a 36 anos).
  • Mês
    Deve ser um mês relativo, de –1 (mês passado) a +11 (daqui a 11 meses).
  • Dia
    Deve ser um dia relativo, de –1 (ontem) a +31 (daqui a 31 dias).
  • Hora
    Deve ser uma hora relativa, de –1 (hora passada) a +23 (daqui a 23 horas).
  • Minuto
    Devem ser minutos relativos, de +9 (daqui a 9 minutos) a +59 (daqui a 59 minutos).