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


---

# 更新セットを使用したワークフローの移動

# 更新セットを使用したワークフローの移動 {#ariaid-title1}

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

ワークフロー情報は複数のテーブルに格納されるため、システムは他のレコードとは異なる方法で更新セットのワークフローを追跡します。

ワークフロー バージョンに対する変更は、[ワークフローが公開される](https://servicenow-prod.fluidtopics.net/3CrmzHZvnbZ24pL0hwf2Uw#work-on-workflows "ワークフローを完了するには、ワークフロー アクティビティを追加し、ワークフローを検証して公開します。")まで更新セットに追加されません。その時点で、ワークフロー全体が更新セットに追加されます。更新セットには、ワークフローが単一のワークフロー \[wf_workflow\] レコードとして格納され、ワークフローの更新タイプを持つ最新バージョンのみが保持されます。

更新セット の詳細については、「[システムアップデートセット](https://www.servicenow.com/docs/access?context=system-update-sets&version=yokohama&pubname=yokohama-application-development&ft:locale=en-US)」を参照してください。

## ワークフロー更新セット移行のユースケース - シンプル {#ariaid-title2}

依存関係のない新しいワークフローを作成した後、ワークフローを更新セットで移行します。
1. ユーザー A が更新セット A を選択します。
2. ユーザー A が、ワークフロー A という新しいワークフローを作成します。
3. ユーザー A がワークフロー A を公開します。XML ペイロードを含む更新セット A に顧客更新セット レコードが追加されます。これには、公開されたワークフロー A およびすべてのアクティビティ依存関係が含まれます。XML ペイロードには、ワークフローに関連付けられたワークフロー入力変数も含まれています。

4. ユーザー A が更新セット A を完成させ、本番インスタンスに移行します。
5. 更新セット A が正常にコミットされます。
6. ワークフロー A が正常に動作します。

## ワークフロー更新セット移行のユースケース - サブフロー依存関係 (成功) {#ariaid-title3}

既存のワークフローとその依存関係サブフローを正常に編集して移行します。
1. ユーザー A が更新セット B を選択します。
2. ユーザー A がワークフロー A をチェックアウトします。
3. ユーザー A がワークフロー B と呼ばれるサブフローをワークフロー A に追加します。ワークフロー B はすでに公開され、本番インスタンスに移行されたと仮定します。

4. ユーザー A がワークフロー A を公開します。XML ペイロードを含む更新セット B に顧客更新セット レコードが追加されます。これには、公開されたワークフロー A およびすべてのアクティビティ依存関係が含まれます。XML ペイロードには、ワークフローに関連付けられたワークフロー入力変数も含まれています。

5. ユーザー A が更新セット B を完成させ、本番インスタンスに移行します。
6. 更新セット B が正常にコミットされます。
7. ワークフロー A は、サブフローとしてワークフロー B と正常に連携します。

## ワークフロー更新セット移行のユースケース - サブフロー依存関係 (失敗) {#ariaid-title4}

依存するサブフローがないために本番インスタンスでの実行に失敗する既存のワークフローを編集し、テスト インスタンスから本番インスタンスに移行します。
1. ユーザー A が更新セット C を選択します。
2. ユーザー A がワークフロー A をチェックアウトします。
3. ユーザー A がワークフロー B と呼ばれるサブフローをワークフロー A に追加します。ワークフロー B はすでに公開されているが、本番インスタンスに移行されていないと仮定します。

4. ユーザー A がワークフロー A を公開します。XML ペイロードを含む更新セット C に顧客更新セット レコードが追加されます。これには、公開されたワークフロー A およびすべてのアクティビティ依存関係が含まれます。XML ペイロードには、ワークフローに関連付けられたワークフロー入力変数も含まれています。

   更新セット C に特にないものは、ワークフロー B と呼ばれるサブフローです。ワークフロー B は、ユーザー A が更新セット C を選択する前に公開されました。
5. ユーザー A が更新セット C を完成させ、本番インスタンスに移行します。
6. 更新セット C は警告とともにコミットされます。
7. ワークフロー A が本番インスタンスで呼び出され、次の結果が得られます。ワークフロー A がランタイム検証チェックに失敗し、本番システムで実行できなくなります。システムは、障害の原因 (特に依存するワークフローがないこと) を詳細に示すワークフロー ログをワークフローコンテキストに追加します。

   ワークフローの依存関係と更新セットにおける検証チェックの詳細については、「[ValidateUpdateSetDependencies](https://servicenow-prod.fluidtopics.net/~HrhgEUGpRtRcSX~3ZAb6w "ValidateUpdateSetDependencies バリデーターは、現在のワークフローで呼び出されたすべてのサブフローを識別し、それらのサブフローのいずれかが別の（進行中の）更新セットで編集されているかどうかを判断します。")」を参照してください。

## ワークフロー更新セット移行のユースケース - サブフロー依存関係 (リスク) {#ariaid-title5}

複数のユーザーが、適切な調整を行わずにワークフローをテスト インスタンスから本番インスタンスに移行します。このユースケースは成功する可能性がありますが、各ユーザーが依存関係について理解し、ワークフローの依存部分を新しいインスタンスに適切に移行した場合に限ります。
この例は、更新セットの失敗を表すものではありませんが、このユースケースではほとんどの場合更新セットが原因と見なされます。検証により、複数の更新セットにわたるワークフロー依存関係の可視化が高まり、より適切な情報がデザイナーに提供されます。ほとんどの場合、警告によってアクションが妨げられることはなく、リスクが特定されるだけです。デザイナーには、検証チェックで示されたアドバイスに対してアクションを起こす責任があります。  
1. ユーザー A が更新セット C を選択します。
2. ユーザー A がワークフロー A をチェックアウトします。
3. ユーザー A が、ユーザー ID を返すワークフロー B と呼ばれるサブフローを追加します。  
   注:  
   ワークフロー B はすでに公開され、本番インスタンスに移行されたと仮定します。
4. ユーザー A がワークフロー B の戻り値を使用して承認を生成します。
5. ユーザー B が更新セット D を選択します。
6. ユーザー B がワークフロー B (ワークフロー A のサブフロー) をチェックアウトします。
7. ユーザー B が、ワークフローの戻り値をユーザー ID から文字列メッセージに変更することで変更します。
8. ユーザー A がワークフロー A を公開します。  
   注:  
   ワークフロー A に関連する警告がダイアログ ボックスに表示され、ユーザー A に対して公開前にワークフローの検証が推奨されます。
9. ユーザー A は、ワークフロー A を公開して[検証](https://servicenow-prod.fluidtopics.net/RGVV_sX258uCDspQ8NF_pA "ワークフロー検証では、ワークフローのさまざまな特性を調べて、ワークフローが公開されない、または失敗する可能性のある問題を特定します。検証レポートには、それぞれのワークフロー検証の結果がまとめられています。")します。
10. ユーザー A に対して、異なる更新セットのユーザーによってワークフロー B が変更されたことが警告されます。
11. ユーザー A はこの警告を無視し、ワークフロー A を公開します。  
    注:  
    XML ペイロードを含む更新セット C に顧客更新セット レコードが追加されます。これには、公開されたワークフロー A およびすべてのアクティビティ依存関係が含まれます。XML ペイロードには、ワークフローに関連付けられたワークフロー入力変数も含まれています。
12. ユーザー A が更新セット C を完成させ、本番インスタンスに移行します。
13. ワークフロー A が本番インスタンス上で呼び出され、すでにシステムにある古いバージョンのワークフロー B を使用して正常に実行されます。
14. ユーザー B がワークフロー B を公開します。  
    注:  
    更新セットが進行中ではなくなったため、ユーザー B に対して更新セット C の依存関係が警告されません。ただし、ユーザー B にはワークフロー バージョンに関連する警告を示すダイアログ ボックスが表示され、ワークフロー B を検証するよう指示されます。ユーザー B がワークフローを公開をキャンセルしてワークフローを検証した場合、ワークフロー B をサブフローとして使用するワークフローがあることがユーザー B に対して警告されます。戻り値が変更されたことが分かったら、ユーザー B はそれらのワークフローもテストする必要があります。更新セット警告のパラメータについては、「[ValidateUpdateSetDependencies](https://servicenow-prod.fluidtopics.net/~HrhgEUGpRtRcSX~3ZAb6w "ValidateUpdateSetDependencies バリデーターは、現在のワークフローで呼び出されたすべてのサブフローを識別し、それらのサブフローのいずれかが別の（進行中の）更新セットで編集されているかどうかを判断します。")」を参照してください。
15. ユーザー B が最終的にワークフロー B を公開します。  
    注:  
    XML ペイロードを含む更新セット D に顧客更新セット レコードが追加されます。これには、公開されたワークフロー B およびすべてのアクティビティ依存関係が含まれます。
16. ユーザー B が更新セット D を完成させ、本番インスタンスに移行します。
17. 更新セット D は警告なしでコミットされます。
18. ワークフロー A は本番インスタンスで呼び出され、正常に実行されません。これは、ワークフロー B の戻り値がユーザー ID を生成しなくなるためです。
{#r_MigrationUseCsSbflwDpdRsk__ul_xcw_dbz_gr}