Éviter les flux de travail en double

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 2 minutes de lecture
  • Les ensembles de mises à jour gèrent 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é 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. Le workflow A : version 1 est créé et publié 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. Le 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. Le 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 version 2.

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

    5. L’ensemble de mises à jour B est terminé.
    6. Le workflow A : version 3 est publié 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 version 3.

      Un enregistrement de mise à jour de client est ajouté à l’ensemble de mises à jour C avec le workflow de 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.

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

      La mise à jour du workflow A – Version 2 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 lié à la migration de l’ensemble de mises à jour

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

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

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