Onshape fournit des flux de travail de gestion des versions génériques que vous pouvez commencer à utiliser immédiatement. Ce processus est décrit dans Workflow de publication typique. Outre ce flux de travail générique, Onshape vous permet de concevoir et de créer votre propre flux de travail de gestion des versions personnalisé, puis de publier ce flux de travail pour que l'ensemble de votre organisation puisse l'utiliser. Vous pouvez même créer plusieurs flux de travail pour répondre aux besoins spécifiques de votre organisation en matière de gestion des versions.

Pour accéder à cette fonctionnalité, vous devez disposer du rôle d'administrateur de votre entreprise Onshape.

Onshape propose de nombreuses options qui régissent le comportement de gestion des versions. En fonction de vos processus métier, ces paramètres peuvent être définis comme les règles par défaut concernant le comportement des versions, quelles sont les conditions de publication et le système de révision qui peut être utilisé, par exemple. Ces options peuvent être définies via la page Gestion des versions des paramètres Company/Enterprise de votre abonnement Onshape.

Dans de nombreux cas, lorsque plusieurs processus de publication sont implémentés dans une organisation, les différents processus peuvent nécessiter des paramètres de publication disparates. Les paramètres par défaut, définis dans la page Paramètres de gestion des versions, peuvent être remplacés par processus par version grâce à la mise en œuvre de processus de publication personnalisés qui peuvent également remplacer les paramètres par défaut par processus.

Lisez la suite pour découvrir le processus de création de vos propres workflows de gestion des versions personnalisés et comment les implémenter dans Onshape.

En quoi consiste la création d'un flux de travail personnalisé

Fondamentalement, Onshape utilise un fichier JSON pour définir la disposition et le comportement du flux de travail pour les flux de travail de publication et d'obsolescence.

  1. Télécharger le fichier de base Onshape JSON
  2. Personnalisez le fichier en suivant la syntaxe JSON fournie dans cette rubrique
  3. Télécharger le fichier personnalisé JSON dans un document Onshape
  4. Publier le flux de travail personnalisé dans votre organisation

Ces étapes sont expliquées en détail ci-dessous.

Téléchargez le fichier JSON

Vous trouverez un fichier de base JSON dans le domaine Onshape de votre organisation :

  1. Connectez-vous à votre compte Onshape.
  2. Accédez à la page paramètres Company/Enterprise > gestion des versions.
  3. Sous l'en-tête Flux de travail, sélectionnez le type de flux de travail à créer : Flux de travail de version ou Flux de travail d'obsolétisation.
  4. Sélectionnez Onshape default... dans la liste déroulante.
  5. Cliquez sur le lien Afficher dans le document à côté de la liste déroulante :

Exemple de configuration et d'activation des workflows gérés

Puisque le format de fichier JSON est un format texte, il est d'une part assez facile à comprendre, mais d'autre part, il peut devenir assez complexe, en particulier à mesure que nos flux de travail deviennent plus complexes. Bien qu'Onshape vous informe de certaines erreurs dans la syntaxe et la mise en forme du document, il n'est pas infaillible et de nombreuses options, bien que légales, peuvent toujours entraîner l'échec de votre flux de travail.

Pour obtenir des instructions détaillées sur la configuration et l'utilisation de plusieurs workflows Onshape, consultez la rubrique Création d'un processus de release personnalisé.

Personnalisez le JSON en fonction des besoins de votre organisation

Tout d'abord, comprenons ce qu'est le JSON. JSON signifie JavaScript Object Notation. C'est un format léger pour stocker et transporter des données. Le JSON est souvent utilisé pour envoyer des données vers et depuis un serveur et une page Web. Le format JSON est « autodescriptif » et facile à comprendre.

Le JSON est construit sur deux structures :

  • Une collection de paires nom/valeur. Dans différentes langues, cela est réalisé sous la forme d'un objet, d'un enregistrement, de structures, d'un dictionnaire, d'une table de hachage, d'une liste de clés ou d'un tableau associatif.
  • Une liste ordonnée de valeurs. Dans la plupart des langues, cela est réalisé sous la forme d'un tableau, d'un vecteur, d'une liste ou d'une séquence.

Il s'agit de structures de données universelles. Pratiquement tous les langages de programmation modernes les prennent en charge sous une forme ou une autre. Il est logique qu'un format de données interchangeable avec les langages de programmation soit également basé sur ces structures.

En JSON, les structures prennent les formes suivantes :

Un objet est un ensemble non ordonné de paires nom/valeur. Un objet commence par { accolade gauche et se termine par } accolade droite. Chaque nom est suivi de : deux points et les paires nom/valeur sont séparées par une , virgule.

Ce qui suit est représentatif de ce que vous verrez dans le flux de travail SON dans Onshape. Cet exemple définit un objet employés : un tableau de 3 enregistrements d'employés (objets) :

{
"employees":[
{"firstName":"John", "lastName":"Doe"},
{"firstName":"Anna", "lastName":"Smith"},
{"firstName":"Peter", "lastName":"Jones"}
]
}

Le format JSON Onshape

Dans Onshape, il y a 4 objets dans le fichier JSON, comme suit :

  • Options - Définir les paramètres de publication
  • Propriétés - Définir les définitions d'attributs
  • États - Définitions de noeud de contrôle
  • Transitions - Spécifier les définitions de lien

Paramètres de publication est un groupe de 10 paramètres possibles liés au comportement de la publication d'un document. Tous ces paramètres se trouvent dans la page Gestion des versions des paramètres Company/Enterprise. Toutefois, les définitions d'un fichier de flux de travail JSON remplacent tous les paramètres de gestion des versions correspondants définis dans les paramètres Company/Enterprise.

Définitions d'attribut sont des attributs qui apparaissent dans la boîte de dialogue Candidat à la release. Ces attributs peuvent être affectés à un ou plusieurs nœuds dans le flux de travail et peuvent être de types différents, obligatoires ou facultatifs, et peuvent contenir des valeurs par défaut, par exemple : « Référence de pièces ».

Les définitions de nœuds définissent le type de nœuds contenus dans le flux de travail et les attributs affectés au nœud. Par exemple, « En attente » ou « Publié ».

Les définitions de lien sont des actions automatisées qui peuvent se produire pendant la transition. Elles servent à connecter les nœuds, mais aussi à définir les attributs qui apparaissent sur le candidat à la release lors de cette transition spécifique. Par exemple, envoyer une notification par e-mail aux utilisateurs affectés à l'action suivante.

La section suivante détaille les différentes sections du document de flux de travail Onshape et toutes les options possibles pour les différents attributs.

Définition du flux de travail JSON

La section Options

La première section du fichier JSON permet aux flux de travail de disposer de paramètres uniques qui régissent les conditions d'une publication. Tous ces paramètres se trouvent sur la page Paramètres Company/Enterprise -→ Gestion des versions. N'oubliez pas que les paramètres définis dans le flux de travail JSON remplacent ceux définis sur la page Gestion des versions.

L'objet « options » suivant définit toutes les paires nom/valeur possibles, cependant, l'une d'entre elles est facultative. Si ce n'est pas le cas, les valeurs définies dans la page Paramètres de gestion des versions sont utilisées par défaut. Par exemple :

"options": {
"revisionSchemeId": "5851740138fa98150a8f953e",
"requireApprover": true,
"requireAllApprovers": true,
"disallowCreatorAsApprover": true,
"requireNote": true,
"autoObsolete": false,
"errorOnFeatureListErrors": true,
"errorOnRolledBack": false,
"errorOnAssemblyErrors": false,
"errorOnDrawingOutOfDate": true,
"errorOnAssemblyRefsOutOfDate": true,
}

The following details each of these options.

revisionSchemeId

Un identifiant unique obtenu à partir de la page Gestion des versions des paramètres Company/Enterprise. Sélectionnez un type de système de révision dans la liste déroulante, copiez l'ID de système de révision suivant et insérez-le dans ce champ dans le JSON.

Onshape propose différents types de systèmes de révision. Il peut s'agir de :

  • Alphabétique
  • Numérique
  • Personnalisé

De nombreuses organisations utiliseront un système numérique dans les workflows de pré-production, puis passeront à un système alpha pour les processus de publication et de modification après l'ingénierie. En cochant cette option, le workflow pourra remplacer les valeurs par défaut définies dans les paramètres de publication et utiliser un système de révision numérique ou alphabétique.

Paramètres des révisions et des références de pièces

Cliquez sur le bouton Copier dans le presse-papiers pour pouvoir utiliser l'ID de système de révision approprié dans votre workflow JSON.

requireApprover

Lorsque la valeur « vrai » est définie, cette option rend obligatoire le champ Approbateur de la boîte de dialogue Candidat à la release. Cette option est directement liée à l'option « Exiger le approbateur dans la boîte de dialogue de release » dans les paramètres de gestion des révisions.

requireAllApprovers

Dans de nombreux workflows, des approbations parallèles peuvent être requises par différents groupes ou personnes au sein de l'organisation. Pour définir cette option sur « vrai », tous les groupes ou personnes nommés comme validateurs doivent approuver le flux de travail avant de pouvoir passer au nœud suivant.

Si le flux de travail est rejeté par un approbateur, il passe immédiatement à l'état Rejeté.

Si cette option est définie sur « faux », il suffit qu'un des groupes ou personnes définis accepte la version pour qu'elle passe au nœud suivant. Dans ce cas, une seule approbation est requise.

Boîte de dialogue Créer un candidat à la release indiquant le nom de la release, les notes de version et les approbateurs requis 

DisallowCreatorAsApprover

Dans de nombreuses organisations, la personne qui initie le processus de release ne peut pas être la personne qui l'approuve également. Lorsqu'elle est définie sur « vrai », cette option applique cette stratégie et empêche un candidat à la release d'être approuvé par son créateur.

requireNote

Lorsque la valeur « vrai » est définie, cette option applique la règle selon laquelle le champ « Note » doit être rempli à chaque étape du flux de travail. Cela signifie que l'initiateur du flux de travail doit entrer une note de publication, et chaque personne qui l'approuve (ou la rejette) doit entrer un commentaire. Le champ Note de publication devient obligatoire dans la boîte de dialogue, comme indiqué dans l'image ci-dessus.

Autoobsolète

Si vous définissez cette option sur « true », les révisions précédentes d'un élément donné deviennent obsolètes immédiatement après la publication d'un nouveau élément. Onshape permet à plusieurs versions d'être actives à la fois, mais certaines organisations n'ont besoin que d'une seule version active d'une pièce, d'un assemblage ou d'un dessin à un moment donné.

Les quatre options suivantes sont liées à des erreurs lors de la publication du document. Pour chacune de ces options, lorsque la condition correspondante est remplie sur un élément à publier, définir l'option sur « vrai » crée une erreur sur l'élément et empêche la soumission du candidat à la release. Si l'option est définie sur faux, il y aura toujours un avertissement sur l'élément, mais la version peut toujours être soumise.

La définition de ces options sur « true » empêchera la soumission du candidat à la release. Ces paramètres remplacent les comportements par défaut définis dans la page Paramètres Company/Enterprise → Gestion des révisions.

errorOnFeatureListErrors

Cette option empêche la publication d'une pièce en cas d'erreurs dans la Liste des fonctions.

errorOnRolledBack

Cette option empêche la publication d'une pièce si la barre de reprise de son atelier de pièces n'est pas à la fin de la Liste des fonctions.

errorOnAssemblageErrors

Cette option empêche la publication d'un assemblage si l'assemblage contient des erreurs.

errorOnDrawingOutOfDate

Cette option empêche la publication d'un dessin s'il n'est pas à jour.

La section Propriétés

Les propriétés sont des attributs qui peuvent être ajoutés à la boîte de dialogue Candidat à la release. Ces attributs peuvent être de types différents, avoir des valeurs par défaut et être rendus obligatoires ou facultatifs.

Voici un exemple de différents attributs définis dans l'objet de propriétés du fichier JSON du flux de travail Onshape.

"properties": [
{
"name": "Compliance Approval",
"propertyId": "comp_app",
"valueType": "USER",
"defaultValue": [
"5e5d30bbc7dcaf1000b61484"
]
},
{
"name": "Observers",
"propertyId": "observers",
"valueType": "USER"
},
{
"name": "Rejection Reason",
"propertyId": "rejres",
"valueType": "STRING"
},
{
"name": "ECR",
"propertyId": "ecr",
"valueType": "STRING",
"defaultValue": ""
},
]

Cette section détaille les différents attributs et leurs valeurs disponibles pour l'objet des propriétés.

name

La valeur de l'attribut Nom peut être n'importe quelle chaîne. Cette propriété s'affiche au-dessus de son champ respectif, dans la boîte de dialogue Candidat à la release, comme illustré ici :

Exemple montrant la valeur de l'attribut de nom dans la boîte de dialogue Candidat à la release 

PropertyId

La valeur PropertyId peut être définie comme une chaîne unique dans le contexte du JSON. Cette valeur est utilisée dans d'autres objets pour définir les attributs qui seront rendus disponibles à chaque stade du workflow.

Il est conseillé de définir un ID de propriété qui vous semble logique pour qu'il puisse être facilement référencé plus tard ; par exemple, rendre l'ID de propriété explicite comme « rejection_reason » ou « Engineering_approver ».

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).

Type de valeur

La valeur de cet attribut définit le type de champ à afficher dans la boîte de dialogue Candidat à la release. Les types de valeurs qui peuvent être utilisés ici sont :

  • UTILISATEUR - Crée un champ dans lequel vous pouvez sélectionner des utilisateurs, des équipes et des rôles. Une valeur par défaut pour ce type de propriété doit être un tableau d'ID utilisateur, d'équipe ou de rôle.
  • STRING - Un champ de texte normal.
  • INT - Valeur entière (nombre entier).
  • DOUBLE - Une valeur décimale.
  • DATE - Fournit un contrôle de sélection de date.
  • ENUM - Fournit un contrôle de Sélection, pré-rempli avec des valeurs définies à partir desquelles l'utilisateur peut en sélectionner une. Une propriété utilisant ce type doit également fournir une liste de valeurs pour le champ. Voici un exemple du format ENUM :
{
"name" : « Disposition du stock : (rebut, retour au fournisseur (RTS), remaniement, utilisation telle qu'elle est) »,
"propertyId": "disposition",
"valueType": "ENUM",
"enumValues": [
{
"value": "Scrap"
},
{
"value": "Return to Supplier (RTS)"
},
{
"value": "Rework"
},
{
"value": "Use As Is"
}
],
"defaultValue": "Use As Is"
},
defaultValue

La valeur DefaultValue fournit une valeur avec laquelle préremplir le champ en cours de définition. La valeur définie ici doit correspondre au type de champ sélectionné dans l'attribut ValueType.

Pour les propriétés de type utilisateur, la valeur par défaut doit être une liste d'ID utilisateur/équipe/rôle, comme indiqué ci-dessous. Pour tous les autres types, il s'agit d'une seule valeur (un nombre ou une chaîne).

“valueType”: “USER”,
"defaultValue": [
"5e5d30bbc7dcaf1000b61484",
"5e5d30bbc7dcaf99634a82219"
]

Les identifiants d'utilisateur et d'équipe se trouvent sur les pages Utilisateurs ou Équipes dans les paramètres Company/Enterprise. Cliquez avec le bouton droit sur l'utilisateur ou l'équipe et sélectionnez l'option « Modifier » dans le menu contextuel, puis utilisez le bouton « Copier dans le presse-papiers » à côté du champ ID pour copier la valeur.

Exemple de boîte de dialogue Modifier l'utilisateur, avec l'option Copier dans le presse-papiers en regard du champ ID utilisateur

La section États

Les états définissent les nœuds réels du flux de travail, ainsi que l'état du package de release au fur et à mesure qu'il progresse dans le processus de release. Lorsqu'un package atteint ces nœuds d'état, l'état défini dans l'attribut « Name » lui est attribué, comme indiqué ici :

Voici un exemple de certains états :

"states": [
{
"name": "IN_PROGRESS",
"displayName": "Create Engineering Release",
"entryActions": [],
"exitActions": []
},
{
"name": "PENDING",
"displayName": "Project Admin Approval ",
"approverSourceProperty": "pr_appr",
"editableProperties": [
"pr_appr"
],
"entryActions": [
{
"name": "markItemsPending"
}
],
"exitActions": []
}
]

name

Cet attribut agit comme un identifiant unique pour le nœud d'état. Il peut s'agir de n'importe quelle chaîne, à condition qu'elle soit unique dans le workflow.

Exemple d'identifiant unique pour le nœud d'état dans la boîte de dialogue Revoir la release 

Nom d'affichage

La valeur d'attribut DisplayName est le nom affiché sur le diagramme de flux de travail. Il peut s'agir de n'importe quelle chaîne qui décrit ce qu'est ce nœud. Selon la complexité du flux de travail, plusieurs états peuvent avoir le même nom d'affichage, même si leurs noms (ID) sont différents.

approverSourceProperty

Cet attribut indique quelles propriétés (le cas échéant) définies dans l'objet Propriétés agiront en tant qu'validateurs pour un état. La valeur de cet attribut doit être le PropertyId d'une propriété de type utilisateur. Les utilisateurs et les équipes de cette propriété sont informés de la progression de la version et doivent approuver la version avant qu'elle ne puisse quitter l'état.

Property State 
{
"name": "Compliance Approval",
"propertyId": "comp_app",
"valueType": "USER"
}
 
{
"name": "PENDING",
"displayName": "Compliance Approval",
"approverSourceProperty": "comp_app"
}
 

NotifierSourceProperty

De même que ApprobationSourceProperty, cet attribut est le PropertyID d'une propriété de type utilisateur et définit qui est notifié (le cas échéant) lorsque le flux de travail atteint cet état. C'est la même chose que les utilisateurs, ou groupes d'utilisateurs, qui pourraient suivre la version mais ne pas nécessairement y participer.

entryActions
et 
exitActions

Le flux de travail Onshape permet d'effectuer certaines actions prédéfinies à certains points du workflow. Ces actions peuvent mettre à jour les métadonnées des éléments ou envoyer des notifications aux pièces prenantes. Les actions d'entrée et de sortie d'état se produisent lorsqu'une version entre ou quitte un état.

Les tâches sont détaillées dans la section Tâches du présent document.

EditableProperties

Cet attribut permet de définir une liste de propriétés qui peuvent être modifiées à ce stade du flux de travail. La valeur de cet attribut doit être une liste de PropertyID des propriétés définies dans le workflow.

Exemple de l'objet Propriétés et de l'objet États avec leurs relations 

RequiredProperties

Cet attribut définit une liste de valeurs d'attribut qui sont obligatoires et doivent être remplies pour que la version puisse quitter cet état. Comme EditableProperties, la valeur de cet attribut est une liste de PropertyIds.

Si un PropertyID est marqué comme obligatoire, il est automatiquement modifié.

RequireditemProperties

Paramètres des propriétés personnalisées, avec l'attribut Taille sélectionné

Cet attribut est une liste d'identifiants de propriétés de métadonnées (à partir de la page « Propriétés personnalisées » des paramètres Company/Enterprise, et non des propriétés de flux de travail) qui doivent être renseignés sur chaque élément du candidat à la release avant de pouvoir passer à autre chose. Pour obtenir l'ID de propriété, double-cliquez sur une propriété sur la page Propriétés personnalisées et utilisez le bouton « Copier dans le presse-papiers » en regard du champ ID. Pour ce faire, vous devez être administrateur de l'entreprise.

Voici un exemple d'objet d'état qui consomme des propriétés personnalisées :

{
"name": "PENDING",
"displayName": "Project Admin Approval ",
"approverSourceProperty": "pr_appr",
"editableProperties": [
"pr_appr"
],
"entryActions": [
{
"name" : "markItemsPending"
}
],
"exitActions": [],
"requiredItemProperties" : [
"5d655b8dbce891151cf7d9d9",
"5d0be2b3374eae12dd6eda1c"
]
}

La section Transitions

Les transitions sont ce qui relie les états ensemble. Ils gèrent les interactions entre les états et ce qui se passe lorsqu'un utilisateur clique sur un bouton comme « Soumettre » ou « Approuver » dans la boîte de dialogue de publication.

Voici un exemple d'objet de transition.

{
"name": "ADVANCE_TO_QA_APPROVAL",
"displayName": "Advance",
"type": "APPROVE",
"uiHint": "success",
"sourceState": "PENDING_OPERATIONS_APPROVAL",
"targetState": "PENDING_QA_APPROVAL",
"actions": [
{
"name": "sendUserNotifications"
},
{
"name": "sendEmailNotifications"
}
]
}

Représenté graphiquement comme :

Représentation graphique de l'État et de la transition

La section suivante détaille les options disponibles dans un objet Transition et montre comment une transition est liée aux états.

name

Il doit s'agir d'un nom descriptif unique qui vous permette d'identifier facilement le but de cet objet de transition sans avoir à regarder d'où il provient et où il se termine. Dans les flux plus complexes, il y aura beaucoup de transitions et encore plus d'états - cela rend un JSON très long et peut-être déroutant. En utilisant des noms descriptifs, vous pouvez simplifier le JSON et aider à éliminer les erreurs.

Nom d'affichage

DisplayName est une valeur affichée sur le diagramme de flux de travail. Comme indiqué ci-dessus, le nom d'affichage de la transition est défini comme « Avance ». Il n'y a pas de règles spécifiques pour cela, sauf que cela devrait être descriptif et représentatif de la transition.

type

Cela définit le type de transition entre les états. Il y a trois types possibles comme suit :

  • SUBMIT
  • APPROVE
  • REJECT

La première transition sera toujours de type SUBMIT, après cela les transitions suivantes doivent être de type APPROVE ou REJECT.

Les détails suivants détaillent chaque option de type :

  • 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.
    • Un Soumettre qui n'est pas une transition initiale n'a pas d'autorisations spéciales.
  • Approuver
    • Marque l'utilisateur comme ayant approuvé un candidat à la release (le jeton devient vert dans la boîte de dialogue de publication).
    • Si les stratégies de la société sont définies sur NÉCESSITE TOUS LES APPROBATEURS, 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é un candidat à la release (le jeton devient rouge dans la boîte de dialogue de publication).
    • Seul un validateur de l'état actuel (ou un administrateur) a la possibilité de rejeter.

UIHint

Cette option définit la couleur du nœud suivant dans l'affichage graphique, ainsi que le bouton correspondant dans la boîte de dialogue Release. Il existe actuellement trois valeurs disponibles pour cet attribut, qui sont des styles d'interface utilisateur Bootstrap :

  • « primary » – bleu
  • « success » — vert
  • « danger » - rouge

sourceState
& 
targetState

L'attribut SourceState est le nom de l'objet d'état à partir duquel cette transition est initiée. L'attribut targetState est le nom de l'objet state auquel il correspond.

La dénomination est très importante pour assurer la cohérence et réduire les erreurs possibles ; pour cette raison, il est fortement conseillé d'utiliser des noms descriptifs pour les objets d'état. Avec des flux de travail plus importants, cela peut rapidement devenir complexe et sujet aux erreurs. Le diagramme suivant montre le mappage entre l'objet d'état et les attributs d'état source et cible.

Exemple d'objet d'état et d'objet de transition, avec leurs relations 

action

Comme les états, les transitions peuvent avoir des actions exécutées en plus de simplement déplacer le candidat à la release vers l'état suivant. Cet attribut définit une liste d'actions de la même manière que les attributs EntryActions et ExitActions sur les états. Les actions d'une transition sont exécutées avant les ExitActions de l'état source et les EntryActions de l'état cible.

La section Tâches

Cette section détaille les actions qui peuvent être affectées aux États et aux transitions. Bien que la plupart de ces actions soient communes aux deux, certaines d'entre elles ont des restrictions à la fois sur la commande et sur l'endroit où elles peuvent être placées.

Les actions sont représentées comme un objet JSON avec un seul attribut : name.

Voici un exemple d'état avec des actions d'entrée ou de sortie :

{
"name": "PENDING_ENGINEERING_APPROVAL",
"DisplayName" : "En attente d'approbation technique",
"approverSourceProperty": "ingénieurs",
"entryActions": [
{
"name": "markItemsPending"
}
],
"exitActions": []
}
Au sein d'une transition, ils peuvent être définis comme suit :
"actions": [
{
"name": "sendUserNotifications"
},
{
"name": "sendEmailNotifications"
}
]

Voici les actions actuellement disponibles :

  • markItemsPending - Modifiez l'état des métadonnées de tous les éléments de la version en « En attente ». Cette action n'est pas autorisée sur les workflows d'obsolescence et ne peut pas être utilisée après les actions MarkItemsRejeted ou ReleaseItems.
  • markItemsRejected - Modifiez l'état des métadonnées de tous les éléments de la version en Rejeté. Cette option n'est pas autorisée sur les workflows d'obsolescence et ne peut pas être utilisée après l'action MarkItemsRejeted ou avant l'action ReleaseItems.
  • 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 ces éléments (obsolétisation automatique des autres révisions si spécifié dans la politique de la société ou dans les options spécifiques du workflow). Cette option n'est pas disponible dans les workflows d’obsolescence.
  • obsoleteItems - Modifiez l'état des métadonnées de tous les éléments du package en obsolètes et obsolètes leurs révisions correspondantes. Cette option n'est pas disponible pour les workflows de version.
  • sendUserNotifications - Envoie un message dans le panneau Notifications Onshape indiquant qu'une transition s'est produite, y compris un lien permettant d'ouvrir le candidat à la release. Cette action n'est autorisée que sur les transitions.
  • sendEmailNotifications -Envoyez une notification par e-mail contenant un lien pour ouvrir le candidat à la release dans Onshape. Cette action n'est autorisée que sur les transitions.

Les deux actions de notification ci-dessus envoient des notifications au créateur du candidat à la release, ainsi qu'aux validateurs et aux notificateurs des états source et cible (le cas échéant), comme spécifié dans ces attributs ApproversSourcePropery et NotifierSourceProperty. Pour les validateurs, les notifications contiendront un appel à l'action pour approuver le candidat à la release.

Conseils et astuces

Le concepteur de flux de travail Onshape peut vous aider

Si vous modifiez le JSON dans Onshape, vous verrez le flux de travail représenté sous la forme d'un graphique avec des nœuds (états) et des arêtes (transitions), mis à jour en temps réel lorsque vous modifiez le JSON. L'éditeur mettra en surbrillance les erreurs de formatage JSON.

Si vous avez un éditeur préféré, vous pouvez modifier le JSON dans ce programme, puis le télécharger dans Onshape. Le concepteur graphique mettra toujours en évidence les erreurs.

Le concepteur de flux de travail Onshape identifie les erreurs de formatage JSON et certains types d'erreurs de construction, comme un ID non valide. Cependant, il ne vous dira pas, par exemple, que vous avez utilisé le mauvais type de transition - c'est pourquoi le test est important !

Utiliser des noms et des identifiants descriptifs

À mesure que le flux de travail devient plus complexe, il sera difficile de suivre les ID que vous avez utilisés pour divers objets, tels que les propriétés. Cela peut devenir particulièrement complexe lors de la connexion d'objets d'état avec les valeurs attributaires SourceState et TargetState des objets de transition.

En utilisant des noms descriptifs et toujours uniques, vous pouvez simplifier le JSON et éliminer de nombreuses erreurs possibles.

Orthographe et majuscules

Dans le JSON, les noms d'objets et les noms d'attributs, ainsi que certaines valeurs, sont codés en dur et sensibles à la casse. Par exemple, l'attribut « SourceState » n'est pas le même que « sourcestate ». Des fautes de frappe comme celle-ci provoqueront l'échec du workflow.

Cette rubrique utilise la syntaxe correcte. Vous devez copier et coller ces mots-clés à partir d'ici ou de l'un des exemples de workflows fournis par Onshape.

Testez votre flux de travail

Avant de l'utiliser en production, exécutez votre workflow sur une pièce de test et assurez-vous qu'il fonctionne. Assurez-vous que les préférences de publication que vous avez utilisées dans votre flux de travail fournissent le comportement attendu.

Les groupes affectés aux différentes étapes du flux de travail acceptent la version.

Création de workflow d'obsolescence

Cette rubrique explique comment créer des processus de release. Le processus de création d'un flux de travail d'obsolescence est le même, mais au lieu d'une action ReleaseItems, il dispose d'une action d'entrée ObsoleteItems sur un objet d'état. Lors de la publication du flux de travail, sélectionnez l'option de bouton radio « Workflow d'obsolescence » au lieu de l'option « Processus de release » dans la boîte de dialogue Publier, comme illustré ci-dessous. Ces flux de travail apparaîtront sous l'onglet « flux de travail d'obsolescence » dans les paramètres de version.

Dans un flux de travail d'obsolescence, vous pouvez marquer un élément pour le republier avec cette syntaxe :

{
"name": "Marquer la révision comme réutilisable",
"propertyId": "os-mark-rereleasable",
"valueType" : "BOOL"
}

Supprimer des flux de travail

Actuellement, même si vous supprimez un document Onshape contenant un document JSON de flux de travail, le flux de travail restera dans la liste des workflows disponibles dans les paramètres de lancement. Vous pouvez décocher le flux de travail afin qu'il ne soit pas disponible pour sélection lors de la création d'un candidat à la release. Bien que cela ne soit pas optimal, il existe une meilleure pratique pour créer des workflows de test, puis les mettre à jour vers une version de release.

Cette méthodologie vous permet d'expérimenter différentes options et workflows avant de publier (éditer) un workflow qui réponde aux besoins de vos organisations.

Cette méthodologie vous permet d'expérimenter différentes options et workflows avant de publier (éditer) un workflow qui réponde aux besoins de vos organisations.