こんにちは。SCSKの吉田です。
今年リリースされたWashington DCバージョンから「Customized Metadata Detail」というテーブルが追加されていることを最近発見しました。
このテーブルを使用することで、インスタンスに加えたカスタマイズを簡単にトレースすることができるようになりました。
公式ドキュメントにはおそらく記載はなく（見逃していたらすいません）、あくまでも個人で調べた内容となりますが、共有させていただきます。
はじめに
ServiceNowを導入する際は、OOTB（Out of the Box）と呼ばれる標準機能を利用して、カスタマイズを最小限に抑えることが推奨されています。標準機能を利用することで初期構築期間の短縮、システム稼働後のメンテナンスコスト削減などのメリットがあります。
その一方で、業務要件のためにカスタマイズが必要となる場面もあります。その際は以下の点を考慮する必要があります。
- メンテナンス工数の増大
カスタマイズは自身でメンテナンスを行っていく必要があります。カスタマイズの程度にもよりますが、発生した問題の原因がカスタマイズの場合、サポート対象外となることがあります。
また、ServiceNowでは１年に１回はインスタンスのアップグレードを実施する必要があり、カスタマイズが多いほどリグレッションテストにかかる工数は増大します。 - カスタマイズ箇所のブラックボックス化
もちろんですがカスタマイズで実装した内容は、公式ドキュメントに記載されていません。そのため、設計書に残していない場合、カスタマイズを実施した特定の開発者に属人化してしまいます。
また、きちんと引継ぎがなされないまま開発者が離任した場合、カスタマイズ箇所の特定が困難になります。
上記のことから、不要なカスタマイズを避けることが求められ、またカスタマイズを実施する場合は、設計書等にドキュメント化しておく必要があります。
しかし、ドキュメント化のルールを整備しないまま開発を進めてしまい、後からカスタマイズをトレースするのに苦労しているという方も多いのではないでしょうか。
カスタマイズをトレースする
以前までは、例えば以下のようにカスタマイズをトレースしていました。
- テーブルに追加したカスタムフィールドを探す場合：sys_dictionaryテーブル上で名前が「u_」から始まるレコードを検索する
- カスタマイズしたBusiness ruleを探す場合：sys_scriptテーブル上で、作成/更新者、作成/更新日時、スクリプトの中身を確認してカスタマイズか否かを確認する
このように、各テーブル上で、それぞれの探し方でトレースする必要がありました。
しかし、Washington DCからは、カスタマイズのトレースを簡単にする以下テーブルが追加されました。
- Customized Metadata Detail[sys_metadata_customization]
どのテーブル上のレコードを変更したかに関係なく、カスタマイズと分類される変更は、Customized Metadata Detailテーブル上にレコードとして格納されるようになったようです。
各テーブル毎に探す手間が省け、かつカスタマイズのみが格納されるテーブルの為、OOTBかカスタマイズかの判別も不要となりました。
また、Author Typeの値を使用することで、以下のように更に詳細な分類ができます。
- 「ServiceNow」の場合：OOTBのレコードに対して、変更を加えカスタマイズしている
- 「Custom」の場合：レコードを新規作成してカスタマイズしている
他にもAuthor Typeが「Unknown」や「ToBeDetermined」となっているレコードがありましたが、カスタマイズを特定する上では上記2つを確認するだけで問題なさそうです。
注意点として、Customized Metadata Detailに格納されるのは、更新セットにキャプチャされる変更のみのようです。
試しにScheduled Jobを作成しましたが、Customized Metadata Detailにはレコードが作成されませんでした。
最後に
今回は、Washington DCで追加されたテーブルを使用し、カスタマイズをトレースする方法をご紹介しました。
カスタマイズのトレースにお困りの方にとって、本記事が参考になれば幸いです。
また、弊社では豊富な構築・運用ノウハウにより、ServiceNow導入のご支援が可能です。
以下HPも併せてご参照ください。
