Déplacement du workflow avec ensembles de mises à jour
Le système suit les workflows dans les ensembles de mises à jour différemment des autres enregistrements, car les informations de workflow 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é, auquel cas l’ensemble du workflow est ajouté à l’ensemble de mises à jour. Les ensembles de mises à jour stockent les workflows sous la forme d’un seul enregistrement de workflow [wf_workflow] et ne conservent que la dernière version avec le type de mise à jour de workflow.
Pour plus d’informations sur les ensembles de mises à jour, consultez 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épendances, 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’update set 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.
- Validations de l’ensemble de mises à jour A réussies.
- 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)
Modification et migration réussies d’un workflow existant et de 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’update set 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.
- Validations de l’ensemble de mises à jour B réussies.
- Le workflow A fonctionne comme prévu, le workflow B étant un flux secondaire.
Cas d’utilisation de migration d’ensemble de mises à jour de workflow : dépendance (échec) de flux secondaire
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 qu’il n’a pas été migré vers l’instance de production.
- L’utilisateur A publie le workflow A.
Un enregistrement d’update set 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.
- Validations de l’ensemble de mises à jour C avec avertissements.
- Le workflow A est appelé sur l’instance de production avec les résultats suivants :
Le workflow A échoue à la vérification de validation de l’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 la défaillance, notamment l’absence d’un workflow dépendant.
Pour en savoir plus sur les vérifications de validation sur les dépendances de workflow et les ensembles de mises à jour, reportez-vous 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 une défaillance 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 aux concepteurs de meilleures informations. Dans la plupart des cas, les avertissements n’empêchent pas une action, mais identifient seulement 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 remplaçant un ID d’utilisateur par 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 de le publier.
- 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’update set 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 appelé sur l’instance de production et s’exécute avec succès à l’aide de l’ancienne version du workflow B déjà présente 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é via 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 doit également tester ces flux de travail. Consultez la rubrique 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’update set client est ajouté à l’update set 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.
- Validations de l’ensemble de mises à jour D sans avertissement.
- Le workflow A est appelé sur l’instance de production et ne s’exécute pas avec succès, car la valeur de retour du workflow B ne génère plus d’ID d’utilisateur.