Jump to: navigation, search

Présentation du développement du modèle de règle

Les modèles de règles permettent au développeur de règles commerciales de créer des modèles de règles définissant les conditions et les actions qui seront utilisées par le créateur de la nouvelle règle commerciale. Le développeur crée les instructions en langage brut qui seront affichées par le créateur de la règle commerciale et les mettra en correspondance avec les instructions de langage des règles qu'exécute le moteur de règles. Pour chaque condition et type d'action, le développeur décide du type de données que le créateur des règles fournira. Voici quelques exemples : l'entrée doit être un nombre entier, une valeur numérique non entière, une chaîne, une sélection dans une liste prédéfinie ou une sélection dans une liste dynamique. Les modèles de règles sont utilisés par les créateurs de règles pour élaborer des règles de classification et de hiérarchisation des tâches aux niveaux Mondial, Département et Processus de la structure d'entreprise de la solution Genesys.

Contenu du modèle

Les modèles de règles sont composés de plusieurs éléments :

  • Actions
  • Conditions
  • Énumérations
  • Modèles de fait
  • Événements
  • Fonctions
  • Paramètres

Actions et conditions

Les actions et conditions définissent des scénarios WHEN/THEN, comme WHEN (quand) un client est un client Gold, THEN (alors) la cible est GoldAgentGroup. L'instruction WHEN est la condition et l'instruction THEN, l'action. Une règle est représentée par aucune, une ou plusieurs conditions et aucune, une ou plusieurs actions. Cet exemple inclut également des paramètres : l'état du client (Gold) et le nom du groupe d'agents (GoldAgentGroup).

Chaque fois qu'une condition contient un mappage de langage de règle qui commence par eval(...), vous devez inclure l'expression entière entre parenthèses, comme suit :

( eval(.... ) )

Ceci garantit une compilation correcte avec un opérateur NOT.

Voir Éditeur d'objets et Éditeur de conditions.

Énumérations

Les énumérations permettent de définir des listes de choix possibles à afficher par le créateur de règles commerciale lorsque le créateur crée des règles basées sur ce modèle de règles. Dans certains cas, la liste des choix possibles est sélectionnée dynamiquement dans les objets Genesys Configuration Server ou dans des sources de données externes. Pour les activités WFM et les activités multisite, la liste des options disponibles est récupérée de manière dynamique à partir de Genesys WFM Server. Ainsi, les énumérations sont utilisées lors de la définition d'une liste discrète des choix qui ne changeront pas de façon dynamique.

Consultez Éditeur Énumérations

Modèles de fait

Tous les modèles de règle incluent un modèle de fait avec un ou plusieurs faits. Un modèle de fait structure les connaissances de base sur les opérations commerciales du point de vue professionnel. Un modèle de fait se concentre sur les connexions logiques (dites « faits ») entre les concepts de base de l'entreprise. Il indique les éléments nécessaires sur les opérations de l'entreprise afin de prendre en charge (ou d'effectuer) ces opérations.

Un bon modèle de fait vous explique comment structurer votre pensée de base (ou connaissance) par rapport au processus d'entreprise en fonction d'un vocabulaire standard. Grâce au vocabulaire standard centré sur les besoins de l'entreprise, il s'assure que les règles commerciales elles-mêmes sont bien comprises par les principales parties prenantes, telles que les analystes commerciaux. Par exemple, dans votre entreprise, il se peut que vous ayez un fait qui représente un client et un fait qui représente une commande.

Le client peut avoir des champs tels que le nom, l'âge, l'emplacement, la solvabilité et la langue de préférence. La commande peut avoir des champs tels que le montant de la commande et la date de la commande. Une règle peut être construite à l'aide de ces valeurs, telles que :

Lorsque le client a au moins 21 ans et que sa commande est supérieure à 100,00, inviter le client à participer au sondage.

Voir Éditeur Modèle de fait

Événements

Pour prendre en charge le traitement des événements complexes, les développeurs de modèles doivent être habilités à désigner certains faits comme des événements, et les créateurs de règles doivent modifier la façon dont DRL est généré lorsqu'un fait est désigné comme un événement.

Ainsi, le modèle de fait inclut des événements et la boîte de dialogue Modèle de fait inclut désormais un bouton Créer un événement. Un événement comprend les champs suivants :

  • Nom
  • Description
  • Une liste facultative de propriétés.
  • Métadonnées d'expiration définies par l'utilisateur pour l'événement

Dans GRAT, la balise de métadonnées @role détermine si nous traitons un fait ou un événement. La balise de métadonnées @role accepte deux valeurs possibles :

  • fact — Lors de l'attribution du rôle de fait, le type doit être traité comme un fait régulier. Le fait est le rôle par défaut.
  • event — L'attribution du rôle d'événement déclare que le type doit être traité comme un événement.

Fonctions

Les fonctions permettent de définir des éléments autres que des conditions et des actions, par exemple, lorsque l'analyse des horodatages est requise. L'éditeur Fonctions vous permet d'écrire des fonctions Java spécifiques à différentes fins dans les modèles de règles. Les fonctions spécifiées peuvent ensuite être utilisées dans les mappages de langage des règles (voir Mappage du langage des règles).

Lors de la création des modèles de règles, le développeur de règle les publie dans le référentiel de règles pour les rendre disponibles dans GRAT pour les utilisateurs de l'entreprise afin de créer des règles.

Les actions et conditions peuvent contenir des paramètres. Différents types de paramètres sont pris en charge.

Certains types de paramètres dynamiques qui font référence à des sources de données externes requièrent la sélection d'un profil. Le profil est défini comme un objet Script de type Collection de données et fournit des informations de connexion qui permettent à GRAT de récupérer ces données dynamiques à partir de la source de données externe. Les sections suivantes décrivent la configuration des profils pour des paramètres de base de données, de service Web et de Workforce Management.

Voir Éditeur Fonctions.

Paramètres

Les paramètres de base de données, service Web et Workforce Management sont utilisés dans les actions et conditions.

Paramètres de base de données

Propriétés du paramètre de base de données

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.

Vous ne pouvez configurer des paramètres de base de données qu'avec une instruction SQL SELECT. Tout autre type d'instruction échoue lors de la configuration.

Paramètres de service Web

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és du paramètre de 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]
Avertissement : Vous ne pouvez pas spécifier d'en-tête ou de paramètres contenant « , » dans la valeur.

Avertissement : 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.

Vous devez définir complètement le message à envoyer et il doit être constant. Aucune substitution de variable n'est effectuée. La requête XPath est utilisée pour extraire les valeurs de la réponse du serveur. La réponse doit être au format XML ou JSON, sinon cela ne fonctionnera pas. Vous devez spécifier une requête XPath valide pour la réponse. Cela dépend entièrement du service avec lequel vous interagissez.

Remarque : Le message est envoyé au serveur seulement une fois par session. Cette opération est effectuée à la fois pour des raisons de performances et parce que les valeurs dans la réponse sont censées être relativement constantes.

Le chemin du paramètre est ajouté à base_path dans le script.

Par exemple :

Si le script contient :

host = api.wunderground.com 
base_path = /auto/wui/geo/ForecastXML/

et si Développement de modèle 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

Paramètres de Workforce Management

Dans Configuration Server, les scripts Workforce Management doivent comporter une section appelée wfm. Le tableau 4 répertorie les propriétés que vous pouvez spécifier pour les paramètres de Workforce Management.

Propriétés du paramètre 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 », 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 va chercher la liste actuelle des activités WFM depuis WFM Server et les affiche pour le créateur de la règle.

Prise en charge des types de modèles définis par l'utilisateur

GRAT affiche automatiquement la liste des types de modèles qui y sont publiés et les concepteurs de modèles peuvent les sélectionner ou en définir de nouveaux, selon leurs besoins.

Versions du modèle

Chaque fois qu'un modèle de règle est publié, une nouvelle version est créée dans le référentiel. Le créateur de la règle peut sélectionner une version du modèle dans la boîte de dialogue Sélection de modèle lors de la création d'un ensemble de règles. Cette boîte de dialogue affiche les N dernières versions d'un modèle, où N correspond à une valeur configurée en utilisant l'option de configuration display-n-template-versions dans Genesys Administrator.

Lorsque vous publiez des versions plus récentes du modèle de règle, sachez que certaines modifications peuvent affecter des règles qui ont déjà été créées à l'aide de la version antérieure du modèle. Veillez à ne pas apporter de modifications qui pourraient annuler des règles existantes, sauf si ces modifications sont communiquées au créateur de la règle.

Par exemple, si le modèle de règle version 1 contient une condition qui sera supprimée ultérieurement dans la version 2, si une règle a déjà été élaborée à l'aide de cette condition, elle ne se compilera plus si l'auteur du règlement effectue la mise à niveau vers le modèle de règle version 2.

Par exemple, si la configuration avait été définie pour afficher les 3 dernières versions d'un modèle, que le modèle actuellement sélectionné est le Modèle GRS version 2, et qu'il existe 5 versions dans le référentiel, nous afficherions le modèle GRS versions 5, 4 et 3, ainsi que le modèle GRS version 2. Les utilisateurs pourraient choisir entre les versions 3, 4 ou 5.

Commentaire sur la version

Afin de fournir des détails sur les différences entre les versions de modèle, les développeurs du modèle de règles peuvent publier un commentaire sur la version qui décrit les modifications spécifiques apportées aux différentes versions de modèle. Ce commentaire de version apparaît dans GRAT dans le tableau de sélection des modèles et peut être modifié par le créateur de la règle dans GRAT.

This page was last edited on November 22, 2019, at 09:33.
Comments or questions about this documentation? Contact us for support!