Déplacement du workflow avec ensembles de mises à jour

Rversion finale: Zurich

Mis à jour 31 juil. 2025

6 minutes de lecture

Le système suit les workflows dans les ensembles de mises à jour différemment des autres enregistrements, car les informations sur les workflows sont stockées dans plusieurs tables.

Les modifications apportées à une version de workflow ne sont pas ajoutées à l’ensemble de mises à jour tant que le workflow n’est pas publié, après quoi l’ensemble du workflow est ajouté à l’ensemble de mises à jour. Les ensembles de mises à jour stockent les workflows sous la forme d’un enregistrement unique de workflow [wf_workflow] et ne conservent que la dernière version avec le type de mise à jour du workflow.

Pour plus d’informations sur les ensembles de mises à jour, voir Ensembles de mises à jour système.

Cas d’utilisation de migration d’ensemble de mises à jour de workflow : simple

Créez un workflow sans dépendance, puis migrez le workflow dans un ensemble de mises à jour.

L’utilisateur A sélectionne l’ensemble de mises à jour A.
L’utilisateur A crée un nouveau workflow appelé Workflow A.
L’utilisateur A publie le workflow A.
Un enregistrement d’ensemble de mises à jour client est ajouté à l’ensemble de mises à jour A contenant une charge utile XML, y compris le workflow A publié et toutes les dépendances d’activité. La charge utile XML contient également les variables d’entrée de workflow associées au workflow.
L’utilisateur A termine l’ensemble de mises à jour A et le migre vers l’instance de production.
L’ensemble de mises à jour A est validé avec succès.
Le workflow A fonctionne comme prévu.

Cas d’utilisation de migration d’ensemble de mises à jour de workflow : dépendance de flux secondaire (réussite)

Modifiez et migrez avec succès un workflow existant et son flux secondaire dépendant.

L’utilisateur A sélectionne l’ensemble de mises à jour B.
L’utilisateur A vérifie le workflow A.
L’utilisateur A ajoute un flux secondaire appelé Workflow B au workflow A.
Supposons que le workflow B a déjà été publié et migré vers l’instance de production.
L’utilisateur A publie le workflow A.
Un enregistrement d’ensemble de mises à jour client est ajouté à l’ensemble de mises à jour B contenant une charge utile XML, y compris le workflow A publié et toutes les dépendances d’activité. La charge utile XML contient également les variables d’entrée de workflow associées au workflow.
L’utilisateur A termine l’ensemble de mises à jour B et le migre vers l’instance de production.
L’ensemble de mises à jour B est validé avec succès.
Le workflow A fonctionne comme prévu avec le workflow B en tant que flux secondaire.

Cas d’utilisation de migration d’ensemble de mises à jour de workflow : dépendance de flux secondaire (échec)

Modifiez et migrez un workflow existant d’une instance de test vers une instance de production qui ne s’exécute pas sur l’instance de production en raison d’un flux secondaire dépendant manquant.

L’utilisateur A sélectionne l’ensemble de mises à jour C.
L’utilisateur A vérifie le workflow A.
L’utilisateur A ajoute un flux secondaire appelé Workflow B au workflow A.
Supposons que le workflow B a déjà été publié, mais n’a pas été migré vers l’instance de production.
L’utilisateur A publie le workflow A.
Un enregistrement d’ensemble de mises à jour client est ajouté à l’ensemble de mises à jour C contenant une charge utile XML, y compris le workflow A publié et toutes les dépendances d’activité. La charge utile XML contient également les variables d’entrée de workflow associées au workflow.

Le flux secondaire appelé Workflow B est absent de l’ensemble de mises à jour C. Le workflow B a été publié avant que l’utilisateur A ne sélectionne l’ensemble de mises à jour C.
L’utilisateur A termine l’ensemble de mises à jour C et le migre vers l’instance de production.
L’ensemble de mises à jour C est validé avec des avertissements.
Le workflow A est invoqué sur l’instance de production avec les résultats suivants :
Le workflow A échoue au contrôle de validation d’exécution et ne peut pas s’exécuter sur le système de production. Le système ajoute au contexte du workflow une entrée de journal de workflow détaillant la cause de l’échec, notamment l’absence de workflow dépendant.
Pour en savoir plus sur les contrôles de validation sur les dépendances de workflow et les ensembles de mises à jour, reportez-vous à la section ValidateUpdateSetDependencies.

Cas d’utilisation de migration d’ensemble de mises à jour de workflow : dépendance de flux secondaire (risque)

Plusieurs utilisateurs migrent un workflow d’une instance de test vers une instance de production sans coordination appropriée. Ce cas d’utilisation peut réussir, mais seulement lorsque chaque utilisateur comprend les dépendances et migre correctement les parties dépendantes du workflow vers la nouvelle instance.

Cet exemple ne représente pas un échec d’ensemble de mises à jour, bien que les ensembles de mises à jour soient le plus souvent blâmés dans ce cas d’utilisation. La validation augmente la visibilité des dépendances de workflow sur plusieurs ensembles de mises à jour et fournit de meilleures informations aux concepteurs. Dans la plupart des cas, les avertissements n’empêchent pas une action, mais identifient uniquement le risque. Le concepteur est responsable de donner suite aux conseils donnés lors des contrôles de validation.

L’utilisateur A sélectionne l’ensemble de mises à jour C.
L’utilisateur A vérifie le workflow A.
L’utilisateur A ajoute un flux secondaire appelé Workflow B qui renvoie un ID d’utilisateur.
Remarque :
Supposons que le workflow B a déjà été publié et migré vers l’instance de production.
L’utilisateur A utilise la valeur de retour du workflow B pour générer des approbations.
L’utilisateur B sélectionne l’ensemble de mises à jour D.
L’utilisateur B extrait le workflow B (le flux secondaire dans le workflow A).
L’utilisateur B modifie la valeur de retour du workflow en la changeant d’un ID utilisateur en un message de chaîne.
L’utilisateur A publie le workflow A.
Remarque :
Une boîte de dialogue affiche les avertissements associés au workflow A et encourage l’utilisateur A à valider le workflow avant la publication.
L’utilisateur A annule la publication et valide le workflow A.
L’utilisateur A est averti que le workflow B a été modifié par un utilisateur dans un ensemble de mises à jour différent.
L’utilisateur A ignore cet avertissement et publie le workflow A.
Remarque :
Un enregistrement d’ensemble de mises à jour client est ajouté à l’ensemble de mises à jour C contenant une charge utile XML, y compris le workflow A publié et toutes les dépendances d’activité. La charge utile XML contient également les variables d’entrée de workflow associées au workflow.
L’utilisateur A termine l’ensemble de mises à jour C et le migre vers l’instance de production.
Le workflow A est invoqué sur l’instance de production et s’exécute avec succès avec l’ancienne version du workflow B déjà installée sur le système.
L’utilisateur B publie le workflow B.
Remarque :
L’utilisateur B n’est pas averti de la dépendance de l’ensemble de mises à jour C, car l’ensemble de mises à jour n’est plus en cours. Toutefois, l’utilisateur B est informé par une boîte de dialogue que des avertissements sont associés à la version du workflow et est invité à valider le workflow B. Si l’utilisateur B annule la publication et valide le workflow, l’utilisateur B est averti qu’il existe des workflows qui utilisent le workflow B comme flux secondaire. Sachant que la valeur de retour a été modifiée, l’utilisateur B devrait également tester ces workflows. Reportez-vous à la section ValidateUpdateSetDependencies pour comprendre les paramètres des avertissements d’ensemble de mises à jour.
L’utilisateur B publie enfin le workflow B.
Remarque :
Un enregistrement d’ensemble de mises à jour client est ajouté à l’ensemble de mises à jour D contenant une charge utile XML, y compris le workflow B publié et toutes les dépendances d’activité.
L’utilisateur B termine l’ensemble de mises à jour D et le migre vers l’instance de production.
L’ensemble de mises à jour D est validé sans avertissement.
Le workflow A est invoqué sur l’instance de production et ne s’exécute pas correctement, car la valeur de retour du workflow B ne génère plus d’ID d’utilisateur.