ビジネスルールに関する FAQ<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #7057C7; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } 目次 sc_taskの変数がビジネスルールで期待される結果を返さないのはなぜですか? レコードにインシデント状況とジャーナルエントリが複数回表示されるのはなぜですか?ビジネスルールがトリガーされないのはなぜですか?非アクティブなビジネスルールがまだ実行されているのはなぜですか?ビジネスルールが if/for/while ループに入らないのはなぜですか?ビジネスルールが特定のレコードに対して機能しないのはなぜですか? よく寄せられる質問 この記事の目的は、クローンに関して ServiceNow テクニカルサポートによく寄せられる一般的な要求/質問に回答することです。フォローアップの質問がある場合は、テクニカルサポートにお問い合わせください。 この KB も役立ちます。 ビジネスルールのベストプラクティス sc_taskの変数がビジネスルールで期待される結果を返さないのはなぜですか? これは、変数のスコープが原因で発生する可能性があります。変数でグローバルが選択されている場合、デフォルトでは、サービスカタログワークフローまたは実行計画内のすべてのカタログタスクで変数を使用できます。この選択を解除した場合、変数を個々のカタログタスクに関連付ける必要があります。 役立つドキュメントを次に示します。 https://docs.servicenow.com/bundle/quebec-application-development/page/script/business-rules/concept/c_UsingPredefinedGlobalVariables.htmlhttps://docs.servicenow.com/bundle/quebec-servicenow-platform/page/product/service-catalog-management/task/t_CreateAVariableForACatalogItem.html また、変数をグローバルにすることはそのカタログアイテムにのみ固有であり、別のカタログアイテムの同じ名前を持つ他の変数には影響しません。 レコードにインシデント状況とジャーナルエントリが複数回表示されるのはなぜですか? 通常、この問題はロジックのループが原因で発生します。問題を再現できる場合は、ビジネスルールのデバッグをオンにして、インシデントのビジネスルールが 2 回実行されているかどうかを確認することを常にお勧めします。ほとんどの場合、ビジネスルールはレコードに対して 1 回だけ実行する必要があるため、レコードでビジネスルールを 2 回表示することは、レコードに重複する情報が存在することを明確に示しています。 そのビジネスルールと、コードにcurrent.update()があるかどうか他のビジネスルールも確認します。もしそうなら、これがあなたの最大の原因です。これは通常、ビジネスルールがレコードの変更に対して実行され (更新など)、そのビジネスルールのためにアクションを実行してそのレコードを変更し、current.update() を実行してそのレコードに別の更新を実行し、ビジネスルールの再実行をトリガーして重複を引き起こすために発生します。 同じレコードからトリガーされたビジネスルールのレコードを更新する場合は、更新前 BR を使用します。これにより、更新をキャッチし、データベースにプッシュする前に更新ステートメントを調整できます。これは、重複の原因となる2回目の更新が不要であることを意味します。 ビジネスルールがトリガーされないのはなぜですか? ビジネスルールがトリガーされていないかどうかを確認する最初のことは、デバッグビジネスルールをオンにして問題を再現することです。ビジネスルールが実際に見つかっているかどうかを確認し、設定された条件を満たしていない可能性があるかどうかを確認します。ビジネスルールが表示されても、設定された条件に失敗した場合は、条件を調べて、どの部分が正しくないかを見つける必要があります。一部の条件には確認する項目が複数ある場合があるため、それらすべてを手動で検証して最初に問題を確認できる場合は、すべての条件を削除して一度に 1 つずつ追加し直し、問題となっている条件を絞り込むことができます。 もう 1 つの方法は、条件からチェックを削除し、ビジネスルールのスクリプトに追加し、gs.info ステートメントを使用して値を表示することで、このビジネスルールによって見つかったデータをライブで確認できるようにすることです。取得しているデータが思ったものと異なる場合があります。これは、条件を調整して修正するのに役立ちます。 万が一、ビジネスルールがトリガーされない場合、いくつかの理由が考えられますが、最も一般的なのは、ビジネスロジックの実行を停止するコード内の setWorkflow(false) ビジネスルールです。これは、特定の作業を行うときにシステムで特定のものがトリガーされないようにするためにコードで使用されますが、ビジネスルールがトリガーされないという後遺症が生じる可能性もあります。これがある場合は、setWorkflow(false) を含むビジネスルールを探し、このビジネスルールの前にトリガーされてこの問題を引き起こしている可能性があるかどうかを確認します。その後で、ビジネスルールが実行されるようにコードを調整する必要があるかどうかを確認できます。 Java で実装されているため顧客には表示されない、すぐに利用可能なコードがパフォーマンス上の理由からビジネスルールエンジンを完全にバイパスし、レコードの変更に GlideRecord をまったく使用していない可能性もあります。場合によっては、特定の機能について、この動作はシステムプロパティで制御できますが、通常は構成できません。ドキュメントとナレッジベースで特定のテーブルと機能を検索し、ビジネスルールの実行が想定されないタイミングに関連する情報を探します。 非アクティブなビジネスルールがまだ実行されているのはなぜですか? したがって、ビジネスルールが非アクティブに設定されている場合、指定されたテーブルの INSERT/UPDATE/SELECT/DELETE からトリガーされることはなく、システムはその非アクティブを検出し、実行しません。ただし、それでもインスタンスにビジネスルールが記録されていることがわかります。これは、スケジュール済みジョブを通じて行われます。スケジュール済みジョブはビジネスルールをトリガーできます。これは、何らかのロジックがあり、レコードのすべてのアクションで実行するのではなく、スケジュール済みジョブとして 1 時間ごとまたは毎日実行したい場合に使用されます。この完璧な例は、OOTB ビジネスルールです。 インシデントの自動クローズ これには、X 日間解決されたすべてのインシデントを調べてインシデントをクローズするロジックがあります。現在、これは常に実行する必要はありませんが、スケジュール済みジョブ [インシデントの自動クローズ] を介して 1 時間ごとに実行するように設定されています。 スクリプトをスケジュール済みジョブ内に記述できますが、ビジネスルールの機能を使用する場合は、スクリプトを非アクティブにしてスケジュール済みジョブから呼び出すことができます。 ビジネスルールが if/for/while ループに入らないのはなぜですか? ビジネスルール内には、if/for/while ループである可能性があり、ループに入らない理由を特定できないループが多数ある場合があります。これを決定する最も簡単な方法は、いくつかの基本的なデバッグステートメントを追加することです。特定のオブジェクトのデータをチェックしている場合、またはクエリに別の GlideRecord オブジェクトが含まれている場合は、チェックの前に簡単なログまたは情報ステートメントを追加して、スクリプト内の変数を検証して、ライブ処理中に値が何であるかを確認できます。これは、ループに入らない理由を特定し、ビジネスルール内のどこに問題がある可能性があるかを特定するのに役立ちます。問題を再現するのが難しい場合もあるため、コードを取得してスクリプト (バックグラウンド) で実行することもできます。BR から指定されたテーブルの glideRecord オブジェクトを作成し、現在のオブジェクトをそのオブジェクトに調整するだけで、スクリプト (バックグラウンド) で実行して、コード内のどこに問題があるかを追跡できます。 ビジネスルールが特定のレコードに対して機能しないのはなぜですか? これは、上記と同様の問題が原因である可能性があります。通常、問題は基準を満たさないレコードのデータに関連しています。よく見られる問題は、リストビューのフィールドには (空) と表示されているが、実際にはフィールドにデータが含まれていることです。これは、フィールドに無効な文字が含まれていることが原因の可能性があります。つまり、データがあるのに表示値がないため空白に見える参照フィールドである可能性があります。このような問題がある場合は、レコードに XML を表示することをお勧めします。データがフィールドにあるのにリストビューに表示されないことに驚くことがあります。その問題が見つかったら、レコードを修正するか、自分に合うように条件を調整できます。