Éviter les flux de travail en double

Ensembles de mises à jour Gérez l’état publié de toutes les versions d’un workflow avant de valider la version du workflow sur une instance locale.

La dernière version d’un workflow validée sous forme d’insertion ou de mise à jour à l’aide d’un ensemble de mises à jour devient la version actuellement publiée, quelle que soit la séquence de publication des versions de workflow.

Valider un workflow dans un ensemble de mises à jour

Suivez les étapes de cette page pour valider un workflow dans un ensemble de mises à jour.

Procédure

1. La version 1 du workflow A est créée et publiée dans l’ensemble de mises à jour A.
2. L’ensemble de mises à jour A est terminé et migré vers une instance locale.
3. Lorsque l’ensemble de mises à jour est validé, le système définit toutes les versions antérieures du workflow A sur Publié = faux.

   Dans la première migration, il n’existe aucune version antérieure.

4. Workflow A : version 1 devient la seule version publiée du workflow.

Exemple de migration d’ensemble de mises à jour

Il n’est pas possible d’avoir plusieurs versions publiées à la suite des validations d’ensembles de mises à jour. Toutefois, cela n’élimine pas les risques et des précautions doivent être prises lors de la migration des ensembles de mises à jour.

Prenons cet exemple :

1. Workflow A : version 1 est migré et validé dans l’instance de production.
2. L’ensemble de mises à jour B est créé.
3. L’ensemble de mises à jour C est créé.
4. Workflow A : version 2 est publié dans l’ensemble de mises à jour B.

   Un enregistrement de mise à jour du client est ajouté à l’ensemble de mises à jour B avec la charge utile de la version 2.

   Un enregistrement de mise à jour du client est ajouté à l’ensemble de mises à jour B avec le workflow de la version 1 non publié.

5. L’ensemble de mises à jour B est terminé.
6. La version 3 du workflow A est publiée dans l’ensemble de mises à jour C.

   Un enregistrement de mise à jour du client est ajouté à l’ensemble de mises à jour C avec la charge utile de la version 3.

   Un enregistrement de mise à jour du client est ajouté à l’ensemble de mises à jour C avec le workflow de la version 2 non publié.

7. L’ensemble de mises à jour C est terminé.
8. L’ensemble de mises à jour C est migré et validé dans l’instance de production.

   Workflow A : version 1 est défini sur non publié.

   La mise à jour de la version 2 du workflow A est ignorée, car l’ensemble de mises à jour B, qui contient la version 2, n’a jamais été migré.

   Workflow A : la version 3 est validée et devient la seule version publiée du workflow.

Risque de migration de l’ensemble de mises à jour

L’ensemble de mises à jour B est migré et validé dans l’instance de production.

1. Workflow A : la version 3 est définie sur non publié.
2. Workflow A : version 1 reste non publié.
3. Workflow A : la version 2 est validée et devient la seule version publiée du workflow.

   Le flux de travail est revenu en arrière, peut-être involontairement. La version régressée devient la version actuellement publiée.