ベストプラクティス：カスタムスクリプトで GlideRecord 変数名として「gr」を使用することが常に得策ではない理由Issue インスタンス内のスクリプトは、予期しない動作をする可能性があります。Cause次に示すように、ServiceNow インスタンスのスクリプト、公式ドキュメント、コミュニティフォーラムなどの例で、「gr 」が変数名として使用されているのをよく見かけます。 var gr = new GlideRecord('incident'); これは得策ではありません。 プラットフォームは Javascript で、多くのコードがグローバル変数スコープで実行されます。 あるビジネスルールで定義された「gr」が、たまたま同じ更新やトランザクションの一部として実行されている他のスクリプトで定義された別の「gr」を上書きする可能性があります。 一方の「gr」をまったく関係のない別の「gr」に置き換えると、スクリプトはその「gr」が定義されたものであるとみなし、それ以降の行を実行し続けます。 スクリプトがクエリ結果を返さなかったり、スクリプトでクエリしたばかりのレコードとは異なるテーブルからのレコードを更新したりする可能性があります。 それは明らかに深刻な影響を与える可能性があります。 実例： ある顧客のインシデントでは、ワークフロー内のスクリプトからインシデントテーブルの単純な gr.get(); クエリを実行したにもかかわらず、要求されたアイテムテーブルが実際には知らないうちにクエリされていたために、レコードが返されませんでした。 これは、同じトランザクションで実行されているリンクされた関連レコードに対して要求アイテムクエリビジネスルールが実行されており、たまたま sc_req_item テーブルに「gr」が使用されていたことが原因でした。 ワークフロー内のカスタムスクリプトは、レコードが返されたと仮定していましたが、実際にはチェックしていませんでした。null である gr.assigned_to 値を使用し、実際の値を持っているかどうかは確認しませんでした。「null」の結果が、通知のユーザーテーブルに対する別のクエリに使用されたため、社内のすべての従業員がメールを受信しました。これは、大きな問題です。 このような状況では、完全なトランザクションの一部として実行されているすべてのものを考慮する必要があるため、他のどのコードが該当するコードを破壊しているかをデバッグして特定することもほとんど不可能です。たくさんの gs.info() メッセージをコードに追加して、すべての値を再確認します。Resolution一般的な優れた javascript コーディングの実践により、これらの問題のほとんどを避けることができます。 たとえば、スクリプトが別の gr を上書きすることを避けるために、スクリプトを関数でラップする方法があります。新しいビジネスルールと計算フィールドのほとんどで、関数内の変数を保護するためにコードをラップするデフォルトのスクリプトが追加されているのはこのためですが、古いビジネスルールを含むほとんどのスクリプトでは要求されません。 優れたコーディング手法に、コードを関数でラップするというものがあります。常にこれを行ってください。 スクリプト内で複数の GlideRecord を使用する場合、誤って gr 名を再利用する可能性があります。ベストプラクティスは、次の例に示すように使用するテーブルに関連した独自の変数名を使用し、決して「gr」を使用しないことです。 function updateOpenIncidents() { var openIncidentGr = new GlideRecord('incident'); .... } updateOpenIncidents(); // runs the above function 絶対にしないということを覚えておくだけで、このような問題が起こる可能性を減らすことができます。 Related Linksこれはなにも「gr」に限ったことではありません。どこでも for ループカウンタとして「i」を使用すると、遅かれ早かれ問題を引き起こすことになります。ループが早く終了したり、無限ループが発生するなどの症状が考えられます。 このプラットフォームには予約済みの名前があり、これも answer、current、previous など、独自の変数として使用しないでください。 この原因に直接関連する問題チケット： PRB1320166 MID サーバーのビジネスルール「プローブ - すべての MID」が、グローバルスコープの javascript 変数を上書きから保護していない (MID サーバーが誤って DOWN として報告される)PRB612498 スクリプトと計算ディクショナリーフィールドで「answer」変数 (または他の同じ変数名) を使用すると、スクリプトの「answer」変数が計算されたフィールド値で上書きされるPRB1351676 ハードウェアカタログに公開すると、publish_to_product_catalog UI ページ処理スクリプトのグローバルスコープの「gr」が原因で、「レコードが見つかりません」にリダイレクトされるPRB1508005 MID 環境キャッシュをクリアするビジネスルールがグローバル変数スコープで変数名「gr」を使用しているため、変数が上書きしたり/上書きされたり、cmdb_ci_ip_address レコードの更新が中断されたりするリスクがある