Création, test et dépannage des Règles des tickets dans le Helpdesk. (4294265)

Création, test et dépannage des Règles des tickets dans le Helpdesk

Notes: Ce document suppose ques les règles de tickets du helpdesk:

Avant de commencer

Les meilleures pratiques:

L'Assistant

Bien que ce document ne parle pas de l'assistant, vous devriez vérifier que  l'assistant ne puisse accomplir ce que vous vouliez avant de poursuivre la lecture cet article. L'assitant est un moyen beaucoup plus facile, plus rapide et fiable pour créer une règle.

La requête "Query": Base de données et les tables de helpdesk

La connaissance de la base de données et le schéma sera d'une grande aide. Reportez-vous à nos autres articles sur l'accès à la base de données en utilisant MySQL Query Browser ou d'autres outils et le schéma de base de données. Contactez le support technique avec toutes vos questions.

Les tableaux liés au service d'assistance le plus fréquemment consultés sont:

Essais & résultats de votre requête
Affichage et Emailing Query Results:

Envoyer email personnalisé à tout compte:Un email très personnalisée peu être également envoyer rapidement, en texte brut avec un message à vous-même (ou un compte de test).
Un email peut être envoyé n'importe où simplement en ajoutant dans une chaîne de caractère la colonne aliasé. 

Par exemples:

SELECT 'testuser@testdomain.com' AS TESTEMAIL FROM HD_TICKET

Ou

SELECT 'testuser@testdomain.com, testuser2@testdomain2.com' AS TESTMULTIPLEEMAIL FROM HD_TICKET

Maintenant vous pouvez configurer l'email, pour se faire aller sur testEmail ou TESTMULTIPLEEMAIL. Voir plus dans la section suivante sur la façon de personnaliser les données dans le corps de l'email.

Requêtes de test avec MySQL Query Browser
MySQL Query Browser peut être utilisé pour tester les résultats des requête à l'avance. Ceci est une manière beaucoup plus rapide de faire des essais et pour recevoir des informations de manière instantanées sur les erreurs de syntaxe et les données manquantes.

Connexion d'entrées à un ticket

Un message personnalisé peut être enregistré comme une entrée dans un billet, il peu aussi être utiliser comme un message de débogage simple pour vos tests.

Note: Cette entrée ne peut pas avoir toutes les données des résultats de la requête, mais elle peut contenir tout le texte que vous voulez. Voir la documentation pour plus d'information sur le sujet. Utilisez des emails personnalisés pour le débogage des données.

Mise en oeuvre des actions

Envoie d'emails pour obtenir le résultat d'un champ:

• informer des nouveautés

• aviser de corrections de bugs

• en vers le portail de support utilisateur
• Demander à un client de vérifier leurs informations de contact

Voici un exemple d'une règle qui compare les dates d'échéance/due dates avec la date actuelle. Si la date d'échéance est passé, alors il sera marquer comme un ticket très urgent et un rappel sera envoyer par email.

Dans cette requête beacoup des colonnes ont été générer par l'assistant. Faites une selection global du code SQL ci-dessous et faite le test, l'idée étant de comparer la date d'échéance/due date avec la date et heure actuelle. Cette requète ne fonctionne pas sur les ticket fermés. 

select HD_TICKET.*,
   HD_TICKET.ID as TICKNUM,
   DATE_FORMAT(HD_TICKET.CREATED,'%b %d %Y %I:%i:%s %p') as CREATED,
   DATE_FORMAT(HD_TICKET.MODIFIED,'%b %d %Y %I:%i:%s %p') as MODIFIED,
   HD_STATUS.NAME AS STATUS_NAME,
   HD_STATUS.ORDINAL as STATUS_ORDINAL,
   STATE,
   U1.USER_NAME as OWNER_NAME,
   U1.FULL_NAME as OWNER_FULLNAME,
   U1.EMAIL as OWNER_EMAIL,
   U2.USER_NAME as SUBMITTER_NAME,
   U2.FULL_NAME as SUBMITTER_FULLNAME,
   U2.EMAIL as SUBMITTER_EMAIL

from HD_TICKET,
   HD_PRIORITY,
   HD_STATUS,
   HD_IMPACT,
   HD_CATEGORY left join USER U1 on U1.ID = HD_TICKET.OWNER_ID
   left join USER U2 on U2.ID = HD_TICKET.SUBMITTER_ID                  

where HD_PRIORITY.ID = HD_PRIORITY_ID and
   HD_STATUS.ID = HD_STATUS_ID and
   HD_IMPACT.ID = HD_IMPACT_ID and
   HD_CATEGORY.ID = HD_CATEGORY_ID and
   HD_TICKET.DUE_DATE < NOW() and  
   HD_STATUS.NAME

Maintenant, l'e-mail personnalisé peut être envoyé au propriétaire avec du contenu dynamique. Cet exemple ci-dessous va générer un email comme indiqué.

Faire une mise à jour

Une déclaration de mise à jour peut être effectuée, elle va modifier les données dans la base de données. Maintenant que nous avons construit un email qui va informer les propriétaires, nous allons faire la mise à jour comme promis, et définir la priorité élevé.

 update HD_TICKET as T set T.HD_PRIORITY_ID = 2 where T.ID in ()

Remarque: il est automatiquement transmis comme une liste délimitée de toutes les valeurs d'une colonne appelée ID qui dans notre cas était HD_TICKET.ID ou spécifiquement 6288.

• Autre remarque: Vous ne pouvez pas effectuer une mise à jour qui va envoyer un autre email ou d'une autre règle.

Le facteur le plus important ici sont les données sur lesquelles vous-souhaitez agir. Les modifications apportées à un ticket spécifique à la demande, ou une approche par lots sur une base planifiée.

Remarques sur les tickets plannifier: Il ya un problème connu avec l'appliance K1000 qui empêche de programmer les règles de ticket à une heure du jour, en effet cela peu blogé le fonctionnement d'une règle de ticket. Toutefois, le ticket sera toujours fonctionnel à la même heure de la journée sur cette base, même si la règle a été modifiée. Par conséquent, pour faire fonctionné cette règle tous les jours à 22h00, ré-enregistrer la à 22h00.

Les règles de ticket peuvent être combinée en utilisant la "* ticket ordering rule *". voir ici What are ticket rules pour plus d'informations à ce sujet.

Pour aller plus loin dans le dépannage

Utilisation du journal d'execution

Le journal d'exécution apparaît au bas de l'écran avec toutes les avanver de vos actions (les requêtes, des actions de messagerie, entrée des tickets et déclarations de mise à jour). Il vous montrera l'information la plus récente.

Le bouton Exécuter maintenant

Le bouton Exécuter maintenant est utile si vous testez ou l'exécuter une règle qui est une règle créer par lots.

Note:  Il n'est pas utile pour tester la plupart des tickets, parce qu'ils dépendent des règles de sauvegarde et du numéro de ticket spécifique,  souvent il est nécéssaire de faire des actions sur les echanges de données.

Autres techniques simples

Limitez vos résultats de tests en utilisant des numéros id spécifiques pour vos ticket

Si vous tester un ticket ouvert spécifique ou un ticket étant classé supérieure à, alors envisager d'ajouter ceci à votre requête et/ou mise à jour afin de limiter la portée de votre test. Vous pourvez ensuite suppimer ces tests une fois que vous êtres sur des résultats.

Accèder aux utilisateurs

• L'OWNER_ID dans la colonne HD_TICKET se réfère à l'actuel propriétaire de l'enregistrement, qui peut être changé.
• Le SUBMITTER_ID dans la colonne HD_TICKET se réfère à l'émetteur actuel du dossier, qui peut être changé.
• L'USER_ID dans la colonne HD_TICKET_CHANGE se réfère à la mise à jour. Cela n'est pas nécessairement le propriétaire du ticket, ni l'expéditeur.
• Une audit sur l'expéditeur d'origine serais très difficile, voir impossible à suivre avec l'éditeur SQL par default. Vous devriez regarder le ticket manuellement et lire sont historique.

Obtenir l'accès à des tickets dans d'autres files d'attente

Il serais possible de le faire en ajoutant ce qui suit à la clause OU dans votre requète:

 and HD_QUEUE_ID=X

OU X est le numéro d'identification ID de l'autre file d'attente qui peut être déterminé en regardant la table HD_QUEUE_ID.