Éviter les flux de travail en double

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 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ée en tant qu’insertion ou 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.

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

    4. Workflow A - La 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 de validations d’ensembles de mises à jour. Toutefois, cela n’élimine pas le risque et des précautions doivent être prises lors de la migration des ensembles de mises à jour.

    Prenons cet exemple :
    1. Workflow A : la version 1 est migrée et validée vers 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 et le workflow de la version 1 n’est pas publié.

    5. L’ensemble de mises à jour B est terminé.
    6. Workflow A : la version 3 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 et le workflow de la version 2 n’est pas publié.

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

      Le workflow A - Version 1 est défini sur Non publié.

      Workflow A : la mise à jour de la 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 de migration de l’ensemble de mises à jour

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

    1. Le workflow A - Version 3 est défini sur Non publié.
    2. Le workflow A - Version 1 n’a pas encore été publié.
    3. Workflow A : la version 2 est validée et devient la seule version publiée du workflow.

      Le workflow est revenu à une version, peut-être involontairement. La version régressée devient la version actuellement publiée.