--- 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) 所要時間：16分 ワークフロースタジオが Now Platform の中でフローやアクションをアクティブ化し、トリガーし、処理する仕組みについて理解します。 フローは「トリガー」と 1 つ以上のアクションで構成されます。トリガーは、いつフローを開始するかを指定するもので、レコードベース、スケジュールベース、またはアプリケーションベースになります。レコードベースのトリガーは、レコードが作成、更新、または削除された後にフローを実行します。フローではアクションの入力として、トリガーとなるレコードを使用できます。スケジュールベースのトリガーは、指定した日時にフローを実行します。フローではアクションの入力として、実行日時を使用できます。アプリケーション トリガーは、関連するアプリケーションが有効になったときに追加されます。たとえば、メトリックベース トリガーは、メトリックベース アプリケーションが有効のときに出現します。 ## フローの処理 {#flow-designer-arch-overview__section_kdb_s1s_sbb} フローの処理は次のシーケンスで行われます。 1. フローのトリガー条件が発生した場合、または API がフローを直接呼び出した場合、システムはイベントキューにエントリーを作成してフローを開始します。 2. スケジューラーはイベントを処理し、バックグラウンドでフローを開始します。 3. システムは、フローからプロセス計画を作成します。 4. システムは、フローをトリガーしたレコードを使用してプロセス計画を実行します。 5. システムは、実行の詳細をコンテキスト レコードに格納します。 {#flow-designer-arch-overview__ol_bn5_q22_dcb} 1. フロートリガーおよび API 呼び出しを処理する : トリガー条件が満たされた場合、または API がフローを直接呼び出した場合、そのたびに ワークフロースタジオ によってイベントエントリーが作成されます。システムは、データベースの操作後にトリガーを処理します。詳細については、「[スクリプトとエンジンの実行順序](https://www.servicenow.com/docs/access?context=r_ExecutionOrderScriptsAndEngines&version=yokohama&pubname=yokohama-api-reference&ft:locale=en-US)」を参照してください。通常、同時に実行される[ビジネスルールの仕組み](https://www.servicenow.com/docs/access?context=c_BusinessRules&version=yokohama&pubname=yokohama-api-reference§ion=r_HowBusinessRulesWork&ft:locale=en-US)と[ワークフローエンジンの操作順序](https://servicenow-prod.fluidtopics.net/6ZtUiMDWMvEu5KbRj3Nl1Q#c_WorkflowEngineOperationOrder "ワークフローエンジンは、ビジネスルールおよびデータベース操作に関連して事前定義された順序で実行されます。一般的な公開ワークフローをキャッシュしてパフォーマンスを向上させます。")は、トリガーされるフローの前に実行されます。 2. キュー内のイベントを処理する : フロー イベントにはそれぞれ、開始するフローへの参照と、トリガーとなるレコードか実行時間のいずれかへの参照が含まれています。システムは、[イベント](https://servicenow-prod.fluidtopics.net/APaGqFbSdHG4ohhR78tfEg "イベントは、特定の条件が発生したときにシステムがログに記録し、その条件に応じて何らかのアクションを実行するために使用する特別なレコードです。")を使用してこれらのイベントを処理します。この処理では、スケジューラーがイベントキュー内の現在のアイテムを、追加された順に定期的に処理します。キュー内の他のイベントによっては、システムがすぐにフローを開始しない場合があります。フロー設計者は、トリガー条件が発生してから実際にフローが開始されるまでの間に、ある程度の遅れ時間が生じることを想定する必要があります。 3. プロセス計画を作成する : ワークフロースタジオがキューからイベントを取り出すと、「プロセス計画」を作成して、実際にフローを実行します。プロセス計画には、フローの実行に必要なすべての情報が含まれています。たとえば、一連の公開されたアクションまたはサブフロー、各サブフローまたはアクションの入力値、各アクションに対して実行するアクション ステップ、トリガーまたはサブフローの出力から提供されるデータなどが含まれています。 ワークフロースタジオ では、フロー、サブフロー、アクションに対する最新の変更がプロセス計画に含まれるように、ジャストインタイムのコンパイル方式が採用されています。変更が検出されない場合、ワークフロースタジオは、プロセス計画のキャッシュされたコピーを使用します。それ以外の場合は、新しいプロセス計画を作成します。 更新されたフロー、サブフロー、およびアクションをプロセス計画で自動的にチェックすることにより、ワークフロースタジオでは、現在のフローを編集しなくても更新セットやアップグレードからの変更を適用することができます。公開されたアクションをターゲット インスタンスに移動すると、公開されたアクションを使用するすべてのフローが次回の実行時に自動的に更新されます。 警告: アクティブになったフローで使用されるサブフローやアクションを変更する場合は、サブフローやアクションで使用する入力と出力を変更しないでください。入力と出力を変更した場合、新しい入力と出力を使用するように設定されていないため、アクティブになったフローが次回トリガーされたときにエラーが発生することがあります。現在実行中のフローはすべて、プロセス計画から得られたコンパイル済みのサブフローやアクションを使用するため、入力または出力の変更の影響を受けることはありません。 4. プロセス計画を実行する : ワークフロースタジオは、フローのプロパティで指定されたユーザーとしてプロセス計画を実行し、それをフローアプリケーションのスコープ内で実行します。 レコードベースのトリガーを使用してフローを実行する場合、ワークフロースタジオは、トリガーレコードを「インスタンス」としてメモリに格納します。これはインターフェイスでは「データ ピル」として表現されます。 フローにアクションを追加するたびに、アクションの結果を保存するデータピルがフローデザイナーによって追加されます。データ ピルの名前は、フロー内のシーケンスとそのデータ タイプを示します。フロー設計者は、アクション結果データ ピルを使用して、他のフロー、アクション、またはサブフローの入力を提供します。フロー設計者は、データ ピル名のシーケンス値を使用することで、正しいデータ ピルを入力値として確実に選択できます。フローでアクションが実行されると、データピルのランタイム値が使用時に生成されます。 5. フロー実行の詳細を格納する : ワークフロースタジオは、フロー実行の詳細を「フロー コンテキスト レコード」に格納します。これには次の情報が含まれています。 * フローの結果の状態 * フローの実行時間 * フローのログ メッセージ * フローの設定とランタイム値 {#flow-designer-arch-overview__ul_pvz_mzb_ccb} フローが実行されるたびに、ワークフロースタジオによって \[フロー実行\] リストにエントリーが追加されます。各エントリーには、独自のコンテキスト レコードと、一致する実行の詳細ページがあります。 注: フロー実行コンテキストはシングルスレッドで実行されます。 ただし、インスタンスのリソースをより多く消費する場合でも、別々のコンテキスト内でフローを実行することがあります。同じフロー内の別々のフローコンテキストでサブフローを実行するには「[動的フロー](https://servicenow-prod.fluidtopics.net/KAHx2BAhw4LbWJqTU~K1Xw "ランタイムデータを使用して、フローまたはサブフローを動的に識別して実行します。動的に呼び出されるフローまたはサブフローに必要な入力を提供するテンプレートをビルドします。")」を参照してください。 フローの結果状況は次のうちの 1 つになります。 {#flow-designer-arch-overview__table_edg_fbc_ccb__entry__2} | 状況 | 説明 | |-|-| | 完了 | フローは正常に完了しました。 | | 進行中 | フローは実行中です。デフォルトでは、トランザクション クォータ ルールによりフローの実行時間が 1 時間より長くなることはありません。 | | 待機中 | フローは他のイベントが発生するのを待っています。たとえば、ユーザーがタスクまたは承認を更新する必要があります。または、レコードが特定のステータスに到達する必要があります。待機中の状態になると、フローは休止中になり、コンテキスト レコードにシリアル化されます。 | | キャンセル | フローはユーザーによってキャンセルされました。 | | エラー | フローにエラーが発生し、実行が停止しました。たとえば、アクションの入力値がない、トランザクション クォータ ルールによりフローが停止された、などです。 | [ ] {#flow-designer-arch-overview__table_edg_fbc_ccb} ## フロー、サブフロー、およびアクションのライフサイクル {#flow-designer-arch-overview__section_f5h_lbs_sbb} ワークフロースタジオ は、フローまたはアクションのステータスを使用して、設定の変更の現在の状態を表現します。 フローおよびサブフローのステータスとアクティブ化のステータス : \[ステータス\] フィールドは、フローまたはサブフローに関連付けられたプロセス計画が存在するかどうかを示します。 {#flow-designer-arch-overview__table_yl4_3l1_ccb__entry__2} | フローのステータス | 説明 | |-|-| | 変更 | フローまたはサブフローへの未保存の変更が存在することを示します。変更ありのフローまたはサブフローはまだ保存されていません。 | | ドラフト | フローまたはサブフローへの保存済みの変更が存在しますが、まだプロセス計画に保存されていないことを示します。ドラフト フローは、すでに保存されていますが、アクティブ化されていません。ドラフトサブフローは、すでに保存されていますが、公開されていません。 | | 公開済み | フローまたはサブフローの格納済みのプロセス計画が存在することを示します。公開されたフローは有効化または無効化されています。 | [ ] {#flow-designer-arch-overview__table_yl4_3l1_ccb} \[有効\] フィールドは、システムがフローまたはサブフローを実行するかどうかを示します。 {#flow-designer-arch-overview__table_rfj_yk1_2cb__entry__2} | アクティブ | 説明 | |-|-| | True | フローまたはサブフローが有効であり、トリガーされたか呼び出されたときに実行されることを示します。フローが有効化されているか、サブフローが公開されています。有効なフローは、トリガー条件が満たされたときか呼び出されたときに実行されます。有効なサブフローは、呼び出されたときに実行されます。 | | False | フローが非アクティブで、トリガーされたか呼び出されたときに実行されないことを示します。非アクティブなフローは、一度もアクティブ化されていないか、またはすでに非アクティブ化されています。非アクティブなサブフローは、一度も公開されていません。 | [ ] {#flow-designer-arch-overview__table_rfj_yk1_2cb} フローを操作する場合は、次の操作を実行できます。 * フローを保存する：フローのドラフトを作成します。 * フローを有効化する：フローのトリガーを有効にし、フローをプロセス計画に変換します。 * フローを非アクティブ化する：フローのトリガーを無効にし、新しいフローが実行されないようにします。現在実行中のフローは実行を続けます。 {#flow-designer-arch-overview__ul_skl_j52_bcb} サブフローを操作する場合は、次の操作を実行できます。 * サブフローを保存する：サブフローのドラフトを作成します。サブフローが公開後に変更された場合、サブフローはドラフト状況に移行します。サブフローを使用する有効なフローはすべて、公開済みのサブフローのみを実行します。 * サブフローを公開する：サブフローが含まれているフローを有効化できます。公開によって、フロー内の使用可能なサブフローのリストにサブフローが追加されます。 {#flow-designer-arch-overview__ul_ign_rhp_scb}
アクションステータス : ワークフロースタジオのインターフェイスには、アクションの設定ステータスは表示されません。アクションステータスを表示するには、アクション タイプ テーブル \[sys_hub_action_type_definition\] に移動して、\[ドラフト ステータス\] フィールドを表示します。 {#flow-designer-arch-overview__table_ymc_ng3_scb__entry__2} | アクションのドラフトステータス | 説明 | |-|-| | ドラフト | 公開されていないアクションに対する変更が存在することを示します。ドラフトのアクションは、\[ドラフト アクションを表示\] オプションが有効になっている場合にのみ、フローで使用できます。ドラフトのアクションが含まれているフローを有効化することはできません。 | | 公開済み | アクションが公開されたことを示します。公開されたアクションは、すべてのフローで使用でき、フローを有効化できます。 | [ ] {#flow-designer-arch-overview__table_ymc_ng3_scb} アクションを操作する場合は、次の操作を実行できます。 * アクションを保存する：アクションのドラフトを作成します。ドラフトのアクションは、\[ドラフト アクションを表示\] が有効になっている場合にのみ、フローで使用できます。アクションが公開後に変更された場合、アクションはドラフト状況に移行します。アクションを使用する有効なフローはすべて、公開済みのアクションのみを実行します。 * アクションを公開する：アクションが含まれているフローを有効化できます。公開によって、フロー内の使用可能なアクションのリストにアクションが追加されます。フローの実行中は、公開ステータスのアクションのみが実行されます。 {#flow-designer-arch-overview__ul_crj_k52_bcb} ![アクションのライフサイクルの図]() ## アプリケーション開発 {#flow-designer-arch-overview__id_ow1_swb_ptb} アクションまたはフローを設計するときは、次の一般的なガイドラインに従います。 標準の Now Platform アプリケーション開発機能を使用して、ワークフロースタジオのコンテンツを作成、管理、保護、および展開してください。フローデザイナーおよびアクションデザイナーは、通常は次のアプリケーション開発タスクを実行します。 * フローやアクションを格納するカスタムアプリケーションを作成します。 * アプリケーションのアクセス許可を設定して、アプリケーションデータへのアクセスを共有または制限します。 * ワークフロースタジオへのアクセスをアプリケーション開発者に許可します。 * カスタムアプリケーションをアプリケーションリポジトリに公開して、フローやアクションを他のインスタンスに展開します。 {#flow-designer-arch-overview__ul_mxr_gz2_bcb} ## 衝突回避 {#flow-designer-arch-overview__section_ayk_lxg_qrb} ワークフロースタジオ は、衝突回避をサポートします。衝突回避は、ユーザーが別の更新セットで変更されているオブジェクトを変更できないようにします。たとえば、ユーザー A が特定の更新セットのフローを編集しているとします。別の更新セットで作業しているユーザー B が、同じフローを開こうとしています。この状況では、システムは衝突を検出し、ユーザー B に警告します。その後、ユーザー B は \[キャンセル\] または \[続行\] のいずれかを選択できます。\[キャンセル\] を選択すると、ユーザー B は ワークフロースタジオ ホームページに戻ります。\[続行\] を選択すると、フローが読み取り専用モードで開きます。 衝突回避が機能するには、両方のユーザーが同じアプリケーションスコープ内にあり、グローバル以外のアプリケーションスコープである必要があります。さらに、変更するアプリケーションをソースコントロールにリンクする必要があります。詳細については、「衝突回避」を参照してください。 ## セキュリティ {#flow-designer-arch-overview__section_hgw_3t2_pdb} ワークフロースタジオのプロセスやレコードへのアクセスを制御します。 * アドミニストレーターは、アプリケーションを作成し、ワークフロースタジオ [委託開発](https://www.servicenow.com/docs/access?context=c_DelegatedDevelopment&version=yokohama&pubname=yokohama-application-development&ft:locale=en-US)権限を持つ開発者としてユーザーをアサインすることにより、ユーザーにワークフロースタジオフローへのアクセス権限を付与できます。委託開発では、アドミニストレーターは、フローデザイナーが通常はアドミンに限定された機能 (ユーザーロールの割り当て、アクセス制御の作成、スクリプトの作成など) にアクセスできるかどうかを制御できます。詳細については、「[開発者権限](https://www.servicenow.com/docs/access?context=developer-permissions&version=yokohama&pubname=yokohama-application-development&ft:locale=en-US)」を参照してください。 * アドミニストレーターは、ユーザーにフロー実行の詳細を表示するロールが含まれる flow_designer ユーザーロールを直接アサインすることによってワークフロースタジオフローへのアクセス権限を付与できます。 警告: ワークフロースタジオ はすべてのテーブルおよびすべてのデータベース操作にアクセスできるシステムユーザーとしてフローを実行できるため、ユーザーに直接 flow_designer ロールの権限を許可することは、ユーザーに admin ロールを与えることと同じです。 * フローデザイナーおよびアクションデザイナーは、標準の[アプリケーションアクセス設定](https://www.servicenow.com/docs/access?context=c_ApplicationAccessSettings&version=yokohama&pubname=yokohama-application-development&ft:locale=en-US)を使用して、コンテンツと他のアプリケーションとのやり取りを管理できます。 {#flow-designer-arch-overview__ul_lhc_5g1_ccb} ## アクションに関する制限 {#flow-designer-arch-overview__section_ksn_nt2_pdb} デフォルトでは、フローのアクションは 50 を超えることはできません。デフォルトの動作を変更するには、sn_flow_designer.max_actions システムのプロパティの値を増やします。ただし、大きなフローがインスタンスに与える可能性があるパフォーマンスの影響を考慮してください。 ## レコードの更新のためのトリガー オプション {#flow-designer-arch-overview__section_dd5_5t2_pdb} フロー設計者は、\[トリガーを実行\] オプションを使用して、フローが特定のレコードを更新できる頻度を指定できます。\[1 回\] オプションは、フローを 1 回だけ実行する場合に使用します。レコードが初めて更新されるとフローが実行されますが、それ以降はレコードが更新されてもフローはトリガーされません。\[常時\] オプションは、レコードが更新されるたびに、かつ、レコードに対して実行中の有効なフローがまだ存在しない場合に、フローを実行する場合に使用します。たとえば、インシデント レコードを 1 回だけ実行するようにアサインするフローを設定し、インシデント ウォッチ リストを常時実行するように通知するフローを設定できます。\[\[トリガーを実行\]\] フィールドは次のトリガー タイプでのみ使用できます。 * 作成時または更新時 * 更新日時 {#flow-designer-arch-overview__ul_iyw_q3d_fcb} ## 直接再帰の防止と間接再帰の制限 {#flow-designer-arch-overview__section_jdm_yt2_pdb} インスタンスの機能停止やシステムリソースの消費を防ぐため、ワークフロースタジオ では、直接再帰の結果であるフローまたはサブフローを開始する要求が無視されます。直接再帰は次の条件下で発生します。 * アクションが、自分自身が含まれているものと同じフローを呼び出す場合。たとえば、スクリプト ステップからフローへの API 呼び出しを実行する、などです。 * アクションまたはサブフローによって、フローのトリガーに一致する結果が生成される場合。たとえば、インシデント レコードが更新されたときに実行されるフローに、インシデント レコードを更新するレコード更新アクションが含まれている、などです。 {#flow-designer-arch-overview__ul_hht_2sj_jdb} ワークフロースタジオ ではまた、間接再帰からフローを開始できる回数も制限されています。関節再帰は次の条件下で発生します。 * 同じフローが一連のサブフロー呼び出しの中で複数回呼び出される場合。たとえば、サブフロー A がサブフロー B を呼び出し、サブフロー B がサブフロー A を呼び出す場合、いずれかのサブフローの呼び出しによって間接再帰が生じます。 * 一連のサブフローで同じフローが複数回トリガーされる場合。たとえば、レコードの作成によってトリガーされる 2 つのフローがあるとします。レコード A を作成するとフロー A がトリガーされ、レコード B が作成されます。さらに、レコード B を作成するとフロー B がトリガーされ、レコード A が作成されます。いずれかのレコード タイプの作成によって間接再帰が生じます。 {#flow-designer-arch-overview__ul_yqs_tz4_jdb} デフォルトでは、実行カウントが 3 回の間接再帰制限に達すると、フローの実行が停止されます。アドミニストレーターは、システムプロパティ com.glide.hub.flow_engine.indirect_recursion_limit を 1 以上の整数値に設定して、この制限を変更することができます。1 未満のプロパティ値は無視され、代わりに 1 回の制限が適用されます。間接再帰の制限を増やすとインスタンスのパフォーマンスに影響を及ぼす場合があるので注意してください。 注: デフォルトでは、トランザクション クォータ ルールによりフローの実行時間が 1 時間より長くなることはありません。 ## フローとアクションのテスト {#flow-designer-arch-overview__section_wxv_d52_pdb} フローのテストでは、トリガー条件がバイパスされ、すぐに実行されます。レコードベースのトリガーでフローをテストするには、トリガーとして動作する特定のレコードを選択する必要があります。フロー設計者は、テストの前に適切なサンプル レコードを生成しておく必要があります。フローのテストの詳細については、「[フローをテストする](https://servicenow-prod.fluidtopics.net/kcmcfukcYpQcvcGo96YM0Q "フローを有効化して他のユーザーがアクセスできるようにする前に、テストを実行して、想定どおりに機能することを確認します。")」を参照してください。 設計段階では、フローで \[ドラフトアクションを表示\] を設定することで、未公開のアクションをテストできます。ドラフト アクションを使用してテストを行う場合は、次のガイドラインに従ってください。 * フローとアクションを非本番インスタンスで設計します。有効な作業中のフローだけを本番インスタンスに展開します。 * ドラフトアクションが完成状態になるまで、\[ドラフトアクションを表示\] を True のままにしておきます。完成したら、それぞれのアクションを公開し、\[ドラフト アクションを表示\] を False に設定して、フローを有効化します。 警告: アクションを公開する前に \[ドラフト アクションを表示\] を無効化すると、フローからすべてのドラフト アクションが削除されます。 * 有効なフローまたは公開されたアクションに変更を加えると、それらはドラフトのステータスに戻ります。フローがトリガーされると、有効化されたフローと公開されたアクションのみが実行され、フロー実行の詳細には実行されたものだけが表示されます。有効なフローのドラフトが存在すると、フロー実行の詳細にリストされているトリガーとアクションが、ドラフト フローにリストされているものと異なる場合があります。 {#flow-designer-arch-overview__ul_zxj_331_ccb}