Création d'un flux de travail de version personnalisé

Lorsque vous configurez un processus de release personnalisé comprenant deux niveaux et que le second niveau n'est pas requis (c'est-à-dire que le second niveau est facultatif) Onshape passe automatiquement de En attente à Publié si aucun validateur n'est spécifié dans le package de release. Aucune configuration n'est requise pour cela, la seule condition requise est de disposer d'un flux de travail à deux niveaux, avec un second niveau facultatif et aucun validateur indiqué dans le champ Validateur du candidat à la release.

Pour télécharger les fichiers de flux de travail par défaut Onshape :

1. Accédez aux Paramètres Enterprise et sélectionnez Gestion des versions.
2. Vérifiez que Activer les workflows gérés est cochée, puis cliquez sur Afficher dans le document.

   

   Le fichier de flux de travail s'ouvre dans un document public dans un autre onglet.

3. Cliquez sur Télécharger, saisissez un nouveau nom pour le fichier.
   

   Vous pouvez fermer cet onglet une fois que l'onglet est téléchargé.

1. Dans votre entreprise, accédez à la page Documents, sélectionnez Créer un document, puis sélectionnez OK. (Dans cet exemple, le nom du document est Workflows personnalisés de la société)
2. Dans le nouveau document, cliquez sur l'icône Plus en bas et sélectionnez Importer :

3. Sélectionnez le fichier de flux de travail que vous venez de télécharger et cliquez sur Ouvrir.
4. Un autre onglet apparaît dans votre document, avec le nom du fichier que vous avez importé. Sélectionnez cet onglet pour l'ouvrir :

Vous pouvez utiliser les actions de workflow FeatureScript pour mettre à jour par programme les propriétés des éléments de release dans le cadre d'une transition de workflow. En orientant le workflow personnalisé vers un Atelier des fonctions dans le même espace de travail que la définition du workflow, une fonction de cet Atelier des fonctions peut être exécutée en tant qu'action qui détermine les mises à jour de propriétés à appliquer à chaque élément de release.

Pour l'utiliser dans un workflow personnalisé, utilisez l'action de workflow UpdateItemPropertiesFromFeatureScript en tant qu'action de transition ou action d'entrée ou de sortie sur un état. L'action prend les paramètres suivants :

• ID FeatureStudio - L'Atelier des fonctions doit résider dans le même espace de travail que la définition de processus de release personnalisée

• Un nom de fonction exporté par cet Atelier des fonctions - Cette fonction doit prendre un seul argument de type : map. Le type de carte transmis à la fonction lors de son exécution contient les données suivantes :

{

// Le package de release détaillé complet, y compris tous les éléments et propriétés

// (tel qu'il serait renvoyé par l'API REST getReleasePackage)

"releasePackage": BTReleasePackageInfo,

// L'utilisateur effectuant la transition

"currentUser": BTUserSummaryInfo,

// L'utilisateur qui a initialement créé le candidat à la release

"releaseCreator": BTUserSummaryInfo,

// La transition en cours d'exécution, telle qu'elle apparaît dans la définition du workflow

"transition": BTTransitionDef,

// La date/heure UTC actuelle, sous forme de chaîne de date ISO

"currentDate": string

}

La fonction doit renvoyer une carte de la forme :

{[key: string]: {[key: string]: any}}

La carte principale est indexée par ID d'élément de version et la carte interne va de l'ID de propriété des métadonnées à une nouvelle valeur souhaitée. Par exemple, si la fonction renvoie la carte suivante :

{

"item1": {

"57f3fb8efa3416c06701d616": "New value",

"customIntProperty": 42

},

"item2": {

« 57f3fb8efa3416c06701d617 »: « Une autre valeur »

}

}

Ensuite, sur l'élément de release portant l'ID “item1”, la propriété “Title 1” sera définie sur la chaîne “New value”, et une propriété personnalisée hypothétique (CustomIntProperty, ci-dessus) sera définie sur le numéro 42. Sur l'élément dont l'ID est “item2”, la propriété “Title 2” sera définie sur la chaîne “Some other value”.

Les informations complètes du package de version sont fournies en entrée de la fonction, de sorte que le filtrage et le calcul supplémentaires peuvent être effectués selon les besoins. Par exemple, appliquer une propriété uniquement aux éléments qui sont des dessins, ou uniquement aux éléments qui ont une certaine catégorie, ou calculer une valeur de propriété à partir d'une autre valeur de propriété.

Il est important de noter que FeatureScript lui-même n'applique aucune modification au package de version ; les modifications apportées aux données en entrée ne survivront pas à l'exécution FeatureScript. Au lieu de cela, c'est la valeur renvoyée par la fonction qui indique au système les modifications à apporter.

Types de valeur de propriété

Le type de valeur dans la carte renvoyée doit correspondre au type de valeur de la propriété de métadonnées correspondante (comme il serait envoyé à l'API « mettre à jour les métadonnées ») ; une valeur non valide entraînera l'échec de la mise à jour de la propriété.

Une propriété de métadonnées de type utilisateur accepte un tableau d'objets de la forme :

{"id": [userId]}

Une propriété de workflow de type utilisateur contient un tableau d'objets dont l'ID utilisateur se trouve dans le champ « EntryId ». Par conséquent, pour ajouter un utilisateur d'une propriété de workflow à une propriété de métadonnées, la valeur doit être transformée au bon format.

Une propriété de métadonnées de type utilisateur accepte uniquement les ID utilisateur, pas les ID d'équipe ou de rôle. Pour appliquer une propriété de workflow de type utilisateur à une propriété de métadonnées de type utilisateur, utilisez uniquement les entrées de la propriété de workflow qui sont des utilisateurs, c'est-à-dire celles dont le « EntryType » est égal à 0.

Si une mise à jour de propriété échoue en raison d'un propertyID ou d'une valeur incorrecte dans l'objet renvoyé, l'action du workflow échoue et les échecs sont consignés pour que les développeurs de workflow puissent les utiliser pour l'analyse (voir Vérification des workflows, ci-dessous).

L'action échoue également si une erreur se produit pendant l'exécution du FeatureScript ou si l'objet retourné est mal formé. Par exemple, si l'objet renvoyé n'est pas un mappage d'ID d'éléments vers des mises à jour de propriétés.

Si l'action échoue, cela est probablement dû à un bug dans le FeatureScript du workflow plutôt qu'à un bug dans le système. Dans ce cas, vous recevrez un message d'erreur renvoyé avec la réponse HTTP vous demandant (ou vos utilisateurs) de contacter l'administrateur du workflow. Le développeur de workflow peut utiliser le journal d'audit du workflow pour identifier et résoudre l'échec (voir Journalisation d'audit de workflow, ci-dessous). Si nécessaire, le développeur du workflow peut créer un ticket d'assistance avec Onshape.

Autorisation globale Gérer les workflow

Il s'agit d'une nouvelle autorisation globale dans Onshape Enterprise qui permet de publier et de résoudre les anomalies des processus de release personnalisés. Les utilisateurs disposant de cette autorisation peuvent publier des workflows et auront toujours la possibilité de créer un candidat à la release en mode résolution d'anomalies (voir Vérification des workflows, ci-dessous).

Les workflows cycliques ne sont pas autorisés.

Seuls les utilisateurs disposant de l'autorisation globale Gérer les flux de travail peuvent publier des flux de travail. Pour plus d'informations sur les autorisations globales, voir Comprendre les autorisations globales.

Modifiez le flux de travail personnalisé, comme indiqué ci-dessous :

1. Apporter des modifications au fichier de flux de travail JSON. Au fur et à mesure que vous modifiez, le diagramme de droite reflète les modifications apportées.
2. Le diagramme est dynamique et déplaçable. Par conséquent, si la structure ne reflète pas le flux de travail prévu, utilisez votre curseur pour l'ajuster.
3. Une fois que vous êtes satisfait(e) de vos modifications et que vous souhaitez rendre votre flux de travail disponible pour une utilisation dans l'entreprise, cliquez sur Publier pour ouvrir la boîte de dialogue Publier un flux de travail personnalisé :

   

   La boîte de dialogue vous avertit de toute erreur à corriger avant de publier, affichée en haut de la boîte de dialogue :

   

   1. Cliquez sur Annuler pour fermer la boîte de dialogue.

   2. Corrigez les erreurs.

   3. Cliquez sur Publier une nouvelle fois pour ouvrir la boîte de dialogue.

4. Entrez un nom, une description et un type de flux de travail.

5. Dans le menu déroulant Remplacer le flux de travail, effectuez l'une des opérations suivantes :

   1. S'il s'agit d'un nouveau flux de travail, sélectionnez Aucun.

   2. Pour remplacer un flux de travail existant, sélectionnez celui que vous souhaitez remplacer. Les champs Nom et Description de remplacement sélectionnés sont automatiquement remplis. Vous pouvez conserver les valeurs existantes ou en saisir de nouvelles :

      

6. Cliquez sur Publier.

Lorsque la publication d'un workflow est annulée, les événements suivants se produisent :

• Le flux de travail n'est plus disponible pour être utilisé dans la gestion des versions pour créer de nouveaux packages de release.

• Tous les paramètres utilisant le flux de travail supprimé sont réinitialisés sur le flux de travail par défaut Onshape.

• Les candidats à la release ou à l'obsolétisation actuellement inclus dans le workflow supprimé continuent de fonctionner normalement. Les packages de release existants et ceux soumis à l'aide du workflow non publié ne sont pas affectés. Vous pouvez toujours ouvrir, afficher et rendre obsolètes les packages de release existants à l'aide du workflow personnalisé et transférer les releases en attente.

Only users who have Manage workflows permissions (under Enterprise settings > Global permissions) can unpublish a workflow.

Pour annuler la publication d'un workflow :

1. Cliquez sur votre nom ou sur l'icône d'utilisateur du compte () dans le coin supérieur droit de la barre d'outils Documents et sélectionnez Paramètres Enterprise > Gestion des versions.

2. Sélectionnez le processus de release à annuler dans la liste déroulante du workflow.

3. Cliquez sur le lien Afficher dans le document situé à droite de la liste déroulante du flux de travail. Le document de flux de travail s'ouvre dans l'onglet actuel du navigateur.

4. Cliquez sur le bouton Annuler la publication en haut du document.

   

5. La boîte de dialogue Annuler la publication du workflow s'ouvre. Cliquez sur le bouton Annuler la publication.

L'annulation de la publication d'un workflow par défaut rétablit le workflow par défaut sur la valeur par défaut d'Onshape.

Un utilisateur disposant de l'autorisation globale Gérer les workflow peut tester un workflow en développement à l'aide du mode de résolution d'anomalies.

Le workflow doit d'abord être publié afin d'être disponible dans la boîte de dialogue Sélectionner le processus de release lors de la publication d'une pièce/d'un assemblage. (Une fois que vous êtes satisfait du nouveau workflow, vous pouvez revenir aux paramètres d'entreprise et activer le workflow.)

Un workflow publié typique oriente vers une version du document dans laquelle se trouve la définition du workflow (le fichier JSON file). Les versions utilisant ce workflow publié suivent le workflow tel que défini dans cette version. Le mode résolution d'anomalies utilise plutôt le workflow tel qu'il existe dans l'espace de travail du document associé à la version publiée. Notez qu'un workflow ne démarre en mode Résolution d'anomalies que s'il existe exactement un espace de travail au-dessus de la version publiée, éliminant ainsi toute ambiguïté.

Le mode de résolution d'anomalies permet une itération rapide pendant le développement du workflow. Si vous constatez que le workflow ne fonctionne pas comme prévu, vous pouvez apporter une modification au workflow JSON ou à l'Atelier des fonctions consommé par la nouvelle action dans l'espace de travail. Le fait de démarrer immédiatement une nouvelle version vous permet (le développeur du workflow) de voir les effets sans avoir à publier une nouvelle version du workflow au préalable.

Pour résoudre les anomalies d'un workflow :

1. Cochez la case Mode résolution d'anomalies (comme indiqué dans l'image ci-dessus).

2. Cliquez sur OK. La boîte de dialogue Créer une version candidate s'ouvre :

   

3. Dans cette boîte de dialogue, vous pouvez sélectionner le bouton du menu de débordement () dans le coin supérieur droit, puis cliquer sur Afficher le journal d'audit pour afficher une piste d'audit des objets de workflow et de leurs événements importants, par exemple, la création et la transition.

4. Vous pouvez également sélectionner Afficher le workflow pour voir le workflow sous forme de diagramme, avec le dernier état en surbrillance, comme dans le diagramme ci-dessous :

   

Les modifications apportées dans l'espace de travail à un flux de travail en mode résolution d'anomalies n'affecteront aucune release déjà en cours. Une release de mode en résolution d'anomalie est verrouillée sur la microversion de l'espace de travail au moment de sa création. Pour voir les résultats des modifications, vous devez créer une nouvelle release. Cette procédure empêche les modifications apportées à la définition de flux de travail d'interrompre une release en cours et d'empêcher son annulation.

Une fois que vous avez publié un flux de travail personnalisé, vous pouvez activer plusieurs flux de travail actifs dans votre entreprise si vous le souhaitez. Lorsque plusieurs flux de travail actifs sont disponibles pour vos utilisateurs, ils peuvent sélectionner le flux de travail à suivre lors de la création d'un candidat à la release.

Il est de la responsabilité de l'administrateur d'éduquer les utilisateurs sur les flux de travail à utiliser et dans quelles conditions.

Pour activer plusieurs flux de travail :

1. Suivez les instructions ci-dessus pour créer plusieurs flux de travail personnalisés et les publier dans Onshape.
2. Dans le Gestion des versions page de Paramètres d'entreprise, sélectionnez les flux de travail personnalisés à activer dans la section Flux de travail gérés en cochant la case Actif à côté de chaque flux de travail :

   

3. Cliquez sur l' Icône d’aperçu du workflow () pour développer la liste déroulante d'une illustration montrant le flux de travail. Sous l'illustration se trouve une description du processus de flux de travail actuel :

   

4. Assurez-vous de cliquer sur Enregistrer les paramètres de version pour enregistrer les modifications que vous avez apportées aux paramètres de gestion des versions pour l'entreprise.

Lorsque vos utilisateurs créent un candidat à la release, ils ont la possibilité de sélectionner un flux de travail à ce moment-là (dans la liste déroulante) :

La syntaxe permettant de personnaliser le flux de travail de publication ou obsolescence est présentée ci-dessous. Notez que la capitalisation est importante.

Gardez à l'esprit les règles suivantes.

Properties

Format

• name: string
• propertyId: string
• valueType: string|ENUM
• defaultValue?: any
• usersOnly?: boolean
• teamsOnly?: boolean
• enumValues?: list

Restrictions

• Les ID de propriété doivent être uniques (et ne correspondent pas à l'ID de propriété Nom, Description ou Commentaire codé en dur d'Onshape)
• ValueType doit être le nom d'un BTMetaDataValueType (sauf BLOB et OBJECT)
• Si ValeurType est ENUM, EnumValues doit être spécifié et la propriété doit contenir une ou plusieurs EnumValues. Chacune des valeurs EnumValues doit avoir un élément de valeur obligatoire. L'élément label est facultatif.
• Si la valeur DefaultValue est fournie, elle doit correspondre au champ de valeur de l'une des valeurs EnumValues.
• usersOnly et TeamsOnly sont mutuellement exclusifs et valides uniquement pour USER properties
• defaultValue, le cas échéant, doit correspondre au type correct indiqué par ValueType
  • STRING : string
  • BOOL : booléen
  • INT : entier
  • DOUBLE : décimal
  • USER: string[]
  • DATE: ISO chaîne de date
  • BLOB et OBJECT ne sont pas pris en charge
• Les valeurs de propriété de type utilisateur sont une liste d'ID utilisateur, d'équipe et/ou de rôle

États

Format

• name - Chaîne
• displayName- Chaîne
• approverSourceProperty?- Chaîne
• notifierSourceProperty? - Chaîne
• entryActions?: Action[]
• exitActions?: Action[]
• editableProperties?- Chaîne[]
  • Les valeurs peuvent inclure :

    • approbateurs

    • observateurs

• requiredProperties?- Chaîne[]
• requireditemProperties?- Chaîne[]

Restrictions

• Les noms doivent être uniques
• approversSourceProperty et NotifierSourceProperty, le cas échéant, doivent être les ID de propriété du flux de travail et pointer vers les propriétés de type utilisateur
• Tout au plus, un état peut utiliser une propriété donnée comme validateurs.
• Un certain nombre d'États peuvent utiliser un bien donné comme déclarants.
• editableProperties et requiredProperties doivent être des ID de propriété dans le même flux de travail.
• requireditemProperties doivent être des ID de propriété de métadonnées valides pour votre société (propriétés intégrées Onshape ou propriétés personnalisées, à l'exclusion des propriétés calculées).

Pour plus d'informations sur les identifiants, voir Comprendre et administrer les rôles du projet et les systèmes d'autorisation.

Transitions

Format

• name - Chaîne
• displayName- Chaîne
• type - Chaîne
• SourceState - Chaîne
• TargetState - Chaîne
• uiHint?- Chaîne (par défaut : "primary")
• actions?: Action[]
• requiredProperties?- Chaîne[]

Restrictions

• Les noms doivent être uniques.
• Le type doit être « APPROVE», « REJECT» ou « SUBMIT».
• sourceState et TargetState doivent être deux états différents dans le flux de travail.
• Il peut y avoir, au plus, une transition de type Approbation à partir de n'importe quel état source.
• Pour une transition de type Approbation, SourceState doit avoir une propriété approbationSourceProperty.
• uiHint, s'il est présent, doit être « primaire », « succès » ou « danger » (ce sont les couleurs des boîtes et autres entités dans la boîte de dialogue de publication et sont codées en dur par Onshape).

Types de transition

Soumettre

• Effectue diverses « initialisations » sur la version à mesure qu'elle sort de la configuration et dans le flux de travail, telles que le lancement de la génération de vignettes pour les pièces configurées dans la version, la connexion des identifiants de document/version liés, etc.
• Seul le créateur de version a la possibilité d'exécuter des transitions SOUMETTRE.
• Les transitions hors de l'état initial doivent être Soumissions.
• Une Soumission qui n'est pas une transition initiale n'a pas de capacités spéciales

Approuver

• Marque l'utilisateur comme ayant approuvé (indique un jeton vert dans la boîte de dialogue de publication).
• Si les stratégies de l'entreprise sont définies sur Nécessite tous les validateurs, la transition ne sera pas effectuée tant que tous les validateurs n'auront pas approuvé.
• Génère des références de contenu d'assemblage/dessin pour les éléments.
• Une seule transition de ce type est autorisée hors d'un état.
• Seul un validateur de l'état actuel (ou un administrateur) a la capacité d'approuver.

Rejeter

• Marque l'utilisateur comme ayant rejeté (indique un jeton rouge dans la boîte de dialogue de publication).
• Seul un validateur de l'état actuel (ou un administrateur) a la possibilité de rejeter.

Actions

Format

• name: string
• params?: {[key: string]: any}

Restrictions

• Le nom doit correspondre à l'un de nos noms d'action prédéfinis (voir ci-dessous, sous Actions autorisées)
• Certaines actions peuvent être autorisées uniquement sur les états ou sur les transitions, certaines peuvent avoir des restrictions d'ordre.

Tâches autorisées

• sendEmailNotifications - Envoyer des notifications par e-mail pour une transition (y compris les notifications push mobiles).
  • Autorisé sur : transitions uniquement
  • Paramètres : aucun
• sendUserNotifications - Envoyer des notifications utilisateur pour une transition.
  • Autorisé sur : transitions uniquement
  • Paramètres : aucun
• MarkItemPending - Modifiez l'état des métadonnées de tous les éléments de la version en les mettant En attente.
  • Autorisé sur : états ou transitions
  • Paramètres : aucun
  • Non autorisé sur les workflows d'obsolescence.
  • Dans les processus de release, impossible après markItemsReleased ou markItemsRejected.
• markItemsRejected - Modifiez l'état des métadonnées de tous les éléments de la version en Rejeté.
  • Autorisé sur : états ou transitions
  • Paramètres : aucun
  • Non autorisé dans les workflows d'obsolescence.
  • Dans les processus de release, impossible après markItemsReleased ou avant markItemsPending
• releaseItems - Modifiez l'état des métadonnées de tous les éléments de la version sur Publié et créez des révisions pour eux (obsolétisation automatique des autres révisions si spécifié dans la stratégie de la société).

  Autorisé sur : états ou transitions

  Paramètres : aucun

  Non autorisé sur les workflows d'obsolescence.

• obsoleteItems - Modifier l'état des métadonnées de tous les éléments du package sur Obsolète et rendez obsolète leurs révisions correspondantes.
  • Autorisé sur : états ou transitions
  • Paramètres : aucun
  • Non autorisé sur les processus de release
• updateItemPropertiesFromFeatureScript - Utilisez ceci pour utiliser une fonction FeatureScript comme action de transition, ou comme action d'entrée ou de sortie sur un état.
  • Autorisé sur : états ou transitions
  • Paramètres : map (argument unique avec ce type)

Lorsque vous définissez un flux de travail personnalisé, vous pouvez inclure une section d'options destinée à remplacer les paramètres de version spécifiques de l'entreprise définis sur la page Paramètres Enterprise > Gestion des versions. Ces options de remplacement sont expliquées ci-dessous :

"options": {

"revisionSchemeId": string,

"requireApprover": boolean,

"requireAllApprovers": boolean,

"disallowCreatorAsApprover": boolean,

"requireNote": boolean,

"autoObsolete": boolean,

"errorOnFeatureListErrors": boolean,

"errorOnRolledBack": boolean,

"errorOnAssemblyErrors": boolean,

"errorOnAssemblyRefsOutOfDate": boolean,

"errorOnDrawingOutOfDate": boolean,

"errorOnPartNumberPending": boolean,

"errorOnPendingTask": boolean,

"nameOverride": chaîne, (remplace l'étiquette du nom de la version, ou le nom de l'obseletion, dans la boîte de dialogue Release

"descriptionOverride": (remplace l'étiquette Release notes, ou Obseletion notes, dans la boîte de dialogue Release)

}

Cette section et tous les champs sont facultatifs. Vous pouvez sélectionner n'importe quel sous-ensemble par lequel vous souhaitez remplacer un paramètre de l'entreprise. Tous les champs non inclus dans le code seront définis par défaut selon les spécifications des paramètres Enterprise.

L'identifiant du système de révision peut être récupéré dans le champ de texte en lecture seule sur la page Paramètres d'entreprise > Gestion des versions :

Tous les objets de workflow créent une piste d'audit des événements importants au cours de leur vie, par exemple, la création et la transition. Ce journal peut être récupéré à l'aide de

GET /api/workflow/obj/<object id>/auditlog

Vous pouvez afficher le résultat de cet appel via un lien dans la version, afin d'inspecter et de résoudre les problèmes..

La réponse du journal d'audit contient des informations de base sur le workflow objet (y compris sa version de workflow publiée et s'il s'agit d'un workflow en mode résolution d'anomalies) et tous les événements qui y sont consignés.

Chaque entrée de journal contient :

• Un horodatage

• Un type (représenté par un entier qui est un ordinal BTWorkflowAuditEntryType)

• L'état/la transition/l'action du workflow au moment de l'événement.

Il existe également d'autres champs pour des informations supplémentaires spécifiques au type d'événement, le cas échéant.

Les types d'événements d'audit sont les suivants :

• Objet créé - Premier événement enregistré pour un objet, lors de sa création.

• Objet rejeté - Lorsque l'action spéciale Rejeter est effectuée sur l'objet.

• Objet supprimé - Lorsque l'objet est supprimé, généralement parce qu'il est suffisamment ancien pour être détecté par le serveur de nettoyage (le journal d'audit d'un objet supprimé n'est pas supprimé).

• Propriétés mises à jour - Lorsque les propriétés du workflow sont modifiées sur l'objet. Il s'agit des propriétés au niveau du package d'un package de version (par exemple), et non des propriétés de métadonnées sur des éléments individuels.

  • Cela inclut les ID de propriété (issus de la définition du workflow) qui ont été modifiés, y compris leurs anciennes et nouvelles valeurs.

• Commentaire ajouté - Inclut l'ID du commentaire nouvellement ajouté.

• Approuvé par l'utilisateur - Lorsqu'un utilisateur exécute l'action d'approbation pour l'état actuel. Cela peut être accompagné ou non d'une transition, selon les paramètres de release de l'entreprise.

  • Cela inclut les ID utilisateur/équipe/rôle dans la liste des approbateurs pour lesquels l'action a été effectuée, c'est-à-dire pour le compte duquel l'utilisateur a approuvé.

• Rejeté par l'utilisateur - Lorsqu'un utilisateur exécute l'action de rejet pour l'état actuel.

  • Cela inclut les ID utilisateur/équipe/rôle dans la liste des approbateurs pour lesquels l'action a été effectuée, c'est-à-dire pour le compte duquel l'utilisateur a rejeté.

• La transition a commencé

• Transition terminée

• Échec de la transition - Inclut un message d'erreur ou un code destiné à l'assistance, le cas échéant.

• Action commencée

• Action terminée

• Échec de l'action - Inclut un message d'erreur ou un code destiné à l'assistance, le cas échéant.

• FeatureScript exécuté - Inclut tout résultat de console issu de l'exécution FeatureScript.

  • Cela inclut toutes les notifications renvoyées par l'exécution FeatureScript (y compris une exception, le cas échéant).

  • Inclut la valeur renvoyée par la fonction FeatureScript.

• Les mises à jour des métadonnées d'élément ont échoué - Lorsque la demande de mise à jour des métadonnées d'un élément de package de version échoue pendant une transition.

  • Cela inclut les ID de propriété des métadonnées ayant échoué, les hrefs de métadonnées des éléments ayant échoué et un message d'erreur.

  • Cela entraîne généralement un échec de transition, sauf lorsque cela se produit au cours de l'action FeatureScript. Les actions intégrées doivent réussir, mais la définition de propriétés supplémentaires à partir de FeatureScript peut échouer tout en permettant la poursuite de la transition.