Déplacement du workflow avec ensembles de mises à jour
Le système suit les workflows des 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 avant la publication du workflow, 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 Jeux de mises à jour système.
Cas d’utilisation de migration d’ensembles 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 qui lui sont associées.
- L’utilisateur A termine l’ensemble de mises à jour A et le migre vers l’instance de production.
- Validations réussies de l’ensemble de mises à jour A.
- Le workflow A fonctionne comme prévu.
Cas d’utilisation de migration de l’ensemble de mises à jour du 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 extrait 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 qui lui sont associées.
- 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 avec le workflow B en tant que flux secondaire.
Cas d’utilisation de migration d’ensembles de mises à jour du 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 peut pas s’exécuter 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 extrait 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’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 qui lui sont associées.
Le flux secondaire appelé workflow B est particulièrement 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 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 la défaillance, 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 ValidateUpdateSetDependenciesà .
Cas d’utilisation de migration d’ensembles de mises à jour du 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 uniquement 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 seulement le risque. Le concepteur est responsable de la mise en œuvre des conseils donnés lors des contrôles de validation.
- L’utilisateur A sélectionne l’ensemble de mises à jour C.
- L’utilisateur A extrait 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 du workflow A).
- L’utilisateur B modifie la valeur de retour du workflow en passant d’un ID utilisateur à 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 qui lui sont associées.
- 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 à 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 workflows. Reportez-vous à 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’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.
- Validations de l’ensemble de mises à jour D 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.