---
sourceDocument: Yokohama ビルドのワークフロー
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/yokohama/build-workflows

 Release :

    - yokohama

ft:locale :

    - ja-JP

ft:publication_title :

    - Yokohama ビルドのワークフロー

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# ValidateUpdateSetDependencies

# ValidateUpdateSetDependencies {#ariaid-title1}

* リリースバージョン: Yokohama
* 
* 更新日 2025年01月30日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：4分

ValidateUpdateSetDependencies バリデーターは、現在のワークフローで呼び出されたすべてのサブフローを識別し、それらのサブフローのいずれかが別の（進行中の）更新セットで編集されているかどうかを判断します。
この警告は、このワークフローとその1つ以上の依存関係が、追加の労力なしに別のインスタンスに同時に展開されないようにアクティブに変更されていることを通知します。

詳細については、「[更新セットを現在のセットとして作成し選択する](https://www.servicenow.com/docs/access?context=create-select-update-set&version=yokohama&pubname=yokohama-application-development&ft:locale=en-US)」を参照してください。

## 検証の要約

* リスク： 親ワークフローが1つの更新セットで編集され、その従属サブフローが別のワークフローで編集されている場合、2つのワークフローは異なるインスタンスに移動されたときに互換性がない場合があります。共通または期待値などの独立した変更を行うと、2つのワークフローが互換性がなくなります。
* 重大度： 警告
* 有効な結果： 有効
* 有効なメッセージ： Update Setの依存関係の問題は見つかりませんでした。
* 無効な結果： 無効
* 無効なメッセージ： このワークフローには、異なる更新セットに属する依存ワークフローがあります。
* 推奨処置： 両方のワークフローを同じ更新セットに変更して展開します。個別の更新セットで依存関係を変更する必要がある場合は、次のいずれかの方法を使用します。
  * すべての更新セットが同時に移行されることを確認します。
  * メインフローアップデートセットをデプロイする前に、そのアップデートセットを完了する前に、依存関係を1つのアップデートセットにマージします。
* パブリッシュ可能： はい
* 実行可能ファイル： はい
* 関連情報: [更新セットを使用したワークフローの移動](https://servicenow-prod.fluidtopics.net/rnY6et3N3JRJpTGBpb1FmA#c_WorkflowMovementWithUpdateSets "ワークフロー情報は複数のテーブルに格納されるため、システムは他のレコードとは異なる方法で更新セットのワークフローを追跡します。")

## トラブルシューティング

ワークフローは、ワークフローが公開されたときにのみ更新セットに追加されます。このバリデータは、次のいずれかの条件が存在する場合に警告を発行します。

* 公開されたサブフローは、親ワークフローとは異なる更新セットにあり、その更新セットは進行中です。
* サブフローは、現在のユーザーとは異なる更新セットで作業している別のユーザーによってチェックアウトされます。

注:  
このバリデーターは、クローズされた更新セットを検索しません。進行中の更新セット、または異なる更新セットで作業しているユーザーにチェックアウトされている現在のワークフローで使用されているすべてのサブフローの更新セットのみを表示します。

## 例

以下は、2人のユーザーが異なる更新セットのワークフロー間で依存関係を作成する、アットリスクの開発シナリオの例です。

ユーザーA：

1. セットAを現在のアップデートセットに設定します。
2. ワークフローAをチェックアウトします。
3. 戻り値を変更します。 文字列ワークフローAをaに入力します。 リファレンス/ユーザータイプ。
4. ワークフローAを発行し、更新セットAにエントリを引き起こします。

ユーザーB：

1. アップデートセットBを現在のアップデートセットに設定します。
2. ワークフローBをチェックアウトします。
3. サブフローとしてワークフローAを含みます。
4. Workflow Aのユーザー参照戻り値を承認割り当てとして使用します。
5. ワークフローBを発行し、Update Set Bにエントリします。

## リスク

* ユーザーBは、ワークフローAの古いバージョンを持つ別のインスタンスに更新セットBを移動します。戻り値は、ワークフローBの結果が開発時にテストされた結果と異なる原因となるユーザー参照ではありません。
* ユーザーBは、ワークフローAのバージョンを持たない新しいインスタンスに更新セットBを移動します。ワークフローBは実行時に検証エラーが発生し、実行できません。ログエントリは、現在のレコードのワークフローログに追加されます。

## 可能な解決策

ソリューション

同じ更新セットを使用して、親ワークフローとすべての従属ワークフローを一緒に新しいインスタンスに移行します。

1. 更新セットを、新しいインスタンスに移行するセットに設定します。
2. 含める必要があるワークフローをチェックアウトして再公開します。このアクションにより、現在の更新セットにエントリが強制的に挿入されます。
3. すべての依存関係の更新セットを完了します。
4. 更新セットをローカルインスタンスに移行するための標準的な手順に従います。

ソリューション 2

更新セット間で依存ワークフローを移動します。

1. 移行するメインワークフローを含む更新セットを特定します。
2. システムアップデートセット\>ローカル更新セット に移動します。
3. メインワークフローへの依存関係を含む更新セットを検索して選択します。
4. 顧客の更新の中に移動するサブフローのワークフローバージョンを選択します。
5. アップデートセットフィールドの中に親ワークフローを含む更新セットを選択します。このフィールドがCustomer Updateフォームにない場合は、フォームを構成してフィールドを追加します。
6. \[更新\] をクリックすると、ベースシステムは従属サブフローを選択された更新セットに移動します。
7. ステップ4-6を繰り返して、従属サブフローを親フロー更新セットに追加します。