---
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) 所要時間：38分

ビジネスルールとは、レコードが表示、挿入、更新、または削除されるとき、またはテーブルに対してクエリが実行されるときに実行する、サーバー側スクリプトです。  
ビジネスルールは、特定のサーバー側の条件が満たされたときに実行されるスクリプトです。ビジネスルール条件には、データベース操作に関連してビジネスルールを実行するタイミングと、ビジネスルールが適用されるレコード操作が含まれます。クライアントスクリプトや UI アクションなど、クライアント側の条件に関してプラットフォームで利用できる他のスクリプトオプションがあります。  
注:  
ビジネスルールは、スクリプティングに依存する従来の自動化ソリューションです。新しいプロセス自動化に ワークフロースタジオ を使用して、拡張、再利用、理解、アップグレードが容易な自動化を作成します。多くの組織が本番環境でビジネスルールを用意しているため、このドキュメントを使用して既存のビジネスルールを操作する方法を学習してください。

## ビジネスルールの仕組み {#ariaid-title2}

ビジネスルールを構成するには、最初にビジネスルールを実行するタイミングと実行するアクションを決定する必要があります。

### ビジネスルールの実行タイミング

ビジネスルールは次の 2 つの基準セットに基づいて実行されます。

* データベース操作に関連してビジネスルールを実行するタイミング。
* ビジネスルールが適用されるレコード操作。

{#r_HowBusinessRulesWork__ul_q43_4h3_bp}ビジネスルールを実行するタイミングを決定するために、次のオプションが提供されています。{#r_HowBusinessRulesWork__table_w2s_1k3_bp__entry__2}

| オプション | ルールが実行されるタイミング |
|-|-|
| 次の値より前 | ユーザーがフォームを送信した後で、データベース内のレコードに対してアクションが実行される前。 |
| 次の値より後 | ユーザーがフォームを送信した後で、さらにデータベース内のレコードに対してアクションが実行された後。 |
| 非同期 | ユーザーがフォームを送信した後と、ビジネスルールから作成されたスケジュール済みジョブがスケジューラーによって実行された後。ユーザーがフォームを送信してから、データベース内のレコードに対して何らかのアクションが実行されるまでに、システムがビジネスルールからスケジュール済みジョブを作成します。 注: 新しく作成されたビジネスルールはアップグレード中に実行されます。 レコードのデータに基づいて意思決定を行う非同期ビジネスルールがレコードにある場合、レコードを立て続けに複数回更新すると、ビジネスルールが順序どおりに実行されなかったり、正しく実行されなかったりする可能性があります。 複数の非同期ビジネスルールが同じレコードを更新する場合、実行順序が保証されていないため、あるスクリプトによって実行された更新が別のスクリプトによって上書きされたり、予期しない順序で更新されたりする可能性があります。このような状況では、ビジネスルールの \[後\] オプションまたは[システムイベント](https://servicenow-prod.fluidtopics.net/APaGqFbSdHG4ohhR78tfEg "イベントは、特定の条件が発生したときにシステムがログに記録し、その条件に応じて何らかのアクションを実行するために使用する特別なレコードです。")を代わりに使用できます。 |
| 表示 | フォームがユーザーに提示された後で、データがデータベースから読み取られた直後。 |
[表 : 1. ビジネスルールを実行するタイミング]

{#r_HowBusinessRulesWork__table_w2s_1k3_bp}  
注:  
* 非同期ビジネスルールは、以前のバージョンのレコードにはアクセスできません。そのため、changes()、changesTo()、および changesFrom() GlideElement メソッドは非同期ルールスクリプトでは機能しません。ただし、条件ビルダーと条件フィールド (詳細ビュー) はどちらも changes()、changesTo()、および changesFrom() メソッドをサポートしています。
* ビジネスルールは、優先するように指定されるまで ACL を優先しません。詳細については、「[ビジネスルールとアクセス制御ルール (ACL) の関係](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0656366)」を参照してください。
{#r_HowBusinessRulesWork__ul_r2y_x2k_5tb}  
ビジネスルールを適用するレコード操作を決定するために、次のオプションが提供されています。{#r_HowBusinessRulesWork__table_p2x_rk3_bp__entry__2}

| オプション | ルールが実行されるタイミング |
|-|-|
| 挿入 | ユーザーが新しいレコードを作成し、システムがそれをデータベースに挿入するとき。 |
| 更新 | ユーザーが既存のレコードを変更したとき。 |
| クエリ | レコードまたはレコードリストのクエリをユーザーがデータベースに送信したとき。通常は、ビジネスルールの前にクエリ操作を使用する必要があります。 |
| 削除 | ユーザーがレコードを削除したとき。 |
[表 : 2. ビジネスルールが適用されるレコード操作]

{#r_HowBusinessRulesWork__table_p2x_rk3_bp}  
注:  
ビジネスルールでは、GlideRecord API から呼び出された場合にのみレコード操作が実行されます。一部のアプリケーションは、意図的にビジネスルールの処理をバイパスして、レコード操作を直接実行します。さらに、ビジネスルールは setWorkflow() メソッドを false に設定して実行された API 呼び出しを無視します。  
この画像は、さまざまなタイプのビジネスルールの実行タイミングを示しています。図 : 1. ビジネスルールの処理フロー  
注:  
ビジネスルールは、フォーム、リスト、または Web サービスからアクセスできるかどうかには関係なく、一貫してレコードに適用されます。これは、ビジネスルールと、フォームの編集時にのみ適用されるクライアントスクリプトとの間の大きな違いの 1 つです。

### ビジネスルールのアクション

ビジネスルールはさまざまなアクションを実行できます。一般的なアクションのタイプは次のとおりです。

* ユーザーが更新しているフォームのフィールド値を変更します。フィールド値は、そのフィールドで使用可能な特定の値、他のフィールドからコピーされた値、およびユーザーのロールによって決定される相対値に設定できます。
* ユーザーに情報メッセージを表示します。
* 親タスクの変更に基づいて子タスクの値を変更します。
* ユーザーがフォーム上の特定のフィールドにアクセスしたり、フィールドを変更したりできないようにします。
* 現在のデータベーストランザクションを中止します。たとえば、特定の条件が満たされている場合に、ユーザーがデータベースにレコードを保存できないようにします。
{#r_HowBusinessRulesWork__ul_yvs_fm3_bp}アドミニストレーターは、スクリプトを作成せずにフィールド値の設定、情報メッセージの作成、トランザクションの中止を行うことができます。

### 再帰ビジネスルールの防止 {#r_HowBusinessRulesWork__section_gk5_ykj_ccb}

ビジネスルールスクリプトでは current.update() を使用しないでください。update() メソッドは、挿入操作と更新操作のために同じテーブルで実行するビジネスルールをトリガーします。これにより、ビジネスルールが繰り返し呼び出されます。前のビジネスルールがすべて完了すると、前のビジネスルールに加えられた変更は自動的に保存されます。後のビジネスルールは、関連する、現行のものではないオブジェクトの更新に最適です。再帰ビジネスルールが検出されると、システムはそれを停止し、システムログにエラーを記録します。current.update() はシステムパフォーマンスの問題を引き起こすため、必要ありません。

false パラメーターを指定して setWorkflow() メソッドを使用すると、再帰ビジネスルールを防ぐことができます。update() および setWorkflow() メソッドの組み合わせは、上記の通常の前と後のガイドラインが要件を満たさない特別な状況でのみ推奨されます。
**関連タスク**   

* [ビジネスルールの作成](https://servicenow-prod.fluidtopics.net/B8h2h7O~WMqHzuhS1GGFPQ#t_CreatingABusinessRule "レコードが表示、挿入、更新、または削除されるとき、あるいはテーブルに対してクエリが行われるときに実行される、任意のタイプのビジネスルールを作成できます。")

## スコープ対象アプリケーションのビジネスルール {#ariaid-title3}

すべてのビジネスルールは、プライベートアプリケーションスコープまたはグローバルスコープのいずれかに割り当てられます。  
作成できるビジネスルールのタイプとそれらのルールへのアクセス方法は、ビジネスルールのスコープと、それが実行されるテーブルのスコープによって異なります。  
注:  
グローバルという用語は、ビジネスルールの 2 つの異なる側面、つまり、それが実行されるテーブルと、それが実行されるスコープを指します。ビジネスルールは、特定のテーブルに対して実行することも、グローバルにすることもできます。また、グローバルスコープまたはプライベートアプリケーションスコープに含めることもできます。

### 特定のテーブルのビジネスルール

ほとんどのビジネスルールは、\[テーブル\] フィールドで定義されている特定のテーブルで実行されます。同じスコープ内のテーブル、および別のアプリケーションスコープからの構成レコードを許可するテーブルに対して、ビジネスルールを作成できます。

ビジネスルールレコードとは異なるスコープ内のテーブルの場合は、ルールのタイプが制限されます。  
* 次のいずれかのオプションを使用して、\[時期\] が \[非同期\] のルールを作成できます。
  * 、、および のデータベース操作。 は選択できない。
  * アクションとスクリプト ( フィールド)。
* 次のいずれかのオプションを使用して、\[時期\] が \[次の前\] であるルールを作成できます。
  * 、、および のデータベース操作。 は選択できない。
  * アクションのみ。スクリプトを書くことはできず、データベース トランザクションを中断することはできません。
* 異なるスコープのテーブルに他のタイプのビジネスルールを作成することはできません。
{#c_BusinessRulesInScopedApps__ul_aht_rh1_rr}

特定のテーブルに対するビジネスルールに、他のビジネスルールやスクリプトからアクセスすることはできません。

### グローバルビジネスルール

警告:  
グローバルビジネスルールの代わりにスクリプトインクルードを使用することを検討してください。スクリプトインクルードは要求時にのみロードされますが、グローバルビジネスルールはシステム内のすべてのページでロードされます。

グローバルビジネスルールは、\[テーブル\] フィールドが \[グローバル\] に設定されているビジネスルールですグローバルビジネスルールは、スコープ保護に応じて、複数のテーブルでアクセスでき、他のスクリプトからアクセスできます。グローバルビジネスルールの場合は、\[アクセス元\] フィールドを設定して、スコープの保護を定義します。  
* \[このアプリケーションスコープのみ\]：ビジネスルールとは異なるスコープ内のアプリケーションがこのビジネスルールを呼び出すことを防止します。
* \[すべてのアプリケーションスコープ\]：任意のアプリケーションによるこのビジネスルールの呼び出しを許可します。  
  注:  
  グローバルビジネスルールはドメインセパレーションをサポートしていません。
{#c_BusinessRulesInScopedApps__ul_fqs_mh1_rr}

### スコープ対象のビジネスルールのスクリプト

ビジネスルールでスクリプトを作成すると、以下にアクセスできます。  
* ビジネスルールと同じスコープ内のすべてのスクリプトインクルードとグローバルビジネスルール。
* 異なるスコープ内のアプリケーションに呼び出しを許可するスクリプトインクルードとグローバルビジネスルール。別のスコープから関数を呼び出すには、関数のスコープを指定する必要があります。
* 一意のスコープにあるビジネスルールの場合は、スコープ対象のシステム API にのみアクセスできます。
{#c_BusinessRulesInScopedApps__ul_ebp_gh1_rr}

## ビジネスルールの作成 {#ariaid-title4}

レコードが表示、挿入、更新、または削除されるとき、あるいはテーブルに対してクエリが行われるときに実行される、任意のタイプのビジネスルールを作成できます。

### このタスクについて

注:  
これらの手順と例は、この機能を実装する方法に関する一般的なガイダンスを提供します。独自のユースケースについては、 [開発者コミュニティフォーラム](https://community.servicenow.com/community?id=community_forum&sys_id=75291a2ddbd897c068c1fb651f9619f3)を参照してください。ここでは、質問をしたり、他の開発者とやり取りしたり、既存のソリューションを検索したりすることができます。

### 手順

1. 移動先 すべてシステム定義ビジネスルール.
2. \[新規\] をクリックします。
3. 必要に応じてフィールドに入力します。  
   注:  
   すべてのフィールドを表示するようにフォームを設定する必要があります。
   {#t_CreatingABusinessRule__table_bb2_yq3_bp__entry__2}

   | フィールド | 説明 |
   |-|-|
   | 名前 | ビジネスルールの名前を入力します。 |
   | テーブル | ビジネスルールが実行されるテーブルを選択します。 注: リストには、ビジネスルールのスコープ保護を満たすテーブルとデータベースビューのみが表示されます。データベースビューに対して定義されたビジネスルールは、クエリでのみ実行できます。データベースビューのビジネスルールは、挿入、更新、または削除では実行できません。 |
   | アプリケーション | このビジネスルールを含むアプリケーション。 |
   | 次からアクセス可能 | グローバルビジネスルールのスコープ保護。 注: このフィールドは、\[テーブル\] フィールドが \[グローバル\] に設定されている場合にのみ表示されます。特定のテーブルで実行されるルールには適用されません。 |
   | アクティブ | ビジネスルールを有効にするには、このチェックボックスをオンにします。 |
   | 詳細 | フォームの詳細バージョンを表示するには、このチェックボックスをオンにします。 |
   | 実行タイミング ||
   | 時期 | \[上級\] ビジネスルールの実行タイミングを選択します：データベース操作の完了に関連して、\[表示\]、\[次の前\]、\[非同期\]、または \[次の後\] から選択します。 注: 関連するスケジュール済みジョブを作成するときにこの値が使用されるため、非同期ビジネスルールに対して \[順番\] を設定することを検討してください。 新しく作成された非同期ビジネスルールは、アップグレード時に自動的に実行されます。 既存の非同期ビジネスルールを移行して、新しい非同期動作を使用できます。 |
   | 順序 | \[上級\] このビジネスルールを実行する順序を示す番号を入力します。特定のアクティビティに複数のルールがある場合、ルールはここで指定された順序 (昇順) で実行されます。 |
   | 挿入 | レコードがデータベースに挿入されたときにビジネスルールを実行するには、このチェックボックスをオンにします。 |
   | 更新 | レコードが更新されたときにビジネスルールを実行するには、このチェックボックスをオンにします。 |
   | 削除 | \[上級\] レコードがデータベースから削除されたときにビジネスルールを実行するには、このチェックボックスをオンにします。 |
   | クエリ | \[上級\] テーブルに対してクエリが実行されたときにビジネスルールを実行するには、このチェックボックスをオンにします。 |
   | フィルター条件 | 選択したテーブルのフィールド値に基づいてビジネスルールを実行する必要があるタイミングを決定するには、条件ビルダーを使用します。 \[ 詳細 \] オプションを選択した場合は、\[ 条件 \] フィールドを使用してスクリプトで条件を作成することもできます。\[ フィルター条件 \] フィールドと詳細な \[条件 \] フィールドで定義された条件が同時に評価されます。 注: 文字列の比較に基づくフィルターでは、大文字と小文字が区別されます。 |
   | ロールの条件 | テーブル内のレコードを変更するユーザーが実行するビジネスルールに対して保持している必要があるロールを選択します。 |
   | アクション ||
   | フィールド値を設定 | 選択リストを使用して、選択したテーブルのフィールドの値を設定します。 * フィールド * 割り当てオペレーター： * 次の値：厳密にそのとおりの値 * 次から取得：別のフィールドの値 * 次の値 (動的)： ビジネスルールを構成するユーザーまたは特定のロールを持つユーザーに関連する値 {#t_CreatingABusinessRule__ul_k2h_qs3_bp} * 値 {#t_CreatingABusinessRule__ul_lff_ps3_bp} |
   | メッセージの追加 | このチェックボックスをオンにし、このビジネスルールが実行されたときに表示されるメッセージを入力します |
   | アクションの中止 | 現在のデータベーストランザクションを中止するには、このチェックボックスをオンにします。たとえば、挿入前のビジネスルールで、条件が満たされている場合は、レコードをデータベースに挿入しません。 このオプションを選択した場合、レコードに対する追加のアクション (フィールド値の設定やスクリプトの実行など) は実行できません。\[メッセージの追加\] チェックボックスをオンにしてメッセージを作成することにより、引き続きユーザーにメッセージを表示できます。 |
   | 詳細 ||
   | 条件 | ビジネスルールの実行タイミングを指定する JavaScript 条件ステートメントを作成します。このフィールドに条件ステートメントを追加することで、条件を個別に評価し、条件が true の場合にのみビジネスルールを実行するようにシステムに指示します。 \[ スクリプト \] フィールドまたは \[ フィルター条件 \] フィールドに条件ステートメントを含める場合は、このフィールドを空白のままにします。\[ フィルター条件 \] フィールドと詳細な \[条件 \] フィールドで定義された条件が同時に評価されます。 非同期ビジネスルールを実行する前にインスタンスで条件ステートメントを再評価するには、システムプロパティ glide.businessrule.async_condition_check を追加し、値を true に設定します。 |
   | スクリプト | \[上級\] 定義された条件が true である場合に実行されるスクリプトを作成します。 * onAfter * onAsync * onBefore * onDisplay {#t_CreatingABusinessRule__ul_cc4_tyg_jt} 詳細と例については、「[Example business rule scripts](https://www.servicenow.com/docs/access?context=c_BusinessRules&version=yokohama&pubname=yokohama-api-reference&section=business-rule-examples&ft:locale=en-US)」を参照してください。 |
   | 関連リスト：バージョン ||
   | バージョン | ビジネスルールのすべてのバージョンを表示します。バージョンを比較したり以前のバージョンに戻したりするには、このリストを使用します。 |
   [表 : 3. ビジネスルールのフィールド]

   {#t_CreatingABusinessRule__table_bb2_yq3_bp}
4. \[送信\] をクリックします。
ビジネスルールに関する問題が発生した場合は、Now Support ナレッジベースの[ビジネスルールに関する FAQ \[KB0965707\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0965707) 記事を参照してください。
**関連資料**   

* [ビジネスルールの仕組み](https://servicenow-prod.fluidtopics.net/B8h2h7O~WMqHzuhS1GGFPQ#r_HowBusinessRulesWork "ビジネスルールを構成するには、最初にビジネスルールを実行するタイミングと実行するアクションを決定する必要があります。")

## ビジネスルールのグローバル変数 {#ariaid-title5}

ビジネスルールで使用するための定義済みのグローバル変数があります。
次の事前定義されたグローバル変数を使用して、ビジネスルールスクリプトでシステムを参照します。  
{#c_UsingPredefinedGlobalVariables__table_jsc_wcw_lz__entry__2}

| グローバル変数 | 説明 |
|-|-|
| <var class="keyword varname">current</var> | 参照されるレコードの現在の状態。この変数を使用する前に、以下の「null ポインター例外の防止」を参照して null を確認してください。 |
| <var class="keyword varname">previous</var> | 実行コンテキスト中に行われた更新の前に参照されたレコードの状態。実行コンテキストは、最初の更新または削除操作で始まり、スクリプトと参照されたビジネスルールが実行された後に終了します。1 つの実行コンテキスト内でレコードに複数の更新が行われた場合、<var class="keyword varname">previous</var> は最初の更新または削除操作の前のレコードの状態を保持し続けます。更新および削除操作でのみ使用できます。非同期操作では使用できません。この変数を使用する前に、以下の「null ポインター例外の防止」を参照して null を確認してください。 |
| <var class="keyword varname">g_scratchpad</var> | スクラッチパッドオブジェクトは表示ルールで使用でき、クライアントスクリプトからアクセスできるようにクライアントに情報を渡すために使用されます。 |
| <var class="keyword varname">gs</var> | [GlideSystem](https://www.servicenow.com/docs/access?context=c_GlideSystemScopedAPI&version=yokohama&pubname=yokohama-api-reference&ft:locale=en-US) 関数への参照。 |
[ ]

{#c_UsingPredefinedGlobalVariables__table_jsc_wcw_lz}

変数 <var class="keyword varname">current</var>、<var class="keyword varname">previous</var>、<var class="keyword varname">g_scratchpad</var> は、トランザクションに対して実行されるすべてのビジネスルールでグローバルです。

### null ポインター例外の防止 {#c_UsingPredefinedGlobalVariables__null}

場合によっては、ビジネスルールの実行時にレコードの <var class="keyword varname">current</var> の状態または <var class="keyword varname">previous</var> の状態がないことがあります。これは、変数が null であることを意味します。変数を使用する前に null をチェックするには、次のコードをビジネスルールに追加します。

    if (current == null) // to prevent null pointer exceptions.
    return; 

### 変数の定義 {#c_UsingPredefinedGlobalVariables__section_c1q_xdw_lz}

ユーザー定義変数のスコープは、デフォルトでグローバルです。新しい変数が順序 100 のビジネスルールで宣言されている場合、次に実行される順序 200 のビジネスルールも変数にアクセスできます。これにより、予期しない動作が発生する可能性があります。

このような予期しない動作を防ぐために、コードは必ず関数でラップしてください。これにより変数が、関数でラップされていない他のビジネスルール内のシステム変数やグローバル変数との競合を防ぐことができます。また、<var class="keyword varname">current</var> などの変数を使用するには、関数が呼び出されたときに使用可能になっている必要があります。  
次のスクリプトは、他のコードとの競合に対して脆弱です。変数 <var class="keyword varname">now_GR</var> が他のルールで使用されている場合、変数の値が予期せず変更される可能性があります。

    var now_GR = new GlideRecord('incident');
    now_GR.query(); 
    while(now_GR.next()) {
     
       //do something
     
    }

このスクリプトが関数でラップされている場合、変数はその関数内でのみ使用でき、<var class="keyword varname">now_GR</var>という名前の変数を使用する他の関数と競合することはありません。

    myFunction();
     
    function myFunction() { 
      var now_GR = new GlideRecord('incident');
      now_GR.query(); 
      while(now_GR.next()) { 
        //do something 
    } }

## ビジネスルールとクライアントスクリプトを使用したフィールド値の制御 {#ariaid-title6}

フィールドにビジネスルールとクライアントスクリプトの両方を実装し、ユーザーがフォームとリストの両方を使用してレコード値を正しく設定できるようにします。また、編集が行われるときにフォームの値が即座に変更されるようにします。
クライアントスクリプトまたはビジネスルールのみを使用してフィールドの更新を制御する場合の問題は、フォームまたはリストのいずれかでフィールドが変更される可能性があるということです。クライアントスクリプトと UI ポリシーはフォームでのみ実行され (クライアントサイド)、リストの編集には適用されません。フォーム内のフィールドでクライアントスクリプトを実行している状態でのリスト編集を許可すると、正しくないデータがレコードに保存されるおそれがあります。クライアントスクリプトまたは UI ポリシーがフォームに適用されるシステムでは、リスト編集を無効にするか、適切なビジネスルールまたはアクセス制御を作成して、リストエディターでの値の設定を制御します。この副作用として、クライアントスクリプトに実装されたセキュリティ対策は簡単に回避されるようになります。ユーザーに必要とされるのはリスト内のフィールドを編集することだけです。

フォームのビジネスルールは動的ではありません。変更を表示するには、ユーザーがレコードを更新する必要があります。そのために、クライアントスクリプトを使用してフォームのフィールド値を制御することをお勧めします。

ビジネスルールとクライアントスクリプトの両方を使用してフィールド値を制御する場合、更新動作はシステム全体で同じです。これは、フォームのリストを使用して変更するかどうかでは、更新される値は異ならないことを意味します。これは、同じ機能を 2 回 (クライアントスクリプトに 1 回、ビジネスルールまたはアクセス制御に 1 回) 実装する必要があることを意味します。

### 例：ユーザーレコードのインポート中にビジネスルールを使用してメールアドレスを作成する

組織には、ユーザーのメールアドレスを first.last@company.com に設定するクライアントスクリプトがあります。アドミニストレーターがこれを行うと、ユーザーの情報を入力すると即座にメールアドレスが表示されます。次に、アドミニストレーターは、ユーザーの姓と名を含むスプレッドシートからユーザーの一括インポートを実行します。各ユーザーのメールアドレスは、フォームの編集時に自動的に設定されることが想定されています。クライアントスクリプトはフォーム (レコードへのインターフェイス) でのみ実行されるため、そのインターフェイスの外部からレコードにインポートされたデータに影響はなく、メールアドレスは作成されません。この問題を解決するために、アドミニストレーターはインポート時に実行されるビジネスルールを実装し、メールアドレスを作成します。

### 例：フォームで編集できないフィールドのリスト編集を防止する

組織は、アサイン先グループが \[開発\] の場合、インシデントフォームの \[優先度\] フィールドを非表示にします。これを行うためにインシデントフォームで UI ポリシーを作成しますが、ユーザーは引き続きリストエディターを使用して \[優先度\] フィールドを表示および編集できます。これを修正するには、アサイン先グループが \[開発\] のときに \[優先度\] フィールドへの読み取りアクセスを防止するアクセス制御を適用します。

### フィールド値としての NULL の使用 {#ariaid-title7}

文字列 NULL は、スクリプト内で特定のロールを持つ予約語です。

予約語はすべて大文字の NULL です。Null や null などの値を持つフィールドは受け入れ可能です。NULL は、特定のフィールドをクリアするためにのみ使用します。

インポートセットデータソースから取得された NULL フィールド値は、空のフィールド値としてステージングテーブルに挿入されます。インポートセット変換マップや、\[名\] フィールドまたは \[姓\] フィールドでは、フィールド値として NULL という用語を使用しないでください。また、参照フィールドでは NULL を使用しないでください。この値は予約語ではなく用語 NULL を含む文字列として解釈されます。{#c_UsingNULLAsAFieldValue__p_npz_t3w_q1b}

## ビジネスルールの表示 {#ariaid-title8}

表示ルールは、ユーザーがレコードフォームを要求したときに処理されます。

データベースからデータが読み込まれ、表示ルールが実行されて、フォームがユーザーに表示されます。current のオブジェクトが利用可能で、データベースから取得されたレコードを表します。フィールドの変更はまだデータベースに送信されていないため、一時的なものです。クライアントには、フォームの値はデータベースの値のように見えます。値が表示ルールから変更された形跡は示されません。これは計算フィールドと同様の概念です。

表示ルールの主な目的は共有されるスクラッチパッドオブジェクト <var class="keyword varname">g_scratchpad</var> を使用することです。このオブジェクトはフォームの一部としてクライアントにも送信されます。この動作は、表示されるレコードには通常含まれていないサーバーデータを必要とするクライアントスクリプトをビルドする場合に役立つことがあります。ほとんどの場合、これによってクライアントスクリプトはサーバーへのコールバックが必要になります。フォームが表示される前にデータを判別できる場合は、初期ロード時にクライアントにデータを提供する方が効率的です。フォームスクラッチパッドオブジェクトは、デフォルトでは空のオブジェクトであり、データの名前:値ペアを格納するためにのみ使用されます。  
表示ルールからデータをフォームスクラッチパッドに入力するには、次のようにします。

    // From display business rule
    g_scratchpad.someName = "someValue";
    g_scratchpad.anotherName = "anotherValue";
     
    // If you want the client to have access to record fields not being displayed on the form
    g_scratchpad.created_by = current.sys_created_by; 
     
    // These are simple examples, in most cases you will probably perform some other 
    // queries to test or get data

クライアントスクリプトからのフォームスクラッチパッドデータにアクセスするには、次のようにします。

    // From client script 
    if(g_scratchpad.someName == "someValue") { 
      //do something special 
    }

## タスクアクティブ状況管理ビジネスルール {#ariaid-title9}

このビジネスルールは、\[状況 (State)\] フィールドの変更に基づいてアクティブなフィールドの値を変更する必要があるかどうかを判断します。

タスクアクティブ状況管理ビジネスルールは、タスクレコードの \[状況 (State)\] が変更されたときに実行されます。実行順序は 50 で、他のほとんどのタスクビジネスルールの前に実行されます。  
現在のタスクテーブルで、テーブルに close_states 属性が定義されている場合、または上位レベルのテーブルからそれが継承されている場合は、アクティブなフィールドを変更する必要があるかどうかがルールによって決定されます。これは、前の状況値と現在の状況値を比較することによって行われます。

* 状態がアクティブ状態から非アクティブ状態に変わると、\[アクティブ\] フィールドは false に設定されます。
* 状態が非アクティブ状態からアクティブ状態に変わると、\[アクティブ\] フィールドは true に設定され、タスクを効果的に再アクティブ化または再オープンします。
{#c_TaskActiveStateMgmtBusRule__ul_lbn_gxq_fbb}

タスクを非アクティブまたはアクティブとしてマークする各タスクテーブルでルールを作成するのではなく、ビジネスルールで (current.active.changesTo(\[true/false\]) アクションを活用することをお勧めします。

## サンプルのビジネスルールスクリプト {#ariaid-title10}

組織の要件に役立つサンプルのビジネスルールスクリプトを検索します。  
注:  
これらの手順と例は、この機能を実装する方法に関する一般的なガイダンスを提供します。独自のユースケースについては、 [開発者コミュニティフォーラム](https://community.servicenow.com/community?id=community_forum&sys_id=75291a2ddbd897c068c1fb651f9619f3)を参照してください。ここでは、質問をしたり、他の開発者とやり取りしたり、既存のソリューションを検索したりすることができます。

### ビジネスルールでの日付フィールドの比較 {#ariaid-title11}

ビジネスルール内の 2 つの日付フィールドまたは 2 つの日付と時刻のフィールドを比較し、それらが正しくない場合はレコードの挿入または更新を中止できます。

たとえば、開始日を終了日より前にすることが必要になる場合があります。スクリプトの例を次に示します。  

    if ((!current.u_date1.nil()) && (!current.u_date2.nil())) { 
      var start = current.u_date1.getGlideObject().getNumericValue(); 
      var end = current.u_date2.getGlideObject().getNumericValue(); 
      if (start > end) {
        gs.addInfoMessage('start must be before end');
        current.u_date1.setError('start must be before end') ;
        current.setAbortAction(true);
     } }

この例はグローバルスクリプトでテストされています。スコープ付きスクリプトで機能させるためには、変更が必要になる場合があります。API の変更が必要になる可能性があることに加えて、スコープ付きスクリプトではセキュリティがより厳格になります。  
ビジネスルールは、挿入および更新アクションの前のルールにすることをお勧めします。サンプルのスクリプトは次のようになります。

* <var class="keyword varname">u_date1</var> と <var class="keyword varname">u_date2</var> は 2 つの日付フィールドの名前です。これらの名前を独自のフィールド名に置き換えます。
* 最初の行では、両方のフィールドに実際に値があることを確認します。
* 次の 2 つの行では、日付の数値を持つ変数を作成します。
* 次の 2 つの行では、エンドユーザーに対して異なるアラートメッセージを作成します。1 つはフォームの上部に、もう 1 つはフォームの <var class="keyword varname">[u_date1]</var> フィールドの横に表示されます。
* 日付フィールドが正しくない場合、最終行で挿入または更新は中止されます。
{#c_ComparingTwoDateFields__ul_y4y_kjx_z4}  
上記の比較のより複雑な例を次に示します。開始日と終了日のペアが複数ある場合は、アレイを次のように使用できます。また、このスクリプトでは、入力日付が特定の範囲内である必要があります。このケースでは、過去は 30 日以上、将来は 365 日以内です。

    // Enter all start and end date fields you wish to check, as well as the previous values 
    // Make sure that you keep the placement in the sequence the same for all pairs 
    var startDate = new Array(current.start_date,current.work_start); 
    var prevStartDate = new Array(previous.start_date,previous.work_start); 
    var endDate = new Array(current.end_date,current.work_end); 
    var prevEndDate = new Array(previous.end_date,previous.work_end);

    // The text string below is added to the front of ' start must be before end' 
    var userAlert = new Array('Planned','Work');
     
    // Set the number of Previous Days you want to check 
    var pd = 30; 
    // Set the number of Future Days you want to check 
    var fd = 365;
     
    // You shouldn't have to modify anything below this line
     
    var nowdt = new GlideDateTime();
    nowdt.setDisplayValue(gs.nowDateTime()); 
    var nowMs = nowdt.getNumericValue(); 
    var pdms = nowMs; 

    // Subtract the product of previous days to get value in milliseconds
    pdms -= pd * 24 * 60 * 60 * 1000; 
    var fdms = nowMs; 

    // Add the product of future days to get value in miliseconds
    fdms += fd * 24 * 60 * 60 * 1000; 
    var badDate = false;
     
     // Iterate through all start and end date / time fields 
    for (x = 0; x < startDate.length; x ++) { 
      if ((!startDate[x].nil()) && (!endDate[x].nil())) { 
        var start = startDate[x].getGlideObject().getNumericValue(); 
        var end = endDate[x].getGlideObject().getNumericValue(); 
        if (start > end) {
          gs.addInfoMessage(userAlert[x] + ' start must be before end');
          startDate[x].setError(userAlert[x] + ' start must be before end');
          badDate = true; } 
        else if ((prevStartDate[x]) != (startDate[x])) { 
          if (start < pdms) {
             gs.addInfoMessage(userAlert[x] + ' start must be fewer than ' + pd + ' days ago');
             startDate[x].setError(userAlert[x] + ' start must be fewer than ' + pd  + ' days ago');
             badDate = true; } } 
        else if ((prevEndDate[x]) != (endDate[x])) { 
          if (end > fdms) {
             gs.addInfoMessage(userAlert[x] + ' end must be fewer than ' + fd + ' days ahead');
             endDate[x].setError(userAlert[x] + ' end must be fewer than ' + fd + ' days ahead');
             badDate  = true ; 
    } } } } 
    if (badDate == true ) {
      current. setAbortAction ( true ) ; }

### XML ペイロードの解析 {#ariaid-title12}

XML 形式のフィールドは、システムの getXMLText 関数を使用して解析できます。  
`ecc_event` 行のペイロードなど、XML 形式でデータベースに挿入されるフィールドは、システムの getXMLText 関数を使用して解析できます。getXMLText 関数は、文字列と XPATH 式を受け取ります。たとえば、次のようになります：

    var name = gs.getXMLText("<name>joe</name>", "//name");

文字列「joe」を返します。  
フィールド「payload」に XML が含まれていると仮定すると、関数呼び出しは次のようになります。

    var name = gs.getXMLText(current.payload, "//name");

XPATH の詳細については、「[w3schools](http://www.w3schools.com/xml/xpath_intro.asp)」を参照してください。

### 前のビジネスルールでのデータベースアクションの中止 {#ariaid-title13}

前のビジネスルールスクリプトで、setAbortAction() メソッドを使用して現在のデータベースアクションをキャンセルまたは中止できます。

たとえば、前のビジネスルールが挿入アクション中に実行され、スクリプトに `current.setAbortAction(true)` を呼び出す条件がある場合、current に保存される新しいレコードはデータベース内には作成されません。このビジネスルールは setAbortAction() を呼び出した後も実行を継続し、後続のすべてのビジネスルールは正常に実行されます。このメソッドを呼び出すと、現在のオブジェクトのデータベースアクションの実行のみが中止されます。

isActionAborted() メソッドを使用して、現在のデータベースアクション (挿入、更新、削除) を中止するかどうかを決定できます。 isActionAborted() は新しいスレッド用に初期化され、next() メソッドはその値を明示的に false に設定します。  
注:  
setAbortAction() は、アクションが中止されるレコードと同じスコープからのみ実行できます。`current.setAbortAction` は、別のスコープで定義されているビジネスルールで実行された場合、優先されません。

### ビジネスルールでトリガーされる操作の決定 {#ariaid-title14}

複数のデータベースアクションでトリガーされるビジネスルールのスクリプトを作成できます。  
イベントをトリガーしたアクションに応じてビジネスルールスクリプトを動的に分岐させる場合は、operation() 関数を使用できます。たとえば、次のようになります：

    if(current.operation() == "update") {
      current.updates ++; } 
      if(current.operation() == "insert") {
        current.updates = 0; }

### ビジネスルールでの OR 条件の使用 {#ariaid-title15}

OR 条件は、ビジネスルール内の任意のクエリ部分に追加できます。  
OR 条件は、addOrCondition() メソッドによってビジネスルール内の任意のクエリ部分に追加できます。次の例は、優先度が 1 または 2 のすべてのインシデントを検索するためのクエリを示しています。最初の addQuery() 条件は変数として定義され、OR 条件で使用されます。

    var inc = new GlideRecord('incident'); 
    var qc = inc.addQuery('priority','1'); 
    qc.addOrCondition('priority','2');
    inc.query(); 
    while(inc.next()) { 
      // processing for the incident goes here 
    }

次のスクリプトはより複雑な例で、2 つのクエリ条件変数を使用して、`(priority = 1 OR priority = 2) AND (impact = 2 OR impact = 3)` と同等の実行をします。OR 条件の結果は、2 つの変数 <var class="keyword varname">qc1</var> と <var class="keyword varname">qc2</var> を使用して実行されます。これにより、`IF` 条件や `WHILE` ループ内など、スクリプトの後半でクエリ条件オブジェクトを操作できます。

    var inc = new GlideRecord('incident'); 
    var qc1 = inc.addQuery('priority','1');
    qc1.addOrCondition('priority','2'); 
    var qc2 = inc.addQuery('impact','2'); 
    qc2.addOrCondition('impact','3'); 
    inc.query(); 
    while(inc.next()) { 
      // processing for the incident goes here  
    }

### ビジネスルールからの Glide リストの参照 {#ariaid-title16}

Glide リストとして定義されたフィールドは、単一のフィールドに格納される値のアレイです。
ビジネスルールを記述するときに glide_list フィールドを処理する方法の例を次に示します。通常、glide_list フィールドには、他のテーブルへの参照値のリストが含まれています。

#### 例

たとえば、タスク内の \[ウォッチリスト\] フィールドは、ユーザーレコードへの参照を含む glide_list です。

次のコードに、フィールドを参照する方法を示します。  

    // list will contain a series of reference (sys_id) values separated by a comma
    // array will be a javascript array of reference values
    var list = current.watch_list.toString();
    var array = list.split(",");
    for (var i=0; i < array.length; i++) {
       gs.print("Reference value is: " + array[i]);
    }

出力：

    *** Script: Reference value is: 62826bf03710200044e0bfc8bcbe5df1
    *** Script: Reference value is: c2826bf03710200044e0bfc8bcbe5d45
    *** Script: Reference value is: 5f74e421c0a8010e01ec0d74a7ee2cc6
    *** Script: Reference value is: 06826bf03710200044e0bfc8bcbe5d57

また、次に示すように getDisplayValue() メソッドを使用して、参照値に関連付けられた表示値を取得することもできます。  

    // list will contain a series of display values separated by a comma
    // array will be a javascript array of display values
    var list = current.watch_list.getDisplayValue();
    var array = list.split(",");
    for (var i=0; i < array.length; i++) {
       gs.print("Display value is: " + array[i]);
    }

出力：

    *** Script: Display value is: Abel Tuter
    *** Script: Display value is:  Ashley Leonesio
    *** Script: Display value is:  Charles Beckley
    *** Script: Display value is:  Cherie Fuhri

### indexOf("searchString") を使用して Glide リスト内の文字列を検索する {#ariaid-title17}

Glide リストフィールド (ウォッチリストなど) に少なくとも 1 つの値がある場合は、indexOf("searchString") を使用してメソッドに渡される文字列の場所を返します。
フィールドが空の場合は、`undefined` が返されます。未定義の値を返さないようにするには、次のいずれかを実行します。

* フィールドを強制的に文字列にします。例： watch_list.toString().indexOf("searchString")
* indexOf() を使用する前に、条件がある空の Glide リストフィールドを確認します。例：if (watch_list.nil() \|\| watch_list.indexOf("searchString") == -1)

### ユーザーアカウントのロック {#ariaid-title18}

ユーザーがアクティブでない場合は、ユーザーアカウントをロックできます。  
次のビジネスルールスクリプトは、ユーザーが LDAP ディレクトリでアクティブでない場合、またはユーザーがインスタンスへのセルフサービス、itil、またはアドミニストレーターアクセス権を持っていない場合に、ユーザーアカウントをロックします。

    // Lock accounts if bcNetIDStatus != active in LDAP and user does not  
    // have self-service, itil or admin role 
    var rls = current.accumulated_roles.toString(); 
    if(current.u_bcnetidstatus == 'active' && (rls.indexOf(',itil,') > 0 || 
      rls.indexOf(',admin,') > 0 || 
      rls.indexOf(',ess,') > 0 )) { 
      current.locked_out = false; } 
    else { 
      current.locked_out = true; } 

    var now_GR = new GlideRecord("sys_user"); 
    now_GR.query(); 
    while(now_GR.next()) { 
      now_GR.update(); 
      gs.info("updating " + gr.getDisplayValue()); 
    }

### デフォルトのクエリ前ビジネスルール {#ariaid-title19}

データベースクエリの実行前に実行されるクエリビジネスルールを使用できます。  
このクエリビジネスルールを使用して、ユーザーが特定のレコードにアクセスできないようにします。インシデントレコードへのアクセスを制限するデフォルトのビジネスルールの以下の例を考慮してください。

* 名前：incident query
* テーブル：インシデント
* タイミング：クエリ前
* スクリプト：

{#c_ExScrDefBeforeQueryBusinessRule__ul_cq3_jqx_z4}

    if(!gs.hasRole("itil") && gs.isInteractive()) { 
      var u = gs.getUserID(); 
      var qc = current.addQuery("caller_id",u).addOrCondition("opened_by",u).addOrCondition("watch_list","CONTAINS",u);
      gs.print("query restricted to user: " + u); }

この例では、ユーザーは、itil ロールを持っているか、または \[Caller\] あるいは \[Opened by\] フィールドでリストされていない限り、インシデントレコードにアクセスできません。そのため、セルフサービスユーザーがインシデントのリストを開くと、自分が送信したインシデントしか表示されません。  
注:  
ユーザーに表示されるレコードは、アクセス制御を使用して制限することもできます。