Bonjour !
Dans la leçon précédente, vous avez appris à dynamiser vos flux d'appels en utilisant des variables et des expressions. Vous savez maintenant comment centraliser des configurations et comment créer une logique de routage simple basée sur des conditions.
Maintenant que nous pouvons créer des flux de plus en plus sophistiqués, une question essentielle se pose : comment les gérer de manière professionnelle ? Comment déployer une modification sans risquer d'interrompre le service ? Comment revenir en arrière si une erreur est introduite ?
L'objectif de cette leçon est de vous apprendre à publier, versionner et gérer le cycle de vie d'un flux Architect. C'est une compétence administrative cruciale qui garantit la stabilité, la traçabilité et la collaboration lors de la gestion de vos logiques de routage. Pour quelqu'un avec votre expérience sur Cisco UCCE, vous pouvez voir cela comme l'équivalent des processus de sauvegarde, d'activation et de gestion des versions de scripts, mais avec le vocabulaire et les outils propres à Genesys Cloud.
À la fin de cette leçon, vous saurez comment faire évoluer vos flux en toute sécurité, de l'édition à la mise en production.
Le Cycle de Vie d'un Flux : de l'Ébauche à la Production
Chaque flux dans Architect passe par différents états. Comprendre ce cycle est la clé pour le gérer efficacement.
Voici les trois états principaux :
- En cours d'édition (Checked Out) : C'est l'état de travail. Quand vous modifiez un flux, il vous est "réservé" (
checked out). Personne d'autre ne peut le modifier en même temps, ce qui évite les conflits. - Versionné (Checked In) : Une fois vos modifications terminées et enregistrées, vous "archivez" le flux (
check in). Cela crée une nouvelle version immuable dans l'historique et le rend disponible pour que d'autres administrateurs puissent le modifier (ce qui créera une autre version). - Publié (Published) : C'est la version "active" du flux, celle qui traite réellement les interactions. À un instant T, il ne peut y avoir qu'une seule version publiée pour un flux donné.
Maintenant, voyons en détail les actions qui vous permettent de passer d'un état à l'autre.
1. Sauvegarder et Archiver : Save vs. Check in
Lorsque vous travaillez sur un flux, vous avez deux manières principales d'enregistrer votre progression. Elles semblent similaires, mais leur usage est très différent.
-
Save (Enregistrer) : Cette action enregistre vos modifications actuelles mais garde le flux en état "checked out". C'est l'équivalent d'un "Ctrl+S" dans un document Word. Utilisez cette fonction pour sauvegarder votre travail fréquemment pendant que vous développez, sans pour autant finaliser votre version.
-
Check in (Archiver) : Cette action est plus formelle. Elle enregistre vos modifications et change le statut du flux pour qu'il ne soit plus "checked out". Cela crée une nouvelle version numérotée dans l'historique du flux et le "libère", permettant à un autre utilisateur (ou à vous-même plus tard) de le modifier à nouveau.
Il est aussi possible d'annuler vos modifications. L'option Discard Unsaved Changes recharge la dernière version enregistrée du flux, abandonnant tout le travail effectué depuis le dernier Save ou Check in.
La documentation de Genesys Cloud décrit précisément ces actions de base. Prenez un moment pour lire ces définitions afin de bien ancrer la différence entre enregistrer une ébauche et archiver une version finalisée.
Veuillez lire les sections intitulées 'Save', 'Check in', et 'Discard Unsaved Changes'. Concentrez-vous sur la distinction clé : 'Save' vous laisse en mode édition, tandis que 'Check in' finalise et versionne votre travail.
2. Valider et Publier : Mettre en Production
Un flux versionné n'est pas encore actif. Pour qu'il puisse prendre des appels, il doit être publié. Mais avant cela, il doit être validé.
-
Validate (Valider) : C'est un outil de contrôle automatique de Genesys Cloud. Avant de publier, vous devez toujours cliquer sur
Validate. Architect parcourt alors l'ensemble de votre flux à la recherche d'erreurs logiques ou de configurations manquantes. Par exemple :- Une action
Transfer to ACDsans file d'attente spécifiée. - Un menu SVI qui ne mène nulle part après une saisie.
- Une variable utilisée dans une expression sans avoir été initialisée.
Si des erreurs sont trouvées, Architect les listera et vous ne pourrez pas publier tant qu'elles ne sont pas corrigées. C'est votre filet de sécurité.
- Une action
-
Publish (Publier) : Une fois le flux validé avec succès, le bouton
Publishdevient disponible. Cliquer dessus rend la version actuelle du flux active. C'est cette version que le système exécutera lorsqu'un appel arrivera sur le numéro de téléphone associé. Toute version précédemment publiée est automatiquement désactivée et remplacée par la nouvelle.
Ce processus en deux étapes (validation puis publication) est fondamental pour un déploiement maîtrisé.
Get started with Architect tutorial
Ce court extrait d'un tutoriel de Genesys Cloud résume parfaitement l'objectif de ces deux étapes.
Lisez simplement la description de la "Leçon 8". Elle met en évidence que le but est de vérifier les erreurs ('validate') puis de publier ('publish') pour que le flux soit actif.
3. La Gestion des Versions : L'Art de Revenir en Arrière
Chaque fois que vous effectuez un Check in, Architect crée une nouvelle version de votre flux (par ex., 1.0, 2.0, 3.0...). Cela crée un historique complet de toutes les modifications. Cette fonctionnalité est essentielle pour deux raisons : la traçabilité et la restauration.
Imaginez que vous publiez une nouvelle version d'un flux, mais qu'elle contient une erreur de logique qui n'a pas été détectée par la validation automatique. Le service est impacté. Que faire ?
Grâce au versioning, la solution est simple : restaurer et republier une version précédente.
Architect vous permet de naviguer dans l'historique des versions d'un flux. Vous pouvez ouvrir une ancienne version (en lecture seule pour l'inspecter), et si vous déterminez qu'il s'agit de la dernière version stable, vous pouvez la publier à nouveau directement. Cela désactivera immédiatement la version défectueuse et réactivera l'ancienne version stable, restaurant ainsi le service rapidement.
Cette section de la documentation explique comment utiliser les fonctionnalités de restauration. C'est une compétence essentielle pour la résolution d'incidents.
Lisez la section 'Revert to Version'. Elle décrit les deux scénarios : annuler des changements en cours et republier une version antérieure.
4. Import / Export : Rendre Vos Flux Portables
Pour finir, la gestion du cycle de vie inclut aussi la capacité de déplacer des flux entre différents environnements. Un cas d'usage très courant est de développer et tester un flux dans une organisation "sandbox" (bac à sable) de Genesys Cloud, puis de le déployer dans l'organisation de production.
- Export : Vous pouvez exporter la configuration complète d'un flux dans un fichier (au format
.yaml). - Import : Vous pouvez ensuite importer ce fichier dans un autre flux (soit un nouveau flux, soit un flux existant).
Attention : Comme l'indique la documentation, l'importation d'un flux écrase complètement la configuration du flux de destination. Il n'y a pas de fusion. C'est une opération de remplacement.
Pour conclure, familiarisez-vous avec les concepts d'import et d'export. C'est une fonctionnalité avancée mais très utile pour la standardisation et le déploiement entre plusieurs organisations.
Lisez la section 'Import and Export'. Retenez surtout l'idée générale de portabilité et l'avertissement concernant l'écrasement des données lors de l'import.
Conclusion
Vous avez maintenant les compétences pour gérer vos flux Architect de manière structurée et sécurisée. C'est une étape indispensable pour passer de la simple création de flux à une administration professionnelle de centre de contact.
Points clés à retenir :
Saveest pour les sauvegardes intermédiaires,Check infinalise et crée une nouvelle version.- Un flux doit être validé (sans erreur) avant de pouvoir être publié.
- La publication rend une version spécifique du flux active et remplace la précédente.
- L'historique des versions vous permet de tracer les modifications et, surtout, de restaurer rapidement une version stable en cas de problème.
- L'import/export permet de déplacer des flux entre organisations, par exemple d'un environnement de test à un environnement de production.
Prochaine leçon :
Maintenant que nous maîtrisons le cycle de vie de nos flux, nous sommes prêts à construire des logiques plus riches. Dans la prochaine leçon, nous entrerons dans le vif du sujet des Serveurs Vocaux Interactifs (SVI). Vous apprendrez à configurer des plannings horaires pour gérer les heures d'ouverture et à construire un menu SVI multi-niveaux pour guider vos appelants.