ServiceNow – Update Set(更新セット)の図解解説

開発・導入

ServiceNowにおける開発の成果物であるUpdate Setについて解説します。

Update set(更新セット)とは

Update Set更新セットは、一般的な開発におけるソースコードや実行可能ファイルに対応する、ServiceNowにおける開発の成果物(の一つの形式)です。そして、一般的な開発と同様に、開発環境で作ったUpdate Setを本番環境にデプロイ(実際にはTransfer=移送と呼ぶことが多いです)することで機能をリリースします。

「ServiceNowってSaaSのITSMツールでしょ?開発って何?」という方は、まずはこちらの記事をご覧ください。

Update Set(更新セット) ≒ 環境に対する変更履歴、開発の操作履歴

Update Setはインスタンス(環境)に対して行われたUpdate(変更)を入れておく箱のようなものです。「商品管理システムの開発において、商品情報を格納するテーブルを作成する」というシチュエーションを例に、Update Setのイメージを示します。

Update Setのイメージ

まず開発者はUpdate Setを作成します。その上でインスタンス(環境)に対して開発を行うと、開発によって追加されたテーブルやカラムといったオブジェクトの情報がUpdate Setに蓄積されていきます。そして、Update SetをCompleteすることで、開発によって作成された一連のオブジェクトがパッケージ化されて、別の環境に移送(デプロイ)できる状態になります。

Update SetにはUpdate Setを作成してからCompleteするまでの間に行った環境に対する変更の情報が含まれているため、環境に対する変更履歴、開発の操作履歴と考えてもよいです。

Update Set(更新セット) ≒ パッチ

Update Ssetは常にそれ単体で一つの機能として成立するとは限りません。例えば、「商品管理システムにおいて、商品の価格を管理する機能を追加することになったので、商品テーブルに価格(Price)カラムを作成することにした」というシチュエーションを考えます。この場合、新しく作ったUpdate Setはそれだけでは動かない、つまり他の機能を前提として、それを補う「パッチ」のような役割を持っていることになります

単体で機能として成立するUpdate Setと、他の機能を補うパッチに近いUpdate Set

ServiceNowをaPaaS(アプリケーション開発プラットフォーム)として使う場合はパターン①、SaaS(ITSMソリューション等)として使う場合はパターン②のイメージがより理解しやすいと思います。

“Default” Update Set

開発者権限を持っているユーザは、画面上部の地球のようなアイコンから現在選択されているUpdate Setを確認することができます。

現在選択されているUpdate Setの確認方法

明示的にUpdate Setを作成・指定していない初期状態や、選択されているUpdate SetをCompleteした後は、”Default”という名前のUpdate Setが選択されています。この状態で開発を行うと、作成されたCustomer Updateは全て”Default” Update Setに含まれます

そのため、開発を行う際はまずその開発のためのUpdate Setを作成し指定するのが基本です。ただし、機能の検証で一次的に変更を行いたい場合や特定の環境だけで設定を変更したい場合には、あえて”Default” Update Setを選択することもあります。

なお、ServiceNowにおける開発物の移送(デプロイ)方法として、Update Set(更新セット)の他にApplication Repository(アプリケーションリポジトリ)を使う方法もあります。Application Repositoryのみを使う場合は、Update Setを作成せず”Default”のままにしておくこともあります。Application Repositoryの概要は下記の記事を参照ください。

Update Setに変更が記録されるものとされないもの

基本ルール: 設定系のテーブルは記録され、データ・トランザクション系のテーブルは記録されない

Update Setは開発物を記録するための仕組みなので、設定系のテーブルに対する変更は記録されますが、実際の業務の中で作成されるデータ・トランザクションを格納するテーブルへの変更は記録されません。

設定系のテーブルの具体例

Update Setに変更が記録されるのは、メニュー > System Definition > Tablesより確認できる当該テーブルの定義において、Application File[sys_metadata]テーブルを継承しているテーブルです。ただし、各種例外もあるため、不安な場合は実際に設定を行い記録されるかどうかを確認するのが確実です。

具体例は次の通り。

  • Table(テーブル)、Field(フィールド)
  • Access Control(アクセス制御)
  • ビジネスロジック(Business Rule, Script Includeなど)

データ・トランザクション系のテーブルの具体例

  • Incident(インシデント)テーブル
  • Request(要求)テーブル
  • 各種ログレコード

間違えやすいテーブル

基本的には上記の考え方でよいのですが、含まれそうだけど含まれなかったり、逆に含まれなさそうだけど含まれるものがあります。実務でよく使って、かつ迷いやすいレコードを挙げます。なお、これがすべてではありません。

間違えやすい記録されるテーブル

  • ロールの情報を格納するRole[sys_user_role], Contained Role[sys_user_role_contains]テーブル
    ユーザ関連のUser[sys_user], Group[sys_user_group]テーブルなどは記録されませんが、ロールだけは記録されます。なお、ユーザやグループとロールを紐づけるUser Role[sys_user_has_role]及びGroup Role[sys_group_has_role]も記録されません。

  • Report[sys_report]
    … レポートは比較的権限の低いユーザでも作成が可能ですが、記録されます。

  • User Criteria[user_criteria], ナレッジベースとUser Criteriaの紐づきを保持するテーブル(Who Can Read Knowledge Base[kb_uc_can_read_mtom]など)
    … 後述しますが、ナレッジベースは記録されませんがナレッジベースとUser Criteriaの紐づきを保持するテーブルは記録されるため、移送時には注意が必要です。

  • ATFのTest[sys_atf_test], Test Suite[sys_atf_test_suite]
    … ATFのテスト関連テーブルは記録されます

  • Connection & Credential Aliases[sys_alias]
    … 後述しますが、CredentialやConnectionは記録されませんがConnection & Credential Aliasesは記録されることに注意です。

間違えやすい記録されないテーブル

  • Knowledge Base[kb_knowledge_base], Knowledge Category[kb_category], Knowledge Article[kb_article]
    … ナレッジ記事だけでなく、ナレッジベースやナレッジカテゴリも記録されないことに注意です。

  • ATFのTest Result[sys_atf_test_result]
    … ATFのテスト自体は記録されますが、実行結果は記録されません。

  • CI Relationship Type[cmdb_rel_type]
    … CMDB系のテーブルや、CI同士の関係を保持するCI Relationship[cmdb_rel_ci]は記録されませんが、こちらは記録されます

  • Private項目にチェックが付いているSystem Property[sys_properties]の変更
    … Private項目にチェックが付いているSystem Propertyの変更は記録されません。ただし、Private項目にチェックがついていても、System Propertyを新規で作成したときは記録されます

  • Schedule[cmn_schedule], Schedule Entry[cmn_schedule_span]

  • Scheduled Job[sysauto]
    バッチ処理などで使うので設定系にように見えますが、記録されません

  • 外部システムの接続情報を格納するCredential[discovery_credential], Connetion[sys_connection], Identity Provider[sso_properties]
    … 接続先の情報はインスタンスごとに対向システムの接続先も変わることがあるので、これは納得ですね。

  • パスワードポリシーを格納するPassword Policies[password_policy]

カスタムテーブルにおける変更をUpdate Setに記録させる方法

カスタムテーブルを作成する際、他の設定系のテーブルと同様に、開発環境で行った変更を本番環境にUpdate Setで移送したいことがあります。その場合は、テーブル作成時に”Track in Update Sets”をクリックして、Application Fileを継承(拡張)する設定を行います

(非推奨)データ・トランザクション系レコードをUpdate Setに記録する方法

当該テーブルのリストで対象レコードを選択し、”Create Application File”を押下することで、通常はUpdate Setに記録されないレコードをUpdate Setに記録させることができます

ただし、この機能は次の理由で、通常の開発においては使用しないことを推奨します

  • ServiceNow Documentationの記事に記載があるように、この機能は主に外部公開するApplicationにサンプルデータを含めるためのもので、インスタンス間で大量のデータをエクスポート・インポートするためのものではないこと
  • 上記キャプチャでTypeが”Metadata Snapshot”となっていることからもわかるように、Update Set記録後した断面のデータが保持され、記録後に更新した分は反映されないこと

プラグインの有効化は記録されないのでインスタンスごとに行う

忘れやすい事項として、プラグインの有効化はUpdate Setに記録されません。そのため、インスタンス事に行う必要があります。特定のプラグインに依存したUpdate Setを移送する場合は、予め移送先のインスタンスでプラグインを有効化しておきます。

Update Set(更新セット)の中を見てみる

Update Setのの中をもう少し深堀して見てみます。

Update Set(更新セット)は単なるCustomer Updateをまとめる箱

上述の通り、Update Set(更新セット)は単なるCustomer Updateをまとめる箱にすぎません。実際に画面で確認してみると、名前や状態などの管理情報と、記録されているCustomer Update(顧客アップデート)の一覧があるだけです。

Update Setレコード

そのため、ここからはCustomer Updateを深堀していきます。

Customer Update(顧客アップデート)はXMLで表現された一つの開発操作

Customer Update(顧客アップデート)は、開発における一つの操作をXMLで表現したものです。Productテーブルの作成に対するCustomer Updateの確認画面を示します。管理用の名前や作成日、作成者を保持する項目もありますが、最も重要なのはXMLのデータが格納されているPayload項目です。

Payloadを見ると、action=”INSERT_OR_UPDATE”」で新規/更新のUpdateであること、「<label>Product</label>」でテーブル名のラベルが”Product”であること、「<name>u_product</name>」でテーブルの物理名が”u_product”であることが表されている、ということがわかります。

<?xml version="1.0" encoding="UTF-8"?>
<record_update table="sys_db_object">
 <sys_db_object action="INSERT_OR_UPDATE">
   …中略…
   <label>Product</label>
   …中略…
   <name>u_product</name>
   …中略…
   <sys_scope display_value="Global">global</sys_scope>
   <sys_update_name>sys_db_object_d5cc3e7d47f3b010aab57868f36d430d</sys_update_name>
   <sys_updated_by>admin</sys_updated_by>
   <sys_updated_on>2021-11-14 09:41:42</sys_updated_on>
   …中略…
 </sys_db_object>
</record_update>

同じオブジェクトを更新したらCustomer Updateはどうなる?

開発をしていると、一度作ったものを修正する、つまり同じオブジェクトを更新する場合があります。このとき、Update Setはどうなるのでしょう。この場合、同じCustomer Updateが更新されます。つまり、一つのUpdate setの中では、同じオブジェクトに関する情報は最新断面だけが保持されます

「商品の細分化に伴い、商品IDを3桁から10桁に変更した」というシチュエーションにおけるイメージを示します。

オブジェクトを削除したらCustomer Updateはどうなる?

オブジェクトを削除した場合は、削除されたことを表すCustomer Updateが作成されます。同じUpdate Setの中でオブジェクトの作成と削除を行った場合は、削除されたことを表すCustomer Updateだけが残ります。

「商品管理において、価格は履歴を管理することになったため、別テーブルに切り出し、商品テーブルからは価格(Price)カラムを削除した」シチュエーションにおけるイメージを示します。

Updateを消しても当該オブジェクトは消えない

最後に一点補足です。

たまに、誤って設定を変更してしまった場合などに、慌ててUpdate Setに記録されているCustomer Updateを削除しようと考える人がたまにいらっしゃるのですが、これはしてはいけませんUpdate Setに含まれる各Customer Updateは、あくまで当該レコードの最新断面(当該レコードに起こった最後の変更)を保持しているだけであり、仮にCustomer Updateを消したとしても、その操作が取り消されるわけではありません。システムの操作ログを消しても、操作自体が取り消されるわけはない、ということです。

設定を誤って変更してしまった場合は、元に戻す操作を同じUpdate Set内で行い、記録させれば大丈夫です。

設定を誤って削除してしまった場合の復元方法は次の記事で紹介しているので合わせて参照ください。

Update Set移送(資源移送)

Update Setの移送については、下記の記事を参照ください。

以上です。

コメント

タイトルとURLをコピーしました