Requêtes du tableau de résultats

Cet article contient les rubriques suivantes :
casm173
Cet article contient les rubriques suivantes :
L’une des tables de la base de données (Cr_Stored_Queries) définit les requêtes stockées. Ces requêtes stockées, qui sont similaires aux requêtes SQL, permettent de personnaliser les champs de compteur sur les noeuds du tableau de résultats dans les interfaces d'administration et Web. Les champs de compteur indiquent le nombre d’enregistrements correspondant à la requête. Par exemple, ils peuvent indiquer le nombre de types de demandes affectées à l'utilisateur connecté.
Chaque utilisateur peut personnaliser les champs de compteur qui apparaissent dans son tableau de résultats, comme expliqué dans l'aide en ligne. L'administrateur de système doit d'abord définir les différents types de demandes qui peuvent être comptées dans ces champs de compteur comme requêtes stockées.
Les calculs des tableaux de résultats seront incorrects si les valeurs des requêtes de base de données sont égales à NULL. Par exemple, si votre requête du tableau d’affichage spécifie que assignee.organization = xyz et qu’un champ de personne assignée est vide (NULL) pour un enregistrement, cet enregistrement ne sera pas inclus dans le calcul du tableau d’affichage.
Requêtes stockées pour l’utilisateur connecté
Deux des champs devant être définis dans la fenêtre Détail de la requête stockée sont Clause Where et Etiquette. Ces deux champs peuvent contenir des expressions personnalisées pour l'utilisateur connecté. Les requêtes stockées font référence à des objets et des attributs plutôt qu’à des noms de tables et à des colonnes. Une requête stockée personnalisée pour l'utilisateur connecté est composée de deux parties :
  • Objet (tel que cr pour une demande)
    Ceci est généralement spécifié à gauche du signe égal (=). La syntaxe de cette partie de la requête stockée est la suivante :
    att_name[.att_name...].SREL_att_name
Une requête stockée possède toujours un type, qui est un nom d’objet par rapport auquel la requête est exécutée et qui fournit le contexte de la requête. Dans la syntaxe précédente, le premier att_name doit être un nom d’attribut de l’objet contexte.
  • L'utilisateur connecté (instance de l'objet cnt pour cet utilisateur)
    Vous devez le spécifier à droite du signe égal (=) si les tickets doivent être sélectionnés en fonction d'un attribut de l'utilisateur connecté. La syntaxe de cette partie de la requête stockée est la suivante :
    @
    att_name
    [.
    att_name
    ...].
    SREL_att_name
Pour plus d'informations sur les objets et les attributs, reportez-vous à la section Commandes de référence de CA Service Desk Manager.
Syntaxe de l’objet cr
Utilisez cette syntaxe si la référence désigne l’objet appel (cr) :
att_name[.att_name...].SREL_att_name
Cet exemple indique la localisation de la personne affectée au traitement du ticket. Dans cet exemple, le nom d’objet n’est pas défini, compte tenu que le type de la requête stockée implique l’objet cr :
[email protected] AND active=1
  • Destinataire
    Attribut de l’objet appel qui est mis en correspondance avec le champ Personne assignée dans la table correspondante. Par exemple, l’attribut assignee est défini dans l’objet cr par SREL agt, ce qui signifie qu’il se réfère au sous-objet agt. Le sous-objet par défaut agt fait partie de la définition de l’objet cnt.
  • location
    Attribut de l’objet cnt correspondant au champ c_l_id de la table Contact. L’attribut location est défini dans l’objet cnt par SREL loc, ce qui signifie qu’il fait référence à l’objet loc.
Clause WHERE
L’exemple suivant indique une valeur que vous pouvez coder dans une clause WHERE :
[email protected] AND active=1
Compte tenu que le type de la requête stockée est une demande, cette requête permet de sélectionner toutes les demandes actives pour lesquelles la localisation de la personne assignée est la même que celle de l'utilisateur connecté.
Etiquette
Vous pouvez inclure les attributs de l’objet cnt dans des étiquettes comme dans les clauses WHERE. Voici un exemple d'utilisation d'un attribut de l'objet cnt dans une étiquette :
@cnt.location.name Calls
Cette étiquette inclut le nom d’une localisation, par exemple Bordeaux, où Bordeaux remplace @cnt.location.name lorsque l’étiquette s’affiche dans une fenêtre. L’étiquette s’affiche sous la forme Appels de Bordeaux.
Mot-clé IN
Grâce au mot clé IN, une requête stockée peut faire référence à deux tables (ou plus) sans création de jointure, ce qui peut considérablement augmenter l’efficacité lors de l’exécution de la requête. Le code est le suivant :
SREL_att_name IN ( value1 [, value2 [,...]] )
Par exemple, vous pouvez coder une requête de demande comme suit :
category.sym IN (\'Soft%\', \'Email\')
Ceci génère la clause WHERE SQL suivante :
category IN (SELECT persid FROM prob_ctg WHERE sym LIKE 'Soft%' OR sym = 'Email')
IN permet, entre autres, d’éviter les produits cartésiens. Par exemple, la requête suivante entraîne un produit cartésien et est particulièrement inefficace :
assignee.last_name LIKE 'MIS%' OR group.last_name LIKE 'MIS%'
Lorsque vous utilisez IN, la requête ne crée pas de produit cartésien ; en fait, elle ne crée pas de jointure du tout, comme dans l'exemple suivant :
assignee.last_name IN 'MIS%' OR group.last_name IN 'MIS%'
Les parenthèses qui encadrent normalement la liste de valeurs à droite de IN peuvent être omises si la liste ne contient qu'une valeur. De même, vous devez éviter les jointures dans les partitions de données en convertissant une partition, comme dans l'exemple suivant :
assignee.last_name LIKE 'Smith' to: assignee = U'374683AA82ACE34AB999A042F3A0BA2E'
où :
  • U
    indique que la valeur est un uuid.
  • ’374683AA82ACE34AB999A042F3A0BA2E’
    Les 32 caractères entre guillemets simples indiquent la représentation d'un UUID réel sous forme de chaîne.
Vous évitez ainsi la jointure même si la requête perd un peu en clarté. IN permet d'écrire la même partition, comme dans l'exemple suivant, présentant autant de clarté que la première version et pratiquement la même efficacité que la seconde :
assignee.last_name IN 'Smith'
CA SDM gère l'application de la clause IN à des listes QREL ou BREL. Par exemple, si vous recherchez toutes les demandes avec des actifs qui sont des parents d'un autre actif spécifique (doté de l'ID 374683AA82ACE34AB999A042F3A0BA2E), la clause WHERE appropriée est la suivante :
affected_resource.[parent]child_hier.child IN (U’374683AA82ACE34AB999A042F3A0BA2E’)
La première partie de la clause,
affected_resource
, est un SREL (clé étrangère) de l'objet cr (demande) pointant vers la table Network_Resource. La partie
child_hier
est la liste des objets hier pointant vers les relations hiérarchiques. La dernière partie,
child
, constitue la première partie de la clause WHERE pour la requête secondaire IN. La partie
374683AA82ACE34AB999A042F3A0BA2E
représente la valeur de la clé étrangère correspondant à
child
.
[parent]
spécifie le renvoi de la requête secondaire. Etant donné que la valeur id est une représentation d'un UUID sous forme de chaîne, elle doit être indiquée comme telle et écrite sous la forme U'374683AA82ACE34AB999A042F3A0BA2E'
L'exemple suivant présente la requête SQL réelle générée, qui fournit toutes les demandes pour lesquelles l'actif est un parent d'un actif spécifique :
SELECT Call_Req.id FROM Call_Req WHERE Call_Req.affected_rc IN (SELECT hier_parent FROM Asset_Assignment WHERE hier_child = U'374683AA82ACE34AB999A042F3A0BA2E')
Pour exécuter des requêtes sur plusieurs parents, vous pouvez indiquer une liste séparée par des virgules dans la partie () de la requête SQL, comme indiqué dans l'exemple suivant :
affected_resource.[parent]child_hier.child IN (U'374683AA82ACE34AB999A042F3A0BA2E', U'374683AA82ACE34AB999A042F3A0BA2E')
Le nom de l'attribut entre crochets ([]) est utilisé pour former la partie SELECT de la clause secondaire. La notation entre crochets n'est pas utilisée pour le groupe Requêtes stockées inclus dans CA Service Desk Manager r6.0, comme indiqué dans l'exemple suivant :
(assignee = @cnt.id OR group.group_list.member IN (@cnt.id)) AND active = 1
Si la notation entre crochets n'est pas utilisée, le sous-système SQL part du principe qu'il s'agit du nom d'attribut du premier symbole dans la partie de notation par insertion de point. Par chance, il apparaît ici que l’objet group_list contient un attribut nommé « group ». Si le nom était différent, la clause Where ne pourrait pas être analysée. La clause équivalente avec des crochets est illustrée comme suit :
(assignee = @cnt.id OR group.[group]group_list.member IN (@cnt.id)) AND active = 1
Vous ne pouvez pas étendre cette notation par insertion de point. Ainsi, l'exemple suivant n'est pas valide :
affected_resource.[parent]child_hier.child.name IN ('chicago1')
Requête en fonction de la priorité
Dans la base de données, la table des priorités (Priority) comporte deux colonnes : sym et enum. La valeur que voit l’utilisateur correspond aux valeurs sym. Quant à l’application, elle voit les valeurs sym en fonction des valeurs enum. Ici, les valeurs sym par défaut 1 à 5 sont l’inverse des valeurs enum.
Exemple
Sym
Enum
1
5
2
4
3
3
4
2
5
1
Par conséquent, lors de l’écriture de la requête stockée, lorsque vous désignez une valeur de 5, vous recherchez en fait une priorité de 1, sauf si vous utilisez une valeur .sym pour spécifier l’attribuer à examiner.
Ne changez pas les valeurs enum par défaut que le produit affecte. Si vous ajoutez des valeurs sym, poursuivez simplement à partir de la valeur enum la plus élevée.
Requêtes temporelles
Les périodes permettent de créer des requêtes stockées temporelles. Une période spécifie un laps de temps qui peut être relatif à la date actuelle. Par exemple, une période peut faire référence à aujourd’hui, à hier, à la semaine dernière ou au mois dernier. Une période a un nom, par exemple TODAY ou YESTERDAY. Pour désigner une période dans une requête stockée, utilisez l'une des deux fonctions intégrées suivantes :
  • StartAtTime (
    nom-période
    )
    Fait référence au début du laps de temps décrit par la période.
  • EndAtTime (nom-période)
    Fait référence à la fin du laps de temps décrit par la période.
Les règles de syntaxe des requêtes stockées exigent que le nom de la période soit entouré de guillemets simples, précédés chacun d’une barre oblique inverse. Par exemple, pour faire référence au début de la semaine dernière, vous devez spécifier :
StartAtTime(\'PAST_WEEK\')
Le passage du temps nécessite d’actualiser périodiquement les requêtes stockées contenant une référence à une période. Par exemple, l’intervalle décrit par « yesterday » change à minuit. Pour l’actualiser, spécifiez l’heure de début, l’heure de fin et l’heure de déclenchement dans la fenêtre Détail de la période.
Heure de début
L’heure de début spécifie le début de la période en termes absolus ou relatifs. Le tableau ci-dessous décrit les champs de la section Heure de début de la fenêtre Détail de la période.
  • Année
    Année explicite, telle que 2000, ou relative, telle que +1 (année suivante) ou -1 (année précédente)
  • Mois
    Mois explicite de 1 (janvier) à 12 (décembre) ou relatif, tel que +1 (mois suivant) ou -1 (mois précédent)
  • Jour
    Jour explicite de 1 à 31 ou relatif, tel que +1 (demain) ou -1 (hier)
  • Heure
    Heure explicite de 0 à 24 ou relative, telle que +1 (heure suivante) ou -1 (heure précédente)
  • Minute
    Minute explicite de 0 à 59 ou relative, telle que +1 ou -1
Heure de fin
L’heure de fin spécifie la fin de la période en termes absolus ou relatifs. Les champs Heure de fin de la fenêtre Détail de la période sont les mêmes que les champs Heure de début de cette fenêtre.
Heure de déclenchement
Le champ Heure de déclenchement indique quand la clause WHERE d’une requête stockée contenant une référence à la période est recréée et la requête stockée actualisée. L’heure de déclenchement doit être relative à l’heure actuelle comme l’indique le tableau suivant :
  • Année
    Doit être une année relative de -1 (année précédente) à +36 (36 années à partir de maintenant).
  • Mois
    Doit être un mois relatif de -1 (mois précédent) à +11 (11 mois à partir de maintenant).
  • Jour
    Doit être un jour relatif de -1 (hier) à +31 (31 jours à partir de maintenant).
  • Heure
    Doit être une heure relative de -1 (heure précédente) à +23 (23 heures à partir de maintenant).
  • Minute
    Doit être une minute relative de +9 (9 minutes à partir de maintenant) à +59 (59 minutes à partir de maintenant).