Onshape には、すぐに使い始めることができる一般的なリリース管理ワークフローが用意されています。このプロセスは、一般的なリリースワークフローで説明されています。Onshape では、この一般的なワークフローに加えて、独自のカスタムリリース管理ワークフローを設計および作成し、組織全体で使用できるようにそのワークフローを公開できます。組織内の特定のリリース管理のニーズに対応するために、複数のワークフローを作成することもできます。

この機能にアクセスするには、Onshape Enterprise の管理者ロールが割り当てられている必要があります。

Onshape には、リリース管理の動作を制御する多くのオプションが用意されています。ビジネスプロセスに応じて、これらの設定は、リリースの動作方法、リリースの条件、使用できるリビジョンスキームなどの既定のルールとして定義できます。これらのオプションは、Onshape サブスクリプションの [Company/Enterprise 設定] の [リリース管理] ページから設定できます。

多くの場合、複数のリリースプロセスが組織内に実装されている場合、さまざまなプロセスで異なるリリース設定が必要になる場合があります。[リリース管理設定] ページで定義された既定の設定は、カスタマイズしたリリースプロセスを実装することで、リリースプロセスごとにオーバーライドできます。このプロセスは、プロセスごとに既定を上書きすることもできます。

独自のカスタムリリース管理ワークフローを作成するプロセスと、Onshape で実装する方法について詳しく説明します。

カスタムワークフローの作成に含まれている内容

基本的に、Onshape は JSON ファイルを使用して、リリースワークフローと廃止ワークフローの両方のワークフローのレイアウトと動作を定義します。

  1. 基本的な Onshape JSON ファイルをダウンロードする
  2. このトピックで提供されている JSON 構文に従ってファイルをカスタマイズします。
  3. カスタマイズした JSON ファイルを Onshape ドキュメントにアップロードし直す
  4. カスタマイズしたワークフローを組織に公開する

これらの手順については、以下で詳しく説明します。

JSON ファイルをダウンロードする

基本的な JSON は、組織の Onshape ドメイン内で見つけることができます。

  1. Onshape アカウントにサインインします。
  2. [Company/Enterprise 設定] > [リリース管理] ページに移動します。
  3. [ワークフロー] 見出しで、作成するワークフローのタイプ、リリースワークフローまたは廃止ワークフローを選択します。
  4. ドロップダウンで [Onshape の既定...] を選択します。
  5. ドロップダウンの横にある [ドキュメントで表示] リンクをクリックします。

管理対象ワークフローの設定と有効化のワークフローの例

JSON ファイル形式はテキスト形式であるため、理解はしやすいものの、ワークフローがより複雑になるにつれて、非常に複雑になる場合があります。Onshape は、構文やドキュメントの形式にある間違いをいくつかの通知しますが、すべてを確実に通知するわけではないので、正規であるにもかかわらず、多くのオプションでワークフローが失敗する場合があります。

複数の Onshape ワークフローを設定して使用する方法の詳細については、カスタマイズリリースワークフローの作成のトピックを参照してください。

組織のニーズに合わせて JSON をカスタマイズする

まず、JSON が何であるかを理解しましょう。JSON は、JavaScript オブジェクト記法の略です。これは、データを格納および転送するための軽量形式です。JSON は、多くの場合、サーバーと Web ページとの間でデータを送信するために使用されます。JSON 形式は「自己記述」であり、理解しやすいです。

JSON は 2 つの構造体上に構築されています。

  • 名前と値のペアのコレクション。さまざまな言語では、これはオブジェクト、レコード、構造体、辞書、ハッシュテーブル、キー付きリスト、または関連付けられた配列として具体化されます。
  • 値の順序付きリスト。ほとんどの言語では、これは配列、ベクトル、リスト、またはシーケンスとして具体化されます。

これらは普遍的なデータ構造です。事実上すべての現代のプログラミング言語は、それらを 1 つの形式でサポートしています。プログラミング言語と交換可能なデータ形式も、これらの構造に基づいていることは理にかなっています。

JSON では、構造は次の形式をとります。

オブジェクトは、名前と値のペアの順序のないセットです。オブジェクトは左中括弧 { で始まり、右中括弧 } で終わります。各名前の後にコロン : が続きます。名前と値のペアは、カンマ , で区切られます。

以下に、Onshape ワークフロー JSON に表示される内容を示します。この例では、従業員オブジェクトを定義します: 3 つの従業員レコード (オブジェクト) の配列:

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

Onshape JSON 形式

Onshape では、JSON ファイルには 4 つのオブジェクトがあります。

  • オプション - リリース設定の定義
  • プロパティ - 属性定義の設定
  • 状態 - 制御ノードの定義
  • Transitions - リンク定義の指定

リリース設定は、ドキュメントのリリースの動作に関連する 10 個の可能な設定のグループです。これらの設定はすべて、[Company/Enterprise 設定] の [リリース管理] ページにあります。ただし、JSON ワークフローファイルの定義は、Company/Enterprise 設定で定義された対応するリリース管理設定よりも優先されます。

属性定義は、[リリース候補] ダイアログに表示される属性です。これらの属性は、ワークフロー内の 1 つまたは複数のノードに割り当てることができます。また、必須またはオプションのタイプも異なり、「パーツ番号」などの既定値を含めることができます。

ノード定義は、ワークフローに含まれるノードのタイプと、ノードに割り当てられる属性を定義します。たとえば、“Pending” や “Released” などです。

リンク定義は、移行中に発生する可能性のある自動化されたアクションです。ノード同士を接続するだけでなく、この特定のトランジションでリリース候補に表示される属性も定義します。たとえば、次のアクションに割り当てられたユーザーにメール通知を送信する場合などです。

次のセクションでは、Onshape ワークフロードキュメントのさまざまなセクションと、さまざまな属性に対して可能なすべてのオプションについて説明します。

ワークフロー JSON の定義

Options セクション

JSON ファイルの最初のセクションでは、ワークフローにリリースの条件を管理する固有の設定を使用できます。これらの設定はすべて [Company/Enterprise 設定] > [リリース管理] ページにあります。JSON ワークフローで定義されている設定は、[リリース管理] ページで定義された設定よりも優先されます。

次の “options” オブジェクトは、すべての可能な名前と値のペアを定義しますが、これらのいずれかがオプションです。定義されていない場合は、[リリース管理設定] ページで定義された値が既定で使用されます。例:

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

次に、これらの各オプションの詳細を示します。

revisionSchemeId

[Company/Enterprise 設定] の [リリース管理] ページで取得した一意の ID。ドロップダウンでリビジョンスキームタイプを選択し、後続のリビジョンスキーム ID をコピーして、JSON のこのフィールドに挿入します。

Onshape は、さまざまな種類のリビジョンスキームを用意しています。次のような内容があります。

  • アルファベット順
  • 数値
  • カスタム

多くの組織では、運用前のワークフローで数値スキームを使用し、設計後のリリースおよび変更プロセスで Alpha ベースのスキームに移行します。このオプションをオンにすると、ワークフローは [リリース] 設定で定義された既定をオーバーライドし、数値または Alpha ベースのリビジョンスキームを使用します。

リビジョンとパーツ番号の設定

[クリップボードにコピー] ボタンをクリックして、JSON ワークフローで適切なリビジョンスキーム ID を使用できます。

requireApprover

このオプションを “true” に設定すると、[リリース候補] ダイアログの [承認者] フィールドが必須になります。このオプションは、[リリース管理] 設定の [リリースダイアログで承認者を要求] オプションに直接関係します。

requireAllApprovers

多くのワークフローでは、組織内の異なるグループやユーザーによって並行承認が必要になる場合があります。このオプションを “true” に設定すると、ワークフローを次のノードに移動する前に、承認者として指定されたすべてのグループまたはユーザーがワークフローを承認する必要があります。

承認者によってワークフローが拒否された場合、そのワークフローはすぐに [拒否] 状態に移行します。

このオプションを “false” に設定した場合、定義された 1 つのグループやユーザーがリリースを受け入れるだけで、次のノードに移動します。この場合、必要な承認は 1 つだけです。

リリース名、リリースノート、承認者が必要であることを示す [リリース候補を作成] ダイアログ 

disallowCreatorAsApprover

多くの組織では、リリースプロセスを開始する担当者は承認者になることはできません。このオプションを “true” に設定すると、このポリシーが適用され、リリース候補の作成者によってリリース候補が承認されません。

requireNote

このオプションを “true” に設定すると、ワークフローのすべての段階で [注記] フィールドへの入力が必須になるというポリシーが適用されます。つまり、ワークフローの開始者はリリースノートを入力し、ワークフローを承認 (または拒否) する各担当者はコメントを入力する必要があります。上の図に示すように、ダイアログの [リリースノート] フィールドは必須になります。

autoObsolete

このオプションを “true” に設定すると、指定されたアイテムの以前のリビジョンは新しいものをリリースするとすぐに廃止されます。Onshape では、一度に複数のリリースをアクティブにできますが、組織によっては、指定された時点でパーツ、アセンブリ、または図面のリリースを 1 つだけアクティブにすることが必要な場合があります。

次の 4 つのオプションは、リリースされるドキュメントのエラーに関連しています。これらの各オプションについて、リリースアイテムで対応する条件が満たされたときに、このオプションを “true” に設定すると、アイテムにエラーが生成され、リリース候補が送信されなくなります。オプションを “false” に設定すると、アイテムには警告が表示されますが、リリースは送信できます。

これらのオプションを “true” に設定すると、リリース候補が送信されなくなります。これらの設定は、[Company/Enterprise 設定] > [リリース管理] ページで定義された既定の動作を上書きします。

errorOnFeatureListErrors

このオプションを使用すると、フィーチャーリストにエラーがある場合に、パーツのリリースが防止されます。

errorOnRolledBack

このオプションを使用すると、Part Studio のロールバックバーがフィーチャーリストの最後にない場合に、パーツのリリースが防止されます。

errorOnAssemblyErrors

このオプションは、アセンブリにエラーが含まれている場合に、アセンブリのリリースを防止します。

errorOnDrawingOutOfDate

このオプションを使用すると、図面が最新でない場合に図面がリリースされるのを防ぐことができます。

Properties セクション

プロパティは、[リリース候補] ダイアログに追加できる属性です。これらの属性には異なるタイプがあり、また既定値があって、必須またはオプションにすることができます。

Onshape ワークフロー JSON ファイルのプロパティオブジェクトで定義されているさまざまな属性の例を次に示します。

"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": ""
},
]

このセクションでは、プロパティオブジェクトで使用できるさまざまな属性とその値について詳しく説明します。

name

名前属性の値には任意の文字列を指定できます。このプロパティは次に示すように、[リリース候補] ダイアログの各フィールドの上に表示されます。

[リリース候補] ダイアログの名前属性の値を示す例 

propertyId

propertyId 値は、JSON のコンテキスト内の一意の文字列として定義できます。この値は、ワークフローのどのステージでどの属性が使用可能かを定義するために、他のオブジェクトで使用されます。

後で簡単に参照できるように、意味がわかりやすいプロパティ ID を定義することをお勧めします。たとえば、プロパティ ID を “rejection_reason” や “Engineering_approver” のように自明な名称にします。

プロパティ ID は一意である必要があります (Onshape のハードコードされた Name、Description、Comment プロパティの ID とは重複できません)。

valueType

この属性の値は、[リリース候補] ダイアログに表示するフィールドのタイプを定義します。ここで使用できる値の種類は次のとおりです。

  • USER - ユーザー、チーム、ロールを選択できるフィールドを作成します。このタイプのプロパティの既定値は、ユーザー、チーム、ロール ID の配列である必要があります。
  • STRING - 通常のテキストフィールド。
  • INT - 整数値 (整数)。
  • DOUBLE - 10 進数値。
  • DATE - 日付選択コントロールを提供します。
  • ENUM - ユーザーが選択できる定義済みの値が事前に入力された選択コントロールを提供します。このタイプを使用するプロパティは、フィールドの値のリストも提供する必要があります。ENUM 形式の例を次に示します。
{
"name": "Inventory Disposition: (Scrap, Return to Supplier (RTS), Rework, Use As Is)",
"propertyId": "disposition",
"valueType": "ENUM",
"enumValues": [
{
"value": "Scrap"
},
{
"value": "Return to Supplier (RTS)"
},
{
"value": "Rework"
},
{
"value": "Use As Is"
}
],
"defaultValue": "Use As Is"
},
defaultValue

defaultValue には、定義されているフィールドを事前に入力するための値が提供されます。ここで定義する値は、valueType 属性で選択したフィールドの種類と一致する必要があります。

USER-type のプロパティの場合、既定値は、次に示すように、user/team/role ID のリストである必要があります。他のすべてのタイプでは、単一の値 (数値または文字列) です。

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

ユーザー ID とチーム ID は、[Company/Enterprise 設定] の [ユーザー] または [チーム] ページにあります。ユーザーまたはチームを右クリックし、コンテキストメニューから [編集] オプションを選択し、[ID] フィールドの横にある [クリップボードにコピー] ボタンを使用して値をコピーします。

[ユーザー ID] フィールドの横に [クリップボードにコピー] オプションがある [ユーザーを編集] ダイアログの例

States セクション

States は、ワークフロー内の実際のノード (リリースプロセスに関与するパーツ、アセンブリ、または図面の状態) を定義します。これらの状態ノードに到達すると、次に示すように、[名前] 属性に定義された状態が割り当てられます。

以下は、いくつかの状態の例です。

"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

この属性は、状態ノードの一意の識別子として機能します。ワークフロー内で一意である限り、任意の文字列を指定できます。

[リリースをレビュー] ダイアログの状態ノードの一意の識別子の例 

displayName

displayName 属性値は、ワークフロー図に表示される名前です。そのノードが何であるかを説明する任意の文字列を指定できます。ワークフローの複雑さによっては、名前 (ID) が異なる場合でも、複数の状態が同じ表示名になることがあります。

approverSourceProperty

この属性は、プロパティオブジェクトで定義されているプロパティのうち、状態の承認者として機能するプロパティ (存在する場合) を示します。この属性の値は、ユーザータイププロパティの propertyId である必要があります。そのプロパティのユーザーとチームには、リリースの進捗が通知され、状態から移行する前に、リリースを承認する必要があります。

プロパティ 状態 
{
"name": "Compliance Approval",
"propertyId": "comp_app",
"valueType": "USER"
}
 
{
"name": "PENDING",
"displayName": "Compliance Approval",
"approverSourceProperty": "comp_app"
}
 

notifierSourceProperty

approverSourceProperty と同様に、この属性はユーザータイププロパティの propertyId であり、ワークフローがこの状態に達したときに誰に通知されるか (存在する場合) を定義します。これは、リリースをフォローしている可能性があるが、必ずしもそれに参加しているとは限らないユーザー、またはユーザーのグループと同じです。

entryActions
と 
exitActions

Onshape ワークフローでは、ワークフローの特定のポイントで、定義済みのアクションをいくつか実行できます。これらのアクションは、アイテムのメタデータを更新したり、関係者に通知を送信することがあります。状態のエントリおよび終了アクションは、リリースがエントリの状態になるか状態を終了したときに発生します。

アクションの詳細については、このドキュメントの Actions セクションを参照してください。

editableProperties

この属性により、ワークフローのこの段階で編集できるプロパティのリストを定義できます。この属性の値は、ワークフローで定義されたプロパティの propertyId のリストである必要があります。

プロパティオブジェクトと状態オブジェクトの関係性の例 

requiredProperties

この属性は、必須の属性値のリストを定義します。この値はリリースがこの状態を終了する前に入力する必要があります。editableProperties と同様に、この属性の値は propertyId のリストです。

propertyId が必須とマークされている場合、自動的に編集可能になります。

requiredItemProperties

サイズ属性が選択されたカスタムプロパティ設定

この属性は、ワークフロープロパティではなく、[Company/Enterprise 設定] の [カスタムプロパティ] ページからのメタデータプロパティ ID のリストです。これらのプロパティは、リリース候補の各アイテムに移動する前に入力する必要があります。プロパティ ID を取得するには、[カスタムプロパティ] ページでプロパティをダブルクリックし、[ID] フィールドの横にある [クリップボードにコピー] ボタンを使用します。これを行うには、Company の管理者である必要があります。

カスタムプロパティを使用する状態オブジェクトの例を次に示します。

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

Transitions セクション

Transitions は、状態を結びつけるものです。これらは、状態間の相互作用と、ユーザーがリリースダイアログの「送信」や「承認」などのボタンをクリックしたときに起こることを処理します。

次に、トランジションオブジェクトの例を示します。

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

グラフィカル表現は次のようになります。

State と Transition のグラフィカル表現

次に、Transition オブジェクト内で使用可能なオプションの詳細と、トランジションが状態とどのように関連しているかを示します。

name

これは、Transition オブジェクトの起点と終了位置を確認することなく、この Transition オブジェクトの目的を簡単に識別できる一意の説明的な名前にする必要があります。より複雑なフローでは、多くの Transition とさらに多くの状態があります。これは非常に長く、おそらく混乱を招く JSON になります。わかりやすい名前を使用することで、JSON を簡略化し、エラーを排除できます。

displayName

displayName は、ワークフロー図に表示される値です。上記のように、トランジション表示名は「Advance」と定義されています。トランジションを説明し代表するものでなければならないことを除いて、これに関する特定の規則はありません。

タイプ

これは、状態間のトランジションのタイプを定義します。次の 3 つのタイプがあります。

  • SUBMIT
  • APPROVE
  • REJECT

常に、最初のトランジションは送信タイプの 1 つになり、後続のトランジションのタイプは承認または拒否になります。

次に、各タイプオプションを詳しく説明します。

  • Submit
    • リリースで構成されたパーツのサムネイル生成の開始、リンクされたドキュメント ID やバージョン ID の接続など、セットアップからワークフローに移行する場合に、リリースでさまざまな「初期化」を実行します。
    • SUBMIT トランジションを実行できるのは、リリース作成者だけです。
    • 初期状態からのトランジションは、Submits にする必要があります。
    • 初期トランジションでない Submit には特別な機能はありません。
  • Approve
    • リリース候補を承認したとしてユーザーをマークします (リリースダイアログでトークンが緑に変わります)。
    • Company のポリシーが [すべての承認者からの承認が必要] に設定されている場合、すべての承認者が承認するまでトランジションは実行されません。
    • アイテムのアセンブリコンテンツまたは図面コンテンツ参照を生成します。
    • この種類のトランジションは 1 つの状態から許可されます。
    • 承認できるのは、現在の状態の承認者 (または管理者) だけです。
  • 拒否
    • リリース候補を拒否したとしてユーザーをマークします (リリースダイアログでトークンが赤に変わります)。
    • 拒否できるのは、現在の状態の承認者 (または管理者) だけです。

uiHint

これにより、グラフィカル表現の次のノードの色と、[リリース] ダイアログの対応するボタンが定義されます。現在、この属性には次の 3 つの値があり、これらはブートストラップの UI スタイルです。

  • “primary” – blue
  • “success” – green
  • “danger” - red

sourceState
と 
targetState

sourceState 属性は、このトランジションが開始される状態オブジェクトの名前です。targetState 属性は、対象の状態オブジェクトの名前です。

一貫性を提供し、発生する可能性のあるエラーを減らすために、命名は非常に重要です。このため、状態オブジェクトにはわかりやすい名前を使用することをお勧めします。大規模なワークフローでは、これはすぐに複雑になり、エラーが発生しやすくなります。次の図は、状態オブジェクトとソースおよびターゲットの状態属性間のマッピングを示しています。

State オブジェクトと Transition オブジェクトの関係性の例 

actions

状態と同様に、トランジションには、リリース候補を次の状態に移動するだけでなく、アクションを実行することもできます。この属性は、状態の entryActions 属性と exitActions 属性と同じ方法でアクションのリストを定義します。トランジションのアクションは、ソース状態の exitActions とターゲット状態の entryActions の前に実行されます。

Actions セクション

このセクションでは、状態とトランジションに割り当てることができるアクションについて詳しく説明します。これらのアクションのほとんどは両方に共通ですが、その中には、順序付けと配置場所の両方に制限があります。

アクションは、「name」という単一の属性を持つ JSON オブジェクトとして表されます。

以下に、エントリアクションまたは終了アクションがある状態の例を示します。

{
"name": "PENDING_ENGINEERING_APPROVAL",
"displayName": "Pending engineering approval",
"approverSourceProperty": "engineers",
"entryActions": [
{
"name": "markItemsPending"
}
],
"exitActions": []
}
トランジション内では、次のように定義できます。
"actions": [
{
"name": "sendUserNotifications"
},
{
"name": "sendEmailNotifications"
}
]

現在利用可能なアクションは次のとおりです。

  • markItemsPending - リリース内のすべてのアイテムのメタデータの状態を [保留中] に変更します。このオプションは、廃止ワークフローで使用することは許可されておらず、markItemsRejected アクション後または releaseItems アクション後には使用できません。
  • markItemsRejected1 - リリース内のすべてのアイテムのメタデータの状態を Released に変更します。このオプションは、廃止ワークフローで使用することは許可されておらず、markItemsRejected アクション後または releaseItems アクション前には使用できません。
  • releaseItems - リリース内のすべてのアイテムのメタデータの状態を Released に変更し、それらのリビジョンを作成します (Company ポリシーまたはワークフローの特別なオプションで指定されている場合、他のリビジョンは自動的に廃止されます)。このオプションは廃止ワークフローには使用できません。
  • obsoleteItems - パッケージ内のすべてのアイテムのメタデータの状態を Obsolete に変更し、対応するリビジョンを廃止します。このオプションはリリースワークフローには使用できません。
  • sendUserNotifications - リリース候補を開くためのリンクを含む、トランジションが発生したことを示すメッセージを Onshape 通知パネルに送信します。このアクションは、トランジションでのみ許可されます。
  • sendEmailNotifications - Onshape でリリース候補を開くためのリンクを含むメール通知を送信します。このアクションは、トランジションでのみ許可されます。

上記の通知アクションはどちらも、リリース候補の作成者、ソース状態とターゲット状態 (存在する場合) の承認者および通知者 (存在する場合) に通知を送信します。これらの状態の approverSourceProperty 属性と notifierSourceProperty 属性で指定されています。承認者の場合、通知には、リリース候補を承認するためのアクションの呼び出しが含まれます。

ヒントとコツ

Onshape ワークフローデザイナーは

Onshape で JSON を編集すると、ノード (states) とエッジ (transitions) を含むグラフとしてワークフローが表示され、JSON を変更するとリアルタイムで更新されます。エディタには、JSON 形式エラーが強調表示されます。

使いたいエディタがある場合は、そのプログラムで JSON を編集し、Onshape にアップロードできます。グラフィカルデザイナーにはエラーが強調表示されます。

Onshape ワークフローデザイナーは、JSON 形式エラーや特定のタイプの構築ミス (無効な ID など) をキャッチします。ただし一例として、間違ったトランジションタイプを使用したことはわかりません。そのため、テストが重要となります！

わかりやすい名前と ID を使用する

ワークフローが複雑になるにつれて、さまざまなオブジェクト (プロパティなど) に使用した ID を追跡することは困難になります。これは、状態オブジェクトをトランジションオブジェクトの sourceState および targetState 属性値に接続すると、特に複雑になる可能性があります。

説明的で常に一意の名前を使用することで、JSON を簡素化し、発生する可能性のある多くのエラーを排除できます。

スペルと大文字と小文字の問題

JSON では、オブジェクト名と属性名、および一部の値はハードコードされ、大文字と小文字が区別されます。たとえば、属性「sourceState」は「sourcestate」と同じではありません。このようなタイプミスは、ワークフローの失敗の原因となります。

このトピックでは全体を通して正しい構文を使用しています。ここから、または Onshape で提供されているワークフローの例の 1 つから、これらのキーワードをコピーして貼り付ける必要があります。

ワークフローをテストする

実稼働環境で使用する前に、テストパーツでワークフローを実行し、それが動作することを確認してください。ワークフローで使用したリリース設定で、期待される動作が提供されていることを確認します。

ワークフローのさまざまなステージに割り当てられたグループに、リリースを承諾させます。

廃止ワークフローの作成

このトピックでは、リリースワークフローの作成方法について説明します。廃止ワークフローを作成するプロセスは同じですが、[releaseItems] アクションはありません。代わりに、状態オブジェクトに対して [ObsoleteItems] エントリアクションがあります。ワークフローを公開するときは、[パブリッシュ] ダイアログの [ワークフローのリリース] オプションではなく、[廃止ワークフロー] ラジオボタンオプションを選択します。これらのワークフローは、リリース設定の [廃止ワークフロー] タブに表示されます。

廃止ワークフロー内で、次の構文を使用して、アイテムを再リリースするようにマークできます。

{
"name": "Mark revision as re-releasable",
"propertyId": "os-mark-rereleasable",
"valueType": "BOOL"
}

ワークフローの削除

現時点では、ワークフロー JSON ドキュメントを含む Onshape ドキュメントを削除しても、ワークフローは [リリース] 設定で使用可能なワークフローのリストに残ります。ワークフローのチェックを外して、リリース候補の作成時に選択できないようにすることができます。これは最適ではありませんが、テストワークフローを作成し、リリースバージョンに更新するためのベストプラクティスがあります。

ワークフロー JSON ファイルを含むドキュメントは、すべての Onshape ドキュメントとまったく同じように動作します。つまり、ドキュメントはワークスペース (通常はメイン) にいる間のみ編集できます。ワークフロードキュメントをワークスペースから公開すると、ドキュメントのバージョンが作成されます。公開時に、既存のワークフローを上書きできます。

この方法を使用すると、組織のニーズを満たすワークフローを公開 (リリース) する前に、さまざまなオプションとワークフローを試すことができます。