Automation
Azure Logic Apps : diagnostiquer un workflow avant de relancer l’exécution
Un runbook de production pour qualifier une exécution Azure Logic Apps en échec avec déclencheur, connecteurs, identité managée, payload, logs, validation et rollback avant de relancer.
Une exécution Azure Logic Apps en échec pousse souvent à cliquer trop vite sur Resubmit. Le workflow peut avoir reçu deux fois le même événement, un connecteur peut être expiré, une identité managée peut avoir perdu un droit, une action HTTP peut avoir retourné un 429, une dépendance privée peut ne plus résoudre en DNS, ou une condition peut avoir déjà déclenché un effet partiel. Relancer sans qualifier l’état peut créer un doublon : ticket, commande, rotation de secret, message envoyé, écriture dans une base ou appel d’API interne.
Le cas d’usage est un workflow d’intégration utilisé en production pour traiter un événement métier ou technique : alerte Azure Monitor, webhook, message Service Bus, fichier déposé, appel HTTP interne ou orchestration d’automatisation. L’objectif du runbook est de décider si l’exécution peut être relancée, rejouée avec un payload corrigé, reprise manuellement, compensée ou bloquée jusqu’à correction du contrat.
Geler le contrat d’exécution
Commence par décrire ce que cette exécution devait faire. Une Logic App n’est pas seulement un diagramme d’actions : c’est une interface de production avec un déclencheur, un payload, des connecteurs, des identités, des effets et une règle d’idempotence.
Execution a qualifier
Logic App: la-prod-incident-routing
Workflow: route-critical-alert
Run ID: 08585200000000000000000000000CU00
Trigger: Azure Monitor alert webhook, Service Bus, HTTP, schedule ou Event Grid
Payload attendu: identifiant d'evenement, cible, severite, correlationId
Effet attendu: creer ou enrichir un ticket, notifier, appeler une API interne
Derniere action certaine avant echec
Effet partiel deja observe
Validation attendue apres execution
Rollback ou compensation connue
Questions avant relance
Le workflow est-il idempotent pour ce payload ?
Le trigger peut-il renvoyer le meme evenement ?
Une action externe a-t-elle deja reussi ?
Le connecteur ou l'identite est-il le bon ?
La dependance appelee est-elle publique, privee ou hybride ?Si l’équipe ne sait pas dire quel effet a déjà eu lieu, la relance est une nouvelle action de production, pas une simple correction technique.
Lire l’état réel du run
La vue graphique donne un signal utile, mais elle ne suffit pas. Il faut capturer le statut du run, le déclencheur, les entrées et sorties des actions critiques, les retries et l’horodatage exact.
RG="rg-integration-prod"
LOGIC_APP="la-prod-incident-routing"
RUN_ID="08585200000000000000000000000CU00"
az logic workflow run show --resource-group "$RG" --name "$LOGIC_APP" --run-name "$RUN_ID" --output json
az logic workflow run action list --resource-group "$RG" --workflow-name "$LOGIC_APP" --run-name "$RUN_ID" --query "[].{name:name,status:status,start:startTime,end:endTime,code:code,error:error.message}" --output tableConserve les entrées sensibles hors des notes partagées, mais garde la preuve technique : action échouée, code retour, durée, tentative, correlationId et action précédente réussie. La relance doit être comparable au run initial.
Séparer déclencheur, payload et état partiel
Beaucoup d’incidents Logic Apps viennent d’un événement ambigu plutôt que du workflow lui-même. Un webhook incomplet, un message Service Bus déjà consommé, un fichier renommé pendant l’exécution ou une alerte Azure Monitor sans dimension attendue peuvent casser une branche du workflow.
Verifier le trigger
Type de trigger et heure exacte
Payload recu par le workflow
Identifiant fonctionnel: eventId, ticketId, orderId, secretName, resourceId
CorrelationId transmis aux appels suivants
Frequence, recurrence ou retry du trigger
Etat du message source: actif, complete, dead-letter, abandonne
Deduplication ou verrou deja applique
Bloquer la relance quand
L'identifiant fonctionnel est absent
Le meme evenement a deja produit un effet externe
Le payload cible un perimetre trop large
Le trigger peut rejouer plusieurs messages a la fois
L'action precedente a reussi mais la validation est inconnueLa bonne réponse peut être une compensation, pas une relance. Par exemple, ne recrée pas un ticket si le ticket existe déjà ; enrichis-le ou rattache le run à l’identifiant existant.
Vérifier connecteurs et identité managée
Une Logic App peut agir avec un connecteur managé, une connexion API, une identité système, une identité utilisateur ou un secret. Le diagnostic doit prouver quelle identité a réellement appelé la dépendance.
RG="rg-integration-prod"
LOGIC_APP="la-prod-incident-routing"
az logic workflow show --resource-group "$RG" --name "$LOGIC_APP" --query "{state:state,identity:identity,accessEndpoint:accessEndpoint,changedTime:changedTime}" --output json
az resource list --resource-group "$RG" --resource-type "Microsoft.Web/connections" --query "[].{name:name,kind:kind,changedTime:changedTime,statuses:properties.statuses}" --output json
PRINCIPAL_ID="00000000-0000-0000-0000-000000000000"
az role assignment list --assignee "$PRINCIPAL_ID" --all --query "[].{role:roleDefinitionName,scope:scope}" --output tableUn 401 ou un 403 ne justifie pas immédiatement d’élargir le rôle. Vérifie d’abord le connecteur utilisé, l’identité attendue, le tenant, le scope Azure et les changements récents sur la connexion.
Qualifier les dépendances réseau et privées
Si le workflow appelle une API interne, Key Vault, Storage, Service Bus ou un endpoint privé, l’échec peut venir du chemin réseau. Private Endpoint peut être dans le parcours, mais il n’est qu’une pièce du diagnostic : DNS, routage, firewall, identité et logs applicatifs doivent rester séparés.
Verifier les dependances
FQDN appele par l'action HTTP ou le connecteur
Resolution DNS attendue depuis le chemin d'execution
Private Endpoint ou VNet Integration si applicable
Regles firewall, NSG, UDR ou proxy intermediaire
Identite presentee a la dependance
Logs cote API, Key Vault, Storage, Service Bus ou APIM
Relance interdite quand
La destination resolue n'est pas celle attendue
Le workflow atteint un endpoint public par accident
Le firewall ne voit qu'une partie de la conversation
L'API interne a deja applique l'action mais la Logic App a timeout
Les logs de dependance ne permettent pas de trancherPour une Logic App Standard intégrée à un réseau virtuel, valide aussi la configuration d’intégration VNet et les routes de sortie. Pour une Logic App Consumption, vérifie surtout le type de connecteur, la configuration de la dépendance et les restrictions d’accès côté service appelé.
Corréler les effets avec les logs
Le point critique est de savoir si le workflow a seulement échoué ou s’il a échoué après avoir produit un effet. Les logs doivent relier le run Logic Apps aux systèmes touchés.
let StartTime = datetime(2026-07-13T06:00:00Z);
let EndTime = datetime(2026-07-13T06:30:00Z);
let WorkflowRunId = "08585200000000000000000000000CU00";
AzureDiagnostics
| where TimeGenerated between (StartTime .. EndTime)
| where ResourceProvider has "MICROSOFT.LOGIC"
| where tostring(runId_s) == WorkflowRunId or tostring(correlationId_g) has WorkflowRunId
| project TimeGenerated, Resource, Category, status_s, actionName_s, code_s, error_message_s, trackingId_g
| order by TimeGenerated ascAjoute ensuite les logs de la dépendance : APIM, Function, Key Vault, Storage, Service Bus, application interne ou outil ITSM. Si l’API cible a répondu 200 mais que la Logic App a échoué sur l’action suivante, la relance doit être bornée.
Décider relance, reprise ou compensation
La décision doit être explicite. Une relance complète n’est sûre que si le workflow sait reconnaître un effet déjà appliqué ou si aucune action externe n’a réussi.
Relancer le run tel quel
Le workflow est idempotent pour cet identifiant fonctionnel
Aucune action externe irreversible n'a reussi
Le connecteur, l'identite et la dependance sont revenus a l'etat nominal
Le payload est complet et borne
La validation post-run est definie
Relancer avec payload corrige
Le trigger initial etait incomplet
La cible exacte est prouvee
Le workflow ne rejouera pas une action deja terminee
Le run est rattache a un incident ou une demande identifiee
Reprendre manuellement
Une action intermediaire a reussi
Le workflow n'a pas de checkpoint fiable
La prochaine etape depend de l'etat observe
Une validation humaine est necessaire
Compenser ou rollback
Un ticket, message, secret, fichier ou appel API a deja ete cree
La relance produirait un doublon
L'identite ou le connecteur etait mauvais
Les logs ne prouvent pas l'etat applique
Le contrat d'idempotence est absentLa question centrale est simple : si le même payload repasse maintenant, le système reconnaît-il qu’il l’a déjà traité ? Si la réponse est non, il faut une reprise contrôlée ou une compensation.
Automatiser le pack de diagnostic
Un bon mode opératoire ne donne pas seulement accès au bouton de relance. Il produit un pack de décision que l’équipe peut lire rapidement pendant l’incident.
diagnostic_pack:
collect:
- workflow_run_state
- trigger_payload_and_functional_id
- failed_action_inputs_outputs
- connector_and_connection_status
- managed_identity_and_role_scope
- dependency_logs
- retry_history
- partial_effects
- validation_signal
decide:
- resubmit_same_run
- resubmit_with_corrected_payload
- resume_manually
- compensate_or_rollback
- block_until_contract_fix
required_evidence:
- run_id
- correlation_id
- target_resource_or_business_id
- last_successful_action
- owner_of_next_action
- rollback_or_compensation_pathCe pack peut être stocké dans l’incident, attaché au ticket de changement ou généré par une petite automatisation de collecte. L’important est de rendre la décision relisible après coup.
Valider et nettoyer après action
Après relance, reprise ou compensation, la validation doit porter sur le système cible, pas seulement sur le statut vert de la Logic App.
Validation apres decision
Le run cible est termine ou explicitement abandonne
Aucun doublon fonctionnel n'a ete cree
La dependance cible confirme l'etat attendu
Les messages source sont dans l'etat attendu
Les retries temporaires sont retires
Les connecteurs ou roles modifies sont revenus au scope approuve
Les logs contiennent runId, correlationId et decision
Le workflow ou le contrat est corrige si l'idempotence manquait
Rollback incomplet quand
Seul le statut Logic Apps est controle
Un message dead-letter reste sans proprietaire
Un connecteur a ete reautorise sans trace
Un role temporaire reste ouvert
La meme relance peut reproduire le doublonLa correction durable est souvent un meilleur contrat : identifiant fonctionnel obligatoire, action idempotente, logs corrélables, retry borné, dead-letter exploitable et étape de compensation connue.
Conclusion
Une Logic App en échec ne se traite pas par réflexe avec Resubmit. Le workflow peut être sain alors que le déclencheur, le connecteur, l’identité, le réseau ou la dépendance cible a dérivé. À l’inverse, le workflow peut avoir déjà réussi l’action importante avant d’échouer sur une étape secondaire.
Le bon runbook fige le payload, prouve l’identité, lit les connecteurs, vérifie le chemin réseau si nécessaire, corrèle les effets et choisit entre relance, reprise, compensation ou blocage. C’est cette décision qui évite de transformer une panne d’intégration en incident de doublons ou de droits trop larges.