Bonjour !
Dans les leçons précédentes, nous avons exploré la logique de flux avancée dans Architect. Vous avez appris à créer des branchements avec les actions Decision et Switch, à gérer des listes de données avec les collections, et à traiter ces listes de manière efficace en utilisant des boucles (Loop). Ces outils vous permettent déjà de construire des flux complexes et dynamiques.
Cependant, en construisant plusieurs flux, vous remarquerez vite que certaines logiques se répètent. Par exemple, une séquence d'actions pour vérifier les horaires d'ouverture, un processus pour saluer un client par son nom, ou une procédure standard de fin d'appel. Copier-coller cette logique dans chaque flux est non seulement fastidieux, mais aussi dangereux : si vous devez la modifier, vous devrez la retrouver et la corriger partout, avec un risque d'oubli et d'incohérence.
C'est pour résoudre ce problème qu'existent les Tâches Communes, ou Common Modules dans Architect.
À la fin de cette leçon, la dernière de ce module, vous saurez comment encapsuler une logique réutilisable dans un module commun, et comment l'appeler depuis n'importe quel autre flux, rendant ainsi vos développements plus rapides, plus propres et plus faciles à maintenir.
1. Qu'est-ce qu'un Module Commun ?
Un module commun est un type de flux spécial dans Architect. Il n'est pas conçu pour être exécuté directement (on ne peut pas lui assigner un numéro de téléphone, par exemple), mais pour être "appelé" par d'autres flux. Pensez-y comme une "sous-routine" ou une "fonction" que vous pouvez construire une seule fois et réutiliser à l'infini.
Les principaux avantages sont :
- Réutilisabilité : Écrivez une logique complexe une fois, utilisez-la partout.
- Maintenance simplifiée : Mettez à jour la logique à un seul endroit, et les changements peuvent être propagés à tous les flux qui l'utilisent.
- Consistance : Assurez-vous qu'une procédure standard est exécutée de la même manière dans tous vos parcours clients.
- Omnicanal : Un même module peut parfois être utilisé par des flux de différents canaux (voix, email, chat), à condition que la logique soit compatible.
Pour bien comprendre les principes de base, la documentation de Genesys Cloud offre une excellente introduction.
Work with common module flows View summary
Cette page, intitulée 'Work with common module flows', explique l'objectif des modules communs et leurs caractéristiques principales. Elle vous donnera un aperçu complet de leur rôle et de leurs capacités.
Lisez la première partie de la page, jusqu'à la section 'Common module versioning'. Concentrez-vous sur la définition des modules communs, leur but, et la note importante sur la compatibilité des actions entre les différents types de flux.
2. Créer un Module Commun
Passons à la pratique. La création d'un module commun est très similaire à celle d'un autre type de flux, avec une étape clé supplémentaire.
La documentation suivante décrit la procédure exacte.
Create a flow View summary - Genesys Cloud Resource Center
Cet article du centre de ressources Genesys Cloud, 'Create a flow', détaille pas à pas comment créer un flux. Nous nous intéresserons spécifiquement à la création d'un module commun.
Suivez les étapes décrites dans la section. Portez une attention particulière à l'étape 6, 'Compatible Flow Types'. C'est ici que vous définissez depuis quels types de flux (appel entrant, chat, email...) votre module pourra être appelé. Ce choix est crucial car il détermine les actions qui seront disponibles dans l'éditeur.
En résumé, pour créer votre module :
- Allez dans Architect > Flows > Common Module.
- Cliquez sur Add.
- Donnez-lui un nom clair et une description.
- À l'étape Compatible Flow Types, sélectionnez les types de flux qui utiliseront ce module (par exemple, "Inbound Call").
- Cliquez sur Create Flow.
L'éditeur de flux s'ouvre, prêt à être configuré.
3. Définir les Entrées et les Sorties (Inputs & Outputs)
Un module réutilisable ne serait pas très utile s'il ne pouvait pas recevoir d'informations du flux qui l'appelle, ni lui renvoyer un résultat. C'est le rôle des variables d'entrée et de sortie.
La configuration se fait au niveau des variables du flux, à l'aide de deux cases à cocher :
- Input to flow : La valeur de cette variable sera fournie par le flux appelant.
- Output from flow : La valeur de cette variable sera retournée au flux appelant à la fin de l'exécution du module.
L'image ci-dessous montre exactement où se trouvent ces options lors de la création ou de la modification d'une variable.

Exemple simple :
Imaginons un module qui ajoute 10 à un nombre.
- Créez une variable de type Entier (
Integer) nomméeFlow.InputNumberet cochez Input to flow. - Créez une autre variable Entier nommée
Flow.ResultNumberet cochez Output from flow. - Dans le flux du module, ajoutez une action
Update Dataqui assigne àFlow.ResultNumberla valeur de l'expressionFlow.InputNumber + 10.
Votre module est maintenant prêt à recevoir un nombre et à en retourner un autre.
4. Appeler un Module Commun
Une fois votre module commun créé et publié, vous pouvez l'utiliser dans un autre flux (de type compatible) grâce à l'action Call Common Module.
Cette action se trouve dans la boîte à outils sous la catégorie Logic. Lorsque vous l'ajoutez à votre flux :
- Dans son panneau de configuration, sélectionnez le module commun que vous souhaitez appeler dans la liste déroulante.
- Les sections Inputs et Outputs apparaissent automatiquement, listant les variables que vous avez marquées comme entrée ou sortie dans le module.
- Pour chaque Input, vous pouvez soit entrer une valeur littérale, soit la lier à une variable de votre flux appelant.
- Pour chaque Output, vous devez spécifier une variable de votre flux appelant qui recevra la valeur de retour.
L'image ci-dessous montre un exemple de logique modulaire, où une tâche réutilisable est appelée pour gérer les erreurs. Le principe est le même : un bloc de logique est appelé pour effectuer une tâche spécifique.

5. Mise en pratique : Un module pour le message de fin d'appel
Créons ensemble un module commun pour standardiser le message de fin d'appel et le décompte de l'appelant.
Partie 1 : Créer le Module Commun CM_StandardClosing
- Créez un nouveau Common Module.
- Name :
CM_StandardClosing - Compatible Flow Types : Cochez
Inbound Call.
- Name :
- Dans l'éditeur du module, créez une variable d'entrée.
- Name :
Flow.CompanyName - Data Type :
String - Cochez la case Input to flow.
- Name :
- Ajoutez une action
Play Audiodans la tâche de départ.- Sélectionnez
To-Speechet utilisez le modeExpression. - Entrez l'expression :
Append("Merci d'avoir contacté ", Flow.CompanyName, ". Bonne journée.")
- Sélectionnez
- Après l'action
Play Audio, ajoutez une actionDisconnectdepuis la catégorieVoice. - Publiez votre module commun. Il est maintenant prêt à être utilisé.
Partie 2 : Appeler le module depuis un flux d'appel
- Créez un nouveau flux Inbound Call.
- Name :
Test_Appel_CM
- Name :
- Dans la tâche de départ, ajoutez une action
Play Audioavec un simple message d'accueil, par exemple "Bienvenue". - Après ce message, faites glisser l'action
Call Common Moduledepuis la catégorieLogic. - Configurez l'action :
- Common Module to run : Sélectionnez
CM_StandardClosing. - Dans la section Inputs, vous verrez le paramètre
CompanyName. Entrez la valeur littérale (entre guillemets)"Mon Entreprise Inc.".
- Common Module to run : Sélectionnez
- Il n'y a pas de sortie à configurer, car le module termine l'appel lui-même.
- Publiez votre flux d'appel.
- Pour tester, assignez un numéro de téléphone à ce flux et appelez-le. Vous devriez entendre "Bienvenue", suivi de "Merci d'avoir contacté Mon Entreprise Inc. Bonne journée.", puis l'appel se terminera.
6. Versioning et Maintenance
Un point crucial à comprendre est la gestion des versions.
Lorsque vous publiez un flux qui appelle un module commun, Architect "fige" la version du module utilisé à ce moment-là.
Work with common module flows View summary
Revenons à notre première ressource, 'Work with common module flows'. Cette fois, nous allons nous concentrer sur la partie concernant le versioning.
Lisez la section intitulée 'Common module versioning'. Elle explique que pour qu'un flux appelant utilise une nouvelle version d'un module commun, le flux appelant doit être lui-même republié.
Cela signifie que si vous modifiez et republiez votre module CM_StandardClosing, les flux qui l'utilisent déjà ne seront pas affectés et continueront d'utiliser l'ancienne version. Pour qu'ils prennent en compte la mise à jour, vous devez ouvrir chaque flux appelant et le republier.
Cette approche garantit qu'une modification sur un module commun ne casse pas de manière inattendue un flux en production. Elle vous donne le contrôle sur le moment où la mise à jour est appliquée.
Conclusion
Félicitations ! Vous avez terminé le module sur la logique de flux avancée en maîtrisant l'un des concepts les plus importants pour un développement propre et à grande échelle : la réutilisation de la logique.
Points clés à retenir :
- Les Modules Communs (Common Modules) sont des flux réutilisables conçus pour être appelés par d'autres flux.
- Ils communiquent avec le flux appelant via des variables d'entrée (Input) et de sortie (Output).
- L'action
Call Common Modulepermet d'exécuter un module depuis un autre flux en mappant les variables. - La mise à jour d'un module commun nécessite la republication des flux appelants pour que les changements soient pris en compte.
L'utilisation de modules communs est une compétence essentielle qui distingue un administrateur débutant d'un architecte de solutions expérimenté.
Prochaine leçon :
Nous avons maintenant une solide maîtrise de la logique interne d'Architect. La prochaine étape est d'ouvrir nos flux au monde extérieur. Dans le prochain module, nous allons aborder un sujet fondamental pour créer des expériences client riches et personnalisées : l'intégration de données externes via les API REST et les Data Actions. Vous apprendrez comment votre flux d'appel peut interroger un CRM, une base de données ou un service web pour, par exemple, récupérer les informations d'un client en temps réel. C'est l'équivalent dans Genesys Cloud des mécanismes de recherche de données externes (data dips) que vous connaissiez dans l'environnement Cisco UCCE, mais basé sur des standards web modernes.