- Introduction
- Démarrage
- Créer avec Maestro BPMN
- Compréhension de la modélisation BPMN de Maestro
- Ouverture du canevas de modélisation
- Modéliser votre processus
- Alignement et connexion des éléments BPMN
- Autopilot pour Maestro (aperçu)
- Référentiel de processus
- Implémenter un processus BPMN simple
- Implémenter un processus BPMN complexe
- Débogage
- Simulation
- Évaluations (Aperçu)
- Scénarios de mise en œuvre courants
- Building with Maestro Case
- Présentation de Maestro Case
- Maestro BPMN vs. Maestro Case : quand utiliser la gestion des incidents
- Le cycle de vie de Maestro Case : du déclencheur d'événement à l'expérience de l'application
- Créer votre premier incident avec Maestro Case
- Créer un Maestro Case avec un agent de codage (aperçu)
- Définition des clés de cas (système vs. externe)
- Établissement des contrats d'E/S et de réécriture de la tâche
- Règles de sortie et fin de l’étape précoce
- Modélisation des étapes primaires et secondaires
- Déclencher un cas à partir de Data Fabric
- Implémentation des personas et des autorisations au niveau de l'étape
- Définition des SLA et des règles d'escalade automatisées
- Configuration d'une boucle de retraitement (renouvellement)
- Configurer et tester l'agent Case Manager (aperçu)
- Contrat d’entrée et de sortie du gestionnaire de cas
- Dictionnaire des composants de Maestro Case
- Créer avec Maestro Flow
- Maestro Automate
- Intégrations
- Opérations
- Surveillance
- Optimisation
- Informations de référence
L'historique d'exécution et les traces par exécution pour les workflows Flow déployés, affichant ce qui a déclenché chaque exécution, le chemin qu'elle a emprunté, ainsi que la sortie et la durée par nœud.
Une fois qu'un Flow est déployé et exécuté, l'historique d'exécution vous donne une vue complète de chaque exécution - ce qui l'a déclenchée, quel chemin elle a pris, ce que chaque nœud a produit et combien de temps chaque étape a pris.
Sujets associés à la gestion des instances Maestro
- Affichage du diagramme des instances — Icônes de statut par étape de processus
- Limitation des instances — limitation automatique d'une instance de workflow sous volume d'activité élevé
- ID d’instance personnalisé — un ID d'instance généré par le runtime à la place de celui généré par le système
Historique d’exécution
L'historique d'exécution répertorie chaque exécution du workflow, avec les informations suivantes pour chacune :
| Champ | Description |
|---|---|
| État (Status) | Succeeded, Failed ou Running |
| Déclencheur | Ce qui a démarré l'exécution (manuel, planifié ou événement d'intégration). |
| Commencé à | Horodatage du moment où l'exécution a commencé. |
| Duration | Temps total entre le début et la fin. |
| Version | Quelle version publiée du workflow s'est exécutée. |
La sélection d'une ligne ouvre la trace d'exécution de cette exécution.
Traçage de l’exécution
La trace d'exécution est un enregistrement étape par étape de ce qui s'est passé pendant une exécution spécifique. Pour chaque nœud, il affiche :
- Valeurs d'entrée - ce que le nœud a reçu.
- Valeurs de sortie - ce que le nœud a produit.
- Statut - si le nœud a réussi ou échoué.
- Durée - temps nécessaire à l'exécution du nœud.
- Détails de l'erreur - si le nœud a échoué, le message d'erreur, le type et la trace de la pile.
La trace met en surbrillance le chemin réellement emprunté par le workflow (par exemple, la ramification d'un nœud de décision), ce qui permet de comprendre facilement l'exécution complète sans lire la définition du workflow.
Filtrer et rechercher des exécutions
Vous pouvez filtrer l'historique d'exécution par :
- Statut (réussi, échoué, en cours d'exécution)
- Type de déclencheur
- Plage de dates
- Numéro de version
Les filtres aident à affiner les exécutions échouées après un déploiement ou à comparer le comportement entre deux versions.
Surveillance des échecs
Les notifications d'échec peuvent provenir des paramètres du workflow ou du workflow lui-même :
- La configuration des alertes dans les paramètres du workflow envoie une notification à un e-mail ou un canal Slack spécifié lorsqu'une exécution atteint le statut
Failed. - Une étape de notification sur le chemin d'erreur d'un nœud fournit plus de contrôle sur le contenu de l'alerte.
Erreurs courantes
- Ne vérifier que les exécutions ayant échoué - Les exécutions lentes et réussies peuvent indiquer des problèmes de performances. Les tendances en matière de durée comptent même lorsque l'exécution réussit.
- Ignorer les numéros de version dans les traces - Le numéro de version identifie la version du workflow qui a produit la trace. Une restauration n'explique pas ce qui s'est mal passé si l'exécution échouée a utilisé une version plus ancienne.