Contents
Éditeur Paramètres
L'éditeur de paramètres vous permet de créer des paramètres de règles, qui sont utilisés éventuellement dans des conditions et des actions de règles.
Chaque paramètre contient les mêmes champs dans la section Détails :
Nom — Nom du paramètre. Description — Brève description du paramètre. Type — Type de paramètre. Vous trouverez plus de détails sur les types dans les rubriques suivantes.
Noms de paramètre
Le caractère de soulignement dans les noms de paramètres a une signification particulière lors de l'élaboration de modèles de règle. Il permet de spécifier un index du paramètre lorsque l'expression de la règle nécessite des instances supplémentaires du paramètre. L'exemple le plus courant est une définition de plage.
Par exemple, supposons que vous ayez besoin de créer une condition qui doit vérifier si la date d'échéance de la tâche est comprise dans la plage de la date1 à la date2 ou dans la plage de la date3 à la date4. Vous pouvez créer une condition telle que :
Due is in "{dueDT1}" to "{dueDT2}" or in "{dueDT3}" to "{dueDT4}")
Mais ceci nécessite la définition de 4 paramètres avec type InputDate dans la section Paramètres. Cette approche peut devenir inefficace, particulièrement s'il existe plus d'une occurrence de la condition/action.
La meilleure solution est d'utiliser le soulignage et l'indexation :
Due is in "{dueDT_1}" to "{dueDT_2}" or in "{dueDT_3}" to "{dueDT_4}"
En utilisant cette approche, vous devez spécifier un seul paramètre, avec le nom DueDT et le type InputDate.
Catégories de paramètres
La section Configuration contient des informations dépendantes du type de paramètre. Lorsqu'un type est sélectionné dans la liste déroulante, différents champs relatifs à ce type sont affichés.
Il existe huit catégories principales de paramètres :
- Chaîne
- Nombre entier
- Numérique
- Date
- Heure
- Booléen
- Calendrier
- Configuration Server
Valeurs d'entrée
Booléen, Entier, Numérique, Chaîne, Date et Heure sont simplement des paramètres pour lesquels le créateur de règles peut fournir une valeur basée sur le type de paramètre défini. Ces paramètres peuvent également être limités. Par exemple, une valeur entière peut être contrainte de se situer au sein d'une plage définie.
Modèles de mappage
Pour les paramètres de valeur d'entrée de type Chaîne, vous pouvez entrer un modèle correspondant qui doit être suivi. Entrez une expression régulière JavaScript pour définir le modèle correspondant. Par exemple, un paramètre de code ZIP peut avoir le modèle correspondant :
>^\d{5}$|^\d{5}-\d{4}$
qui représente un code postal à 5 chiffres. Un paramètre Numéro de téléphone peut avoir le modèle correspondant :
^\(?(\d{3})\)?[- ]?(\d{3})[- ]?(\d{4})$
qui représente un numéro de téléphone à 10 chiffres au format (xxx)-xxx-xxxx.
Infobulles personnalisées
L'utilisation d'une infobulle personnalisée vous permet d'entrer un texte d'infobulle utile lorsque vous définissez tous les paramètres de la valeur d'entrée (hormis le type de paramètre booléen qui ne nécessite pas d'infobulle). Si vous cochez Utiliser une infobulle personnalisée, le texte que vous entrez dans le champ de l'infobulle est affiché dans GRAT si ce paramètre est utilisé dans une action ou une condition de règle. Si vous ne cochez pas la case Utiliser une infobulle personnalisée, GRAT affiche une infobulle automatiquement créée. Par exemple, {age} est un entier compris entre 1 et 99.
Le modèle regex approuvé doit être compatible avec le moteur JavaScript du navigateur et peut varier légèrement selon la version du navigateur.
Calendriers
Les paramètres de calendrier indiquent à GRAT qu'il doit afficher une liste déroulante des calendriers professionnels associés à l'ensemble de règles en cours de modification. Le créateur de règles peut ensuite choisir l'un des calendriers.
Exemple : Les paramètres de calendrier peuvent être utilisés dans une règle pour attribuer dynamiquement un calendrier comme suit :
Assign business calendar "{businessCalendar}"
Lors de la définition d'un paramètre Calendrier, le designer de modèle doit uniquement indiquer le nom du paramètre et sélectionner un type de calendrier. Aucune autre configuration n'est nécessaire.
Configuration Server
Les paramètres de Configuration Server permettent au créateur de la règle de choisir une valeur unique dans une liste déroulante. Par exemple, un paramètre Configuration Server peut être configuré pour extraire une liste de groupes d'agents de la base de données de Configuration Server. La liste est remplie à partir de Configuration Server. Les paramètres de Configuration Server requièrent que vous sélectionniez le type d'objet :
- Agent
- Groupes d'agents
- Compétences d'agent
- Attribut professionnel
- Contexte professionnel
- Extension
- Point de routage externe
- File d'attente des interactions
- Type de média
- Emplacement
- Groupes de places
- Point de routage
- Autocommutateur
- T-Server
- Points de routage virtuels
Si vous sélectionnez Attribut professionnel, vous pouvez sélectionner le nom de l'attribut professionnel dans une liste définie dans Configuration Manager.
La sélection de Contexte professionnel vous invite à entrer le niveau de contexte professionnel qui vous intéresse pour ce paramètre. Le contexte professionnel fait ici référence au niveau de la hiérarchie sous le dossier Structure d'entreprise dans Configuration Server.
Base de données
Les paramètres de base de données permettent au créateur de choisir une valeur unique dans une liste déroulante. Par exemple, un paramètre de base de données peut être configuré pour extraire une liste de types d'ordre à partir d'une base de données. La liste est renplie par une requête de base de données. Les paramètres de base de données exigent le nom de profil (le nom de l'objet Configuration Server Script qui contient vos informations de connexion à la base de données), le type de requête (valeur unique ou liste, selon les éléments à afficher dans GRAT) et la requête SQL à exécuter.
Remarque : La liste de valeurs est extraite au moment où le créateur des règles se connecte à GRAT. Si des valeurs sont mises à jour à partir du système externe après la connexion de l'utilisateur à GRAT, l'utilisateur doit cliquer sur le bouton Déconnexion, puis se connecter à nouveau pour afficher les modifications.
Exemple
Pour utiliser un paramètre de base de données, un profil de paramètre doit auparavant avoir été configuré pour le locataire de Configuration Server. Il s'agit d'un objet Script qui spécifie le pilote JDBC, ainsi que l'URL, le nom d'utilisateur et le mot de passe de la base de données nécessaires pour exécuter la requête. Pour en savoir plus sur la configuration des profils, reportez-vous au Guide de déploiement de Genesys Rules System. Le nom de cet objet Script est utilisé comme nom de profil pour le paramètre de base de données.
Pour obtenir des valeurs de la base de données, une instruction Select SQL valide doit être spécifiée. Par exemple, pour obtenir toutes les valeurs d'une colonne, utilisez une instruction de sélection comme suit :
SELECT column_name FROM table_name
Pour les paramètres de base de données dynamiques, vous pouvez configurer le paramètre de manière à ce qu'un nom (valeur interne fournie avec une demande d'évaluation de règle) et une étiquette (informations qui sont affichées à un créateur de règles lors de la création d'une règle utilisant ce paramètre) puissent être extraits de deux colonnes de base de données différentes.
|
Propriété |
Obligatoire/facultatif |
Description |
|---|---|---|
| driver | Obligatoire | Nom du pilote JDBC à utiliser. Par exemple, com.mysql.jdbc.Driver |
| url | Obligatoire | L'URL de la base de données au format correct pour le pilote JBDC à utiliser. |
| username | Obligatoire | Nom d'utilisateur valide pour vous connecter à la base de données. |
| password | Obligatoire | Mot de passe requis pour la connexion de l'utilisateur à la base de données. |
| initSize | Facultatif | Taille initiale du groupe de connexions. La valeur par défaut est 5. |
| maxSize | Facultatif | Taille maximale du groupe de connexions. La valeur par défaut est 30. |
| waitTime | Facultatif | Le délai maximal (en millisecondes) à attendre avant d'obtenir une connexion. La valeur par défaut est de 5000. |
En général, il n'est pas nécessaire de définir ou de modifier des valeurs facultatives.
En développement de modèles, vous pouvez uniquement configurer des paramètres de base de données avec une instruction SELECT SQL. Tout autre type d'instruction échoue lors de la configuration.
Opérationnel
Les paramètres opérationnels sont créés par les utilisateurs par le biais de Genesys Administrator Extension et, lorsqu'ils sont déployés, sont stockés en tant qu'options des objets Transaction du type liste dans la base de données de Genesys Configuration Server. Au moment d'exécuter la règle, lorsque Rules Engine évalue une règle qui contient un paramètre Opérationnel, il obtient la valeur actuelle de l'option d'objet Transaction associée depuis Configuration Server. Le développeur de la règle détermine à partir de quel objet Transaction, et de quelle option de cet objet, la valeur du paramètre Opérationnel est extraite, et le créateur de la règle utilise ce paramètre dans le cadre d'une condition ou d'une action.
Exemple Un paramètre Opérationnel appelé waitTimeThreshold peut être défini. Si un appelant attend plus longtemps que ce seuil pour un agent disponible, une autre action peut être effectuée.
Plutôt que de spécifier une valeur pour le seuil de la règle comme suit :
When Caller’s wait time is greater than 30 seconds Then Offer a callback
le créateur de la règle pourrait spécifier ceci :
When
Caller’s wait time is greater than {waitTimeThreshold}
Then
Offer a callback
Un utilisateur peut modifier à tout moment la valeur de {waitTimeThreshold} à l'aide de Genesys Administrator Extension et celle-ci prend immédiatement effet sans passer par la modification ou le redéploiement d'un ensemble de règles.
Par exemple, utilisez la condition suivante lorsque vous définissez le mappage :
Queue(waitTime > {waitTimeThreshold} )
Pour configurer un paramètre opérationnel, vous avez besoin de deux ID :
- L'ID de liste, qui correspond au nom de l'objet de transaction dans lequel le paramètre opérationnel est conservé
- L'ID de paramètre, correspondant au nom d'une option de cet objet de transaction.
La valeur de l'option contient la valeur réelle du paramètre Opérationnel récupéré par Rules Engine lors de l'évaluation de la règle. Les paramètres opérationnels sont toujours stockés sous forme d'objets de transaction de type Liste, mais la configuration précise des options dans cet objet Liste varie en fonction de la configuration du paramètre Opérationnel.
- Expression de langage — Estimation du temps d'attente supérieur à {opParmEwtThreshold}
- Mappage du langage des règles — CallInfo ( ewt > Integer.parseInt({opParmEwtThreshold}))
Notez qu'il n'y a pas de guillemets anglais simples ou doubles autour de {opParmEwtThreshold}
Pour des exemples supplémentaires, voir l'exemple de modèle « Paramètres opérationnels » et l'ensemble de règles fourni avec GRAT (dans le dossier exemples).
Consultez l'aide de Genesys Administrator Extension pour des informations générales sur les paramètres Opérationnels.
Sélectionner l'énumération
Les paramètres Sélectionner l'énumération sont liés à une Énumération. Le créateur de règles peut ainsi effectuer des sélections à partir d'une liste spécifique.
Services Web
Les paramètres de services Web permettent au créateur des règles de choisir une valeur unique dans une liste déroulante. Par exemple, un paramètre de service Web peut être configuré pour extraire une liste de symboles boursiers à partir d'un service Web externe. La liste est remplie par une requête de service Web. Les paramètres de services Web nécessitent le nom de profil (nom de l'objet Configuration Server Script qui contient les informations de connexion de votre service Web), le type de requête (liste ou valeur unique) et la requête XPath à exécuter. De plus, les paramètres de services Web exigent que certains paramètres de protocoles soient entrés, notamment la méthode HTTP, le chemin et le corps du message.
Remarque : La liste de valeurs est extraite au moment où le créateur des règles se connecte à GRAT. Si des valeurs sont mises à jour à partir du système externe après la connexion de l'utilisateur à GRAT, l'utilisateur doit cliquer sur le bouton Déconnexion, puis se connecter à nouveau pour afficher les modifications.
Exemple
Similaire à un paramètre de base de données, un profil de paramètre doit avoir été préalablement créé. Ce profil contiendra des informations telles que l'adresse du serveur (hôte et port), le chemin d'accès au service et tout autre paramètre HTTP nécessaire. Pour en savoir plus sur la configuration de ces profils, reportez-vous au Guide de déploiement de Genesys Rules System.
Pour obtenir des valeurs du service, un message valide pour le service doit être spécifié. Ce message doit être constant. En d'autres termes, aucune substitution de variable ne se produira.
Remarque : Aucun message ne peut être envoyé pour les requêtes HTTP GET. Toutes les informations contenues dans la requête sont fournies via la chaîne de requête et/ou les en-têtes.
Par exemple, pour obtenir la prévision météo de San Francisco, vous pouvez faire la demande suivante auprès du service Weather Underground REST :
http://api.wunderground.com/auto/wui/geo/ForecastXML/index.xml?query=94129
Il s'agit toutefois de la requête complète. L'hôte (api.wunderground.com) et le chemin de base (/auto/wui/geo/ForecastXML/) doivent être spécifiés dans le profil.
Pour définir un paramètre afin de formuler cette requête, le nom de profil doit faire référence aux informations correctes décrites précédemment. De plus, les paramètres de protocole doivent spécifier GET comme méthode, avec index.xml?query=94129 comme chemin. Aucun message n'est requis pour cette requête.
Pour obtenir les valeurs du résultat, une expression XPath valide doit être spécifiée. Le service Web doit renvoyer les résultats au format XML ou JSON. Voir la section Spécifications XPath pour plus d'informations sur les expressions XPath.
Par exemple, pour obtenir les maximums prévus à partir de la requête décrite précédemment, l'expression XPath suivante peut être utilisée :
//high/fahrenheit/text()
Dans Configuration Server, les scripts de service Web doivent avoir une section appelée WebService. Le tableau ci-dessous répertorie les propriétés que vous pouvez spécifier pour les paramètres du service Web.
|
Propriété |
Obligatoire/facultatif |
Description |
|---|---|---|
| host | Obligatoire | Hôte pour le service. |
| base-path | Obligatoire | Chemin de base pour accéder au service. |
| protocol | Facultatif | La valeur par défaut est http. |
| port | Facultatif | La valeur par défaut est 80. |
| headers | Facultatif | Tous les en-têtes HTTP personnalisés nécessaires au service. |
| parameters | Facultatif | Tous les paramètres HTTP personnalisés nécessaires à la personnalisation de la connexion. |
En règle générale, il n'est pas nécessaire de définir ou de modifier les valeurs de paramètres. Les en-têtes et paramètres sont des listes au format suivant :
key:value[,key:value]
Vous ne pouvez pas spécifier d'en-tête ou de paramètres contenant « , » dans la valeur. Si vous envoyez un message au service, il est attendu que Content-Type soit spécifié dans l'en-tête, car ce paramètre définit l'interaction de message globale avec le serveur. Un jeu de caractères facultatif peut être inclus. Par exemple, Content-Type:applicaton/json;charset=UTF-8.
Dans le développement de modèles, le chemin d'accès au paramètre est ajouté au base_path dans le script. Par exemple, si le script contient :
host = api.wunderground.com base_path = /auto/wui/geo/ForecastXML/
et que le GRDT spécifie :
query type = List XPath Query = //high/fahrenheit/text() HTTP Method = GET path = index.xml?query=66062 message (not set)
alors le message envoyé est :
GET /auto/wui/geo/ForecastXML/index.xml?query=66062 HTTP/1.1
Cela renverra les maximums de la semaine en Fahrenheit :
81 77 81 81 83 85
Workforce Management
Les paramètres de Workforce Management (WFM) permettent au créateur de règles de sélectionner une valeur dans une liste déroulante d'activités (un objet de base de données WFM représentant les tâches du centre de contact dans lesquelles les agents peuvent être impliqués) et de définir des activités multisite (ensemble d'activités réalisées sur plusieurs sites physiques) qui sont récupérées dynamiquement à partir du serveur de Genesys Workforce Management. Les paramètres de Workforce Management nécessitent le profil WFM (l'objet Configuration Server Script de type Collection de données).
Exemple
Une activité est l'objet de planification principal utilisé lors de l'élaboration de prévisions et de calendriers. Une activité peut être associée à un objet Site individuel WFM ou des activités multisite peuvent être créées au niveau de l'unité commerciale WFM, qui regroupe des informations de plusieurs activités « enfants » sur plusieurs sites WFM. Par conséquent, lorsque vous fournissez des règles pour créer une liste d'activités WFM extraites dynamiquement à partir de WFM Server, le nom de l'activité WFM ou de l'activité multisite est précédé du nom du site WFM ou de l'unité commerciale WFM, respectivement.
Par exemple, si la configuration WFM présente la structure suivante :
Unité commerciale portant le nom « ACME »
- Site portant le nom « San Francisco »
- Activité portant le nom « Différends »
- Activité portant le nom « Demandes de facturation »
- Site portant le nom « Chicago »
- Activité portant le nom « Différends »
- Activité portant le nom « Modifications d'adresses »
- Activité multisite sous le nom de « Facturation » (comprenant les « Demandes de facturation » du site de San Francisco et les « Modifications d'adresses » du site de Chicago)
- Activité multisite sous le nom de « Différends » (comprenant les « Différends » du site de San Francisco et les « Différends » du site de Chicago)
Le créateur des règles affichera les éléments suivants dans la liste déroulante lors de l'utilisation de l'action de règle Affecter l'activité WFM dans une règle :
U.O. ACME : Facturation U.O. ACME : Différends Site de Chicago : Modifications d'adresse Site de Chicago : Différends Site de San Francisco : Demandes de facturation Site de San Francisco : Différends
Dans Configuration Server, les scripts Workforce Management doivent comporter une section appelée wfm. Le tableau ci-après répertorie les propriétés que vous pouvez spécifier pour les paramètres de Workforce Management.
|
Propriété |
Obligatoire/facultatif |
Description |
|---|---|---|
| wfmCfgServerApplName | Obligatoire | Nom de l'application Configuration Server pour le serveur WFM. |
| wfmCfgServerUserName | Obligatoire | Nom d'utilisateur de Configuration Server |
| wfmCfgServerPassword | Obligatoire | Mot de passe de Configuration Server. |
| wfmServerUrl | Obligatoire | URL de WFM Server. |
Lors de la configuration d'un nouveau paramètre de type « Workforce Management » dans le développement de modèles, nommez simplement le paramètre et choisissez le profil WFM (objet de script simplement créé) dans la liste déroulante. Lorsque le créateur utilise ce paramètre, GRAT extrait la liste actuelle des activités WFM à partir de WFM Server et les affiche pour le créateur de la règle.