ServiceNow 開発者として、sys_id をアサインロジックのビジネスルールに直接組み込みたくなる誘惑に駆られた経験は、誰にでもあるでしょう。機能しなくなるまでは問題なく動作します。
「Did You Know: Best Practices」のこのエピソードでは、Shamma Negi がロジックにsys_idをハードコーディングすることの危険性について説明します。具体的には、sys_idsに基づいてグループを割り当てるコードが、環境間で移動したときに、それらの ID がターゲットインスタンスに存在しない可能性があるために失敗する可能性があることを実証しています。
Shamma は、脆弱な ID に依存するのではなく、ServiceNow のすぐに利用可能な強力な機能であるアサインルールの使用方法を示します。コミュニケーションチャネルがチャットの場合に、ハードコードされたIDではなく名前と条件のみを使用して、インシデントがデータベースグループに自動的にアサインされるデモを説明します。
しかし、学習はそれだけではありません。最後に、次の 4 つのベストプラクティスを紹介します。
-
システムプロパティを使用 どうしても必要な場合は、sys_id にシステムプロパティを使用してください。これにより、構成の移植性が向上します。
-
ディシジョンテーブルの活用 時間の経過とともに変化する複雑なアサインロジックには、ディシジョンテーブルを活用しましょう。視覚的で、スケーラブルで、保守可能です。
-
更新セットまたはシードデータにキーレコードを含める インスタンス間で重要な構成の一貫性を確保するためです。
-
インスタンススキャンを実行 定期的にインスタンススキャンを実行しましょう。これらは、本番環境に昇格する前にハードコードされた参照やその他の禁止事項をキャッチするのに役立ちます。
新しいアプリを構築する場合でも、従来のアプリを維持する場合でも、このエピソードは簡潔ながらも重要なリマインダーです。 クリーンロジックは移植可能なロジックです。
巧妙なトリックや塹壕から学んだ教訓があれば、ぜひお聞かせください。コメントに残すか、コミュニティで私たちをタグ付けしてください!
この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-advocate-blog/clean-assignment-logic-in-servicenow-st...。
免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。
This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-advocate-blog/clean-assignment-logic-in-servicenow-st...。
