ServiceNow研究所

ServiceNowで外部システムとファイルを送受信する方法

Sat, 12 Oct 2024 00:00:00 GMT

ServiceNowは、多くの外部システムと連携し、自動化されたワークフローを構築することが可能です。この記事では、外部システムと画像やPDFなどのバイナリファイルを送受信する方法を解説します。

結論

外部システムとのファイルの送受信は、通信の起点、データの所在、送受信時のデータ形式に応じて様々なパターンが存在します。各パターンごとの実現方法を下表に示します。

方式	データ形式	実現方法
ServiceNowから外部システムにファイルを送信する場合通信の起点：ServiceNow ファイルの場所：ServiceNow	バイナリ	・REST Step ・REST Message
	Base64エンコード	・Base64エンコードした上でREST Step or REST Message
	multipart/form-data形式	・REST Step
ServiceNowから外部システムのファイルを取得する場合通信の起点：ServiceNow ファイルの場所：外部システム	バイナリ	・REST Step ・REST Message
	Base64エンコード	・REST Step or REST Messageで受信した上でGlideSysAttachmentでファイルを保存
	multipart/form-data形式	– (送信のための方式なので考慮不要)
外部システムからServiceNowのファイルを取得する場合通信の起点：ServiceNow ファイルの場所：外部システム	バイナリ	・Attachment APIのGET /now/attachmentを利用
	Base64エンコード	・カスタムAPIを利用
	multipart/form-data形式	– (送信のための方式なので考慮不要)
外部システムからServiceNowにファイルを送信する場合通信の起点：外部システムファイルの場所：外部システム	バイナリ	・Attachment API ・Import Set API
	Base64エンコード	・カスタムAPIを利用
	multipart/form-data形式	・Attachment API ・/sys_importset.do

ServiceNowにおける外部システムとのバイナリファイルの送受信方法のまとめ

以下、各パターンにおける具体的なデータの送受信方法について解説します。

前提知識

まず、ServiceNowと外部システム間でファイルをやり取りするために必要な基本的な知識について解説します。

Webシステムにおける画像やPDFなどのバイナリファイルの送受信方法

ServiceNowはWebシステムの一つであるため、まずはWebシステム全般における画像やPDFなどのバイナリファイルを送受信する一般的な方法について説明します。

Webシステム間でHTTP(S)を利用してバイナリファイルをやり取りする際には、主に以下の3つの方法が一般的に使われます。ServiceNowもこれらの方式をサポートしています。

バイナリをそのまま送受信
リクエストボディにバイナリデータを直接設定するシンプルな方法です。
Base64エンコードを使用して送受信
バイナリデータをBase64という方式でテキストに変換して送受信する方法です。この方法ではデータサイズが増えるデメリットがありますが、JSON形式のデータの中に画像などを含めることができるため、多くのAPIで使用されています。
multipart/form-data形式で送受信
フォームデータを送信する際に使われる方式で、複数のテキストやファイルを同時に送信できます。リクエストボディを区切り文字で複数の部分に区切ってテキストやファイルを指定するため、multipartと呼ばれます。ファイルを含める場合は、バイナリデータはエンコードされず、そのまま送信されるのが一般的です。

なお、システム間でファイルを転送する際にはFTP(SFTP)も利用されることがあります。ServiceNowでは、MIDサーバやRPAの機能を用いてローカルシステムとファイルをやり取りする際にFTP(SFTP)を利用することもできますが、本記事では対象外とします。

ServiceNowにおいて外部システムと通信する方法

ServiceNowでは、外部システムとの通信を行うために、いくつもの方法が用意されています。ここでは、それらのうち主要な方法について解説します。

ServiceNowが通信の起点となる場合：REST Step or REST Message

ServiceNowから外部システムにリクエストを送る場合、主にFlow（ワークフロー機能）の中で使用するREST step、もしくはスクリプトから直接呼び出すREST Messageを利用します。

方式	概要	備考
REST step	ノーコードで外部システムとのシステム連携を構築するための機能	・Flowの一部として組み込むことで、簡単に外部連携が構築可能・使用にはIntegration Hubのライセンスが必要（トランザクション単位の課金）*1
REST Message	スクリプトを使用して外部システムと連携する機能	・コーディングが必要で、開発の難易度が高い・ServiceNow標準の機能であり、トランザクション単位の課金は発生しない

ServiceNowが通信の起点となる場合の外部連携方法

*1 課金体系については2024年Xanaduバージョン現在のものです。今後変更される可能性があるため注意してください。

外部システムが通信の起点となる場合：標準公開API or カスタムAPI

外部システムが通信の起点となる場合、ServiceNowでは標準で提供されているAPIか、カスタムAPIを利用して通信を行います。

方式	概要	備考
標準公開されているWeb API	ServiceNowが標準で提供する外部公開API	・システムアカウントを発行するだけで利用可能で、開発作業は不要
カスタムAPI	スクリプトを使って独自のAPIを作成し、外部システムに公開する	・スクリプト作成が必要で開発の難易度が高い・自由度が高く、柔軟な実装が可能

外部システムが通信の起点となる場合の外部連携方法

IP制限がかかったネットワーク内に外部システムが存在する場合はMID Serverを介して通信

外部システムが通信の起点となる場合は基本的には問題ありませんが、ServiceNowが通信の起点となる場合は、外部システムがIPアドレス制限などの通信制限を行っているケースがあります。ServiceNowインスタンスから直接アクセスできない内部ネットワークに外部システムが存在する場合はMID Serverを介して通信を行う必要があります。詳細については、次の記事を参照ください。

ServiceNow - MIDサーバーってなに？

ServiceNowにおけるファイルの保管方法

ServiceNowにはGoogleドライブ・Oneドライブ・Boxのようなファイルスを単体で格納するためのトレージは存在せず、ファイルは特定のレコードに対する添付ファイルとして保存されます。GUI上でも、ストレージのような場所にファイルをアップロードするのではなく、「特定のレコードに添付する」という形でファイルをアップロードします。

データベース上では以下の2つのテーブルに分けて格納されます。

Attachment（添付ファイル） [sys_attachment]
ファイル名、サイズ、拡張子といったメタデータを保管します。
Attachment Document（添付ドキュメント） [sys_attachment_doc]
ファイルの実体そのものを保存します。ファイルサイズが大きい場合は、1つの添付ファイルが複数のレコードに分割されて保存されます。

ファイルをスクリプトから操作する際はGlideSysAttachmentを使用

上述のように、添付ファイルは複数のテーブルにまたがって、かつ必要に応じて分割して保管されているため、スクリプトから操作する際には、Attachment（添付ファイル）を操作するためのAPI(クラス)であるGlideSysAttachmentを利用します。このAPIを利用することで、ファイルの取得や作成が可能です。

ここまでが前提知識です。以降はパターンごとの外部システムとの添付ファイルの送受信方法について解説します。

ServiceNowから外部システムにファイルを送信する場合

バイナリ

REST step、またはREST Messageを用いてバイナリを直接外部システムに送信することができます。

REST stepを用いる方法

REST stepの設定において、HTTP Methodを”POST”に、Request Typeを”Binary”を選択すると、指定したAttachment（添付ファイル）レコードのバイナリデータをリクエストボディに設定することができます。

図では簡単のためAttachmentレコードを直接指定しましたが、一般的には事前に”Get Attachments on Record”アクションなどで取得したAttachmentのSysIDを渡すことになります。

REST Messageを用いる方法

RESTMessageV2.setRequestBodyFromAttachment()を用いることで、指定したAttachment（添付ファイル）レコードのバイナリデータをリクエストボディに設定することができます。使い方はシンプルで、AttachmentレコードのSysIDを引数に渡すだけです。

RESTMessageV2.setRequestBodyFromAttachment()の使い方

var request = new sn_ws.RESTMessageV2();
// requestのエンドポイント、メソッド、ヘッダ等を設定
request.setRequestBodyFromAttachment('<attachment sys_id>');
response = request.execute();

Base64エンコード

Base64エンコードしたファイルを送信する必要がある場合は、事前にスクリプトでファイルをBase64エンコードした文字列を取得した上で、REST stepやREST Messageに渡します。ただし、Base64エンコードしたファイルの取得方法はがスクリプトをScopedで書く場合とGlobalで書く場合で異なる点に注意が必要です。

ScopedでBase64エンコード済みファイルを取得する方法

Scopedの場合は比較的シンプルで、GlideSysAttachment.getContentBase64()を使ってBase64エンコードされたファイルを取得できます。以下に、指定されたインシデントレコードに添付されたファイルをBase64形式で取得し、JSON形式のペイロードを作成するコード例を示します。

ScopedでBase64エンコード済みファイルを取得する方法

var incidentSysID = 'インシデントレコードのSysID';
var gsa = new GlideSysAttachment();
var attachments = gsa.getAttachments('incident', incidentSysID); // Get attached file(s)
var payload = [];

while (attachments.next()) {
    var fileName = attachments.getValue('file_name'); // Get file name of attachment
    var attachmentContent = gsa.getContentBase64(attachments); // Get attachment content in Base64
    
    payload.push({
        'filename': fileName,
        'contentBase64': attachmentContent
    });
}

gs.info(JSON.stringify(payload));

GlobalでBase64エンコード済みファイルを取得する方法

Globalでは、GlideSysAttachment.getContentBase64()が利用できず、”undefined”を返してしまいます。そのため、Scopedで作成したScript Includeを介して取得することを推奨します。

なお、Community等で調べると、次のようにGlideSysAttachment.getBytes()とGlideStringUtil.base64Encode()を使用してGlobalでBase64エンコード済みファイルを取得する方法が紹介されていますが、これらは公式にドキュメント化されていないAPIであるため、基本的には使用しない方がよいでしょう。

GlobalでBase64エンコード済みファイルを取得する方法

var incidentSysID = 'インシデントレコードのSysID';
var gsa = new GlideSysAttachment();
var attachments = gsa.getAttachments('incident', incidentSysID); //create attachment GlideRecord
var payload = [];

while (attachments.next()) {
    var fileName = attachments.getValue('file_name'); // Get file name of attachment
    var attachmentContent = GlideStringUtil.base64Encode(gsa.getBytes(attachments)); // Encode attachment content in Base64
    
    payload.push({
        'filename': fileName,
        'contentBase64': attachmentContent
    });
}

gs.info(JSON.stringify(payload));

multipart/form-data形式

multipart/form-data形式でファイルを送信する場合、REST stepを使用します。REST stepにおいて、HTTP Methodを”POST”に、Request Typeを”Multipart”を選択すると、Multipartを構成するUIが表示されます。このUIで(+)ボタンを押してPart Typeを”File”とすることで、ファイルを添付して送信することができます。

一方で、REST Messageではmultipart/form-data形式のリクエストを作成するためのメソッドが存在せず、次の理由から恐らく実現は困難です。

バイナリデータの扱いが困難
REST Messageでは、ペイロードにバイナリデータを直接含める必要がありますが、ServiceNowではスクリプト内でバイナリデータを直接扱う、公式にドキュメント化されたAPI(クラス)が存在しません。
リクエストボディの型の制約
仮にペイロードを作成できたとしても、RESTMessageV2.setRequestBody()はString型しか受け付けません。

実現方法をご存じの方がいれば、コメントでご教示いただければと思います。

ServiceNowから外部システムの中のファイルを取得しに行く場合

バイナリ

REST stepまたはREST Messageを用いて、外部システムのファイルをバイナリで返すAPIやファイルをダウンロードするエンドポイントにアクセスし、その結果であるファイルをAttachmentテーブルに格納することができます。

REST stepを用いる方法

REST stepの設定において、Save As Attachmentにチェックを入れた上で、ファイルを添付するレコードを指定します。

REST Messageを用いる方法

RESTMessageV2.saveResponseBodyAsAttachment()を用いることで、レスポンスのバイナリデータを指定したレコードの添付ファイルとして保存することができます。

コード例は以下の通りです。レスポンスのオブジェクトに対してこのメソッドを呼び出すのではなく、リクエストを行うRESTMessageV2インスタンスに対してこのメソッドを呼び出した上でリクエストのを行う（execute()メソッドを呼ぶ）ことに注意です。

RESTMessageV2.saveResponseBodyAsAttachment()でレスポンスのバイナリデータをAttachmentテーブルに格納

var request = new sn_ws.RESTMessageV2();
// requestのエンドポイント、メソッド、ヘッダ等を設定
request.saveResponseBodyAsAttachment(tablename, recordSysId, filename);        
response = request.execute();

Base64エンコード

外部システムからBase64エンコードされたバイナリファイルが返ってくる場合は、レスポンスボディからBase64エンコード済みのファイル部分を取り出した上でスクリプトを用いて保存します。

Base64エンコード済みのファイルの保存取得方法はがスクリプトをScopedで書く場合とGlobalで書く場合で異なる点に注意が必要です。

ScopedでBase64エンコード済みファイルを保存する方法

Scopedの場合は、GlideSysAttachment.writeBase64()を用いることでBase64エンコード済みファイルをAttachmentテーブルに保存することができます。て保存します。

例として、ファイル名、ファイルタイプ、Base64エンコード済みのファイルの中身を含むペイロードが取得できた前提で、そのファイルを指定されたインシデントレコードに添付するコードを示します。

ScopedでBase64エンコード済みファイルを保存する方法

var incidentSysID = 'インシデントレコードのSysID';
var incident = new GlideRecord('incident');
incident.get(incidentSysID);

var gsa = new GlideSysAttachment();

var payload = { // このような形式のpayloadが取得できていると仮定
    'fileName': 'example.png',
    'contentType': 'image/png',
    'contentBase64': 'iVBORw0KGgoAAAANSUhEUgAA...==' // Example Base64 encoded content
};

// Write the Base64 encoded content as an attachment
var attachmentSysID = gsa.writeBase64(incident, payload.fileName, payload.contentType, payload.contentBase64);

gs.info('The attachment sys_id is: ' + attachmentSysID);

GlobalでBase64エンコード済みファイルを保存する方法

GlobalではwriteBase64()が利用できず、またドキュメント化されたメソッドも無いため、ScopedなScript Includeを介して実現します。

簡単にできる方法をご存じの方がいたらコメントをください。

外部システムからServiceNowの添付ファイルを取得する場合

バイナリ

外部システムからServiceNowの添付ファイルをバイナリで取得する場合は、標準で外部公開されているAttachment APIを利用します。

添付ファイルの取得：GET /now/attachment/{sys_id}/file

エンドポイント”GET /now/attachment/{sys_id}/file”を用いることで、添付ファイルをバイナリファイルとして取得することができます。

curlコマンドの例を示します。

GET /now/attachment/{sys_id}/fileの使用例

curl "https://<インスタンス名>.service-now.com/api/now/attachment/<AttachmentレコードののSysID>/file" \
 -u <認証情報> \
 -o "test.png"

このエンドポイントではAttachmenレコードのSysIDが必要となりますが、多くのユースケースでは、番号やSysIDが分かっているレコードから、そのレコードに添付されたファイルを取得します。そのため、次のエンドポイントとセットで利用されることが多いです。

メタデータの取得・検索：GET /now/attachment

“GET /now/attachment”を利用することで、Attachmentテーブルに格納されている添付ファイルのメタデータ（SysID、ファイル名、ファイルの種類、添付先のレコードなど）の一覧を取得することができます。

多くの場合、URLクエリパラメータ”sysparm_query”を利用してレコードのSysIDからそのレコードに添付されたファイルを検索するために利用します。

例として、インシデントレコードに添付されているファイルのメタデータを取得するcurlコマンドを示します。

GET /now/attachmentの使用例

curl "https://<インスタンス名>.service-now.com/api/now/attachment?sysparm_query=table_name%3Dincident%5Etable_sys_id%3D<インシデントレコードのSysID>" \
 -u <認証情報>

Base64エンコード

ServiceNowからBase64エンコードされたファイルを取得するための標準APIは提供されていません。そのため、外部システム側でBase64エンコードを行うか、Scripted REST API等を用いてエンドポイントを作成する必要があります。

エンドポイントを自作する場合は、上述のScopedでBase64エンコード済みファイルを取得する方法及びGlobalでBase64エンコード済みファイルを取得する方法を参照ください。

外部システムからServiceNowにファイルを送信（アップロード）する場合

バイナリ

外部システムからServiceNowにバイナリファイルを直接アップロードする場合に利用できるのが、Attachment APIのエンドポイント”POST /now/attachment/file”です。クエリパラメータでファイル名、添付先テーブル、添付先レコードのSysIDを指定し、リクエストボディにバイト列を書き込みます。

インシデントレコードにファイルを添付するcurlコマンドの例を示します。

curl -X POST "https://<インスタンス名>.service-now.com/api/now/attachment/file?file_name=<ファイル名>&table_name=incident&table_sys_id=<インシデントレコードのSysID>" \
 -u <認証情報> \
 -H "Content-Type: image/png" \
 --data-binary @test.png

Base64エンコード

外部システムからServiceNowにBase64エンコード済みのファイルを直接アップロードできる標準APIは提供されていません。そのため、外部システム側でバイナリ変換を行うか、Scripted REST API等を用いてBase64エンコード済みファイルを受け付けることができるエンドポイントを作成する必要があります。

エンドポイントを自作する場合は、上述のScopedでBase64エンコード済みファイルを保存する方法を参照ください。

multipart/form-data形式

外部システムからServiceNowにmultipart/form-data形式でファイルをアップロードする方法は、用途に応じて複数そんざいします。

Attachment API – POST /now/attachment/upload

汎用的に利用できるのが、Attachment APIのエンドポイント”POST /now/attachment/upload”です。

curlコマンドの例を示します。バイナリを直接送信する/fileとは異なり、ファイル名や添付対象レコードの情報は、マルチパートデータ内に含めます。

curl -X POST "https://<インスタンス名>.service-now.com/api/now/attachment/upload" \
 -u <認証情報> \
 -H "Content-Type: multipart/form-data" \
 -F "table_name=incident" \
 -F "table_sys_id=<インシデントレコードのSysID>" \
 -F "file=@test.png"

なお、ファイルを表すパートの名前の指定は無いようです。また、ファイルを複数添付しても初めの一つしかアップロードされませんでした。そのため、恐らく最初にアップロードされたバイナリのインプットを添付ファイルとして認識する仕様になっているようです。

Import Setを用いてExcelやCSVファイルを取り込ませたい場合は /sys_importset.do

従業員データの取り込みなど、ExcelやCSV形式のファイルを特定のテーブルにImport Setを経由して取り込ませたい場合はエンドポイント”/sys_importset.do”を利用します。

例として、Import Set “Sys UI Message”とTrasnform Map “Sys UI Message Transform Map”を用いて、Messageテーブルの翻訳をインポートするcurlコマンドを示します。

curl -X POST "https://<インスタンス名>.service-now.com/sys_import.do?sysparm_import_set_tablename=u_sys_ui_message&sysparm_transform_after_load=true" \
 -u <認証情報> \
 -H "Content-Type: multipart/form-data" \
 -F "file=@sysuimessagedata.xlsx"

sysparm_transform_after_load=trueとすることで、ファイルがアップロード後にTransform Mapを用いたデータの登録までを1回のリクエストで行うことができます。

このAPIは、XMLやJSON形式に変換してデータを送信する必要のあるImport Set APIと比べ使い勝手が良い反面、エラーハンドリングが不十分であることに注意が必要です。例えば、以下のような状況でも、200 – OKというステータスが返ります。

存在しないImport Set名を指定した場合
誤ったファイル形式（例: 画像ファイル）を送信した場合

また、成功した場合でも、リクエストボディは空で成否判定もできません。そのため、Transform Mapのログを定期的に確認するなど、エラーハンドリングや結果確認を補完する処理とセットで利用することを推奨します。

以上です。

ServiceNow – 開発者・管理者必見! SN Utilsの概要・使い方

Tue, 10 Sep 2024 00:00:00 GMT

ServiceNow開発者・管理者用便利ツールである SNUtilsの概要や使い方を説明します。

SN Utilsとは

SN UtilsとはServiceNow開発者・管理者の作業効率を飛躍的に向上させる非公式のブラウザ拡張ツールです。開発者はServiceNow従業員のArnoud Kooiであり、2024年8月時点でも更新が続いています。非公式ながらその便利さが認められ、ServiceNowのDeveloperブログやYoutubeチャンネルでも紹介されています。

インストール方法

拡張機能/アドオンとして各ブラウザに追加します。対応ブラウザはChrome, Safari, Firefox, Edgeの4つです。
以下、各ブラウザのインストールリンクです。
Chrome / Edge / Firefox / Safari

インストール後、各ServiceNowインスタンスにログインした状態でSN Utilsが自動で機能するようになります。

主な機能

SN Utilsには数多くの便利機能がありますが、その中でも筆者がよく利用する機能について紹介します。なお、筆者はWindows OSにてChrome版のSN Utilsを使用しています。

スラッシュコマンド（Slashcommands）

インスタンスを開いている状態でスラッシュキー(“/”)を押すと、以下のスラッシュコマンド画面が表示されます。この画面に様々なコマンドを入力することで、作業を大幅に効率化させることができます。

個人的によく使うスラッシュコマンドを説明します。どれも日々の生産性を高め、ServiceNow開発を非常に快適にさせてくれます。

言語切り替え

/lang <言語>で、インスタンス言語を変更することができます。

プロパティ検索

/p <検索したい文字列> で、検索したい文字列を含むプロパティを検索することができます。/pのみの場合、プロパティテーブルを開きます。

ユーザ検索

プロパティ検索と同様に、/u <検索したい文字列>で、ユーザを検索することができます。

プロパティ・ユーザと同様に、ビジネスルール(/br)、UIアクション(/ua)、UIポリシー(/up)、スクリプトインクルード(/si)、クライアントスクリプト(/cs)も検索可能です。

レコード検索

/<SysID>で、該当SysIDを持つレコードの検索が可能です。スクリプトやシステムプロパティにSysIDが直接入力されているレコードを確認したいときに便利です。

フォームの必須項目を入力

/rnd で、フォーム画面の必須項目を自動入力します。テスト時や、さっとレコードを作成したいときに、非常に重宝します。
開発者であるArunodお気に入りの機能だそうです。

Docs検索

/docs <検索したい文字列>でServiceNow Docsの記事検索ができます。同様に、/apiではServiceNow DevelopperでAPIを、/commではServiceNow Communityでコミュニティ記事を検索できます。

バックグラウンドスクリプトに遷移

/bgで、バックグラウンドスクリプトを開きます。SN Utilsをインストールすることでバックグラウンドスクリプトも改良され、エディタが黒背景に、スクリプトの実行結果が画面右に出力されるようになります。

また、/bgcで、今開いているレコードをGlideRecordで取得するスクリプトが自動的に入力された状態で、バックグラウンドスクリプトを開くことができます。

GlideRecordについては以下の記事で詳しく解説しています。あわせてご覧ください。

ServiceNow - GlideRecordのイメージと使い方　図解解説

今回紹介したスラッシュコマンドを一覧にまとめておきます。

コマンド	説明	例
/lang <言語コード>	インスタンス言語を切り替える	/lang ja
/p <検索したい文字列>	プロパティを検索する	/p home
/u <検索したい文字列>	ユーザを検索する	/u admin
/br <検索したい文字列>	ビジネスルールを検索する
/ua <検索したい文字列>	UIアクションを検索する
/up <検索したい文字列>	UIポリシーを検索する
/si <検索したい文字列>	スクリプトインクルードを検索する
/cs <検索したい文字列>	クライアントスクリプトを検索する
/<SysID>	SysIDからレコードを検索する
/docs <検索したい文字列>	Docsの記事を検索する	/docs GlideRecord
/api <検索したい文字列>	DeveloperサイトのAPIリファレンスを検索する	/api g_form
/comm <検索したい文字列>	コミュニティ記事を検索する	/comm GlideAjax
/rnd	フォーム画面で必須項目を自動入力する	–
/bg	バックグラウンドスクリプトを開く	–
/bgc	開いていたレコードを取得するスクリプトが入力された状態のバックグラウンドスクリプトを開く	–

よく使うスラッシュコマンド

項目名表示（Technical Names）

フォーム画面の白い部分をダブルクリックすることで、フィールドラベルの横にフィールド名を表示させることができます。各フィールドの内部名を確認したいときに非常に便利です。
また、Referenceフィールドは、フィールド名をクリックすることで、参照元となるテーブルのリスト画面を表示可能です（リスト画面でも同様に余白をダブルクリックすることで、フィールドの項目名を表示することが可能です）。

さらに、ヘッダー部分のリンクをクリックすることで、Scratchpadの値や、拡張元を含む各テーブルのフィールドがフォーム画面上に表示されているか・されていないか・表示されているが何らかのスクリプト等で隠されているかを確認することができます。

なおこれらの情報は/tn スラッシュコマンドでも表示させることができますが、筆者はダブルクリックでいつも表示させています。

ポップアップタブ（Pupup tabs）

拡張機能のアイコンをクリックすることで、ポップアップタブを開くことができます。こちらにも様々な便利機能が用意されています。

以下、個人的によく利用するポップアップタブの機能を紹介します。

UpdateSet

現在のアプリケーションスコープにおける利用可能なUpdateSetの一覧を表示し、UpdateSetの切り替えや新規作成、各UpdateSetの定義画面へ遷移することができます。

UpdateSetについては以下の記事で詳しく解説しています。あわせてご覧ください。

ServiceNow - Update Set（更新セット）の図解解説

Update Set（更新セット）移送に関する注意点・Tips

Tables

テーブル名を検索し、リスト画面やテーブル定義を表示することができます。特に、作成したカスタムテーブルのリスト画面を表示したいときに重宝します。

その他

その他、筆者が利用している便利機能を紹介します。

スコープ・アプリケーションの確認・変更

地球儀アイコンの左に、現在のアプリケーションスコープやUpdateSetが表示されます。クリックすることで、それらを変更することができます。UpdateSet切り替えミスの防止に繋がると共に、切り替えのステップを短縮できます。

また、現在のアプリケーションスコープと異なるスコープで作成されているレコードを開いた際、通常で表示されるスコープ変更リンクをクリックしても一時的にしかスコープが変更されませんが、SN Utilsで表示されるリンクをクリックすると、該当するスコープへ永続的に切り替えることができます。

フォーム保存がショートカットで実行できる

以下のショートカットで、いちいちUpdateやSaveのUI Actionをクリックせずに、レコードの保存が可能です。

Ctrl+S：フォームの保存
Ctrl+Shift+S：レコードを挿入して維持（Insert and Stay）

リスト画面に特定の項目を瞬時に表示させる

リスト画面の歯車マーク右に表示されているアイコンをクリックすることで、特定の項目（初期設定では更新日時、更新者、作成日時、アプリケーション）を瞬時にリスト画面に表示させるようパーソナライズすることができます。最新のレコードや自分が開発していたレコードを確認するために、リスト画面を更新日時でソートしたい。が、リスト画面に更新日時フィールドが表示されていない…なんて時にとても役立ちます。

表示させる項目は、ポップアップタブのSettingsでカスタム可能です。

インスタンスごとにタグを表示する

ポップアップタブのSettingsタブで「Enable Instance Tag」をチェックすることで、インスタンス毎にタグを表示させることができます。タグは色やサイズ、配置場所等を細かく設定できるため、開発環境、テスト環境、本番環境の区別を強調し、操作環境ミスを減らすことができます。
タグの表示/非表示は/itt スラッシュコマンドで変更できます。

※ただし筆者は、以前から愛用していたEnvironment Indicatorという別の拡張機能を使用しています。

Environment Indicator - Chrome ウェブストア

使用にあたっての注意

画面やDOMに影響を与えるものであるため、クライアント系の動作テストやユーザマニュアル作成時、ベンダーの方はクライアントへのデモ披露時には念のためSN Utilsをオフにすることを推奨します。

その他、SN Utilsには様々な便利機能が備わっています。LinkedInやX（旧Twitter）アカウントでもTipsが随時投稿されているので、是非チェックしてみてください。
今回は以上です。

Update Set（更新セット）移送に関する注意点・Tips

Sun, 01 Sep 2024 00:00:00 GMT

ServiceNowのUpdate Set（更新セット）をインスタンス間で移送する際の注意点やTipsを共有します。なお、Update Set自体については「ServiceNow – Update Set（更新セット）の図解解説」を、ServiceNowにおける開発資源の移送全般については「ServiceNowにおける開発・資源移送（デプロイ）の全体像」を併せて参照ください。

開発時・移送前

Update Set（更新セット）に記録されない変更に注意

Update Set（更新セット）には全ての変更が記録されるわけではありません。基本的な考え方として、設定系のテーブルは記録され、データ・トランザクション系のテーブルは記録されないことを覚えておきましょう。

また、開発者からみると移送されるべきと考えられる変更の中に、一部Update Setに記録されないものがあります。これらの変更は、レコードをXML形式でエクスポート・インポートする機能を使って移送します。

詳細は次の記事で詳しく解説しているので、併せて参照ください。

ServiceNow - Update Set（更新セット）の図解解説

Update Set（更新セット）への記録漏れに注意

移送対象のUpdate Set（更新セット）に記録すべき変更が、”Default” Update Setや、移送予定のない無関係なUpdate Setに含まれていると、機能を正しく移送することができません。特に、Service Portal、Employee Centerの開発・変更を行う場合などで、複数のアプリケーションスコープをまたいで開発を行う場合に漏れやすいです。

開発者各自が注意を払うべきですが、記録漏れを完全に防ぐのは難しいため、Update SetをComplete状態に変更する前に、以下の手順で必ず確認を行いましょう。

Customer Update（顧客アップデート）テーブルのリストを開く
メニューに”sys_update_xml.list”と打ち込むことでリストを開くことができます

開発を行った期間、および開発者のユーザで絞りこむ

適切なUpdate Setに含まれていることを確認する
この時、Update Setを明示的に指定していない場合に指定される”Default” Update Setになっている場合は漏れている可能性が高いです

Update Set（更新セット）への記録漏れを発見した場合

更新セットへの追加が漏れていた場合は、細心の注意を払いつつCustomer Update（顧客アップデート）レコードのUpdate Setフィールドの値を修正し、適切なUpdate Setに記録されるようにします。

なお、適切なUpdate Setを選択した状態で再度更新を行う方法もありますが、この場合、対象レコードを意図的に変更してから元に戻すなどの操作が必要となり、操作ミス（二次被害）を誘発する可能性があります。また、”Default” Update Setなどにゴミが残るため、個人的には上述の方法を推奨します。

誤ったUpdate Set（更新セット）への記録に注意

Update Setへの記録漏れに加え、誤ったUpdate Setに変更を記録してしまうことにも注意が必要です。確認方法と対応は、上述の記録漏れの場合と同様です。

ただし、誤って記録したUpdate Setが、本来記録されるべきUpdate Setと同時に移送する予定のUpdate Setである場合、後述のUpdate set batching機能を利用することで、複数のUpdate Setを一つのUpdate Setであるかのように扱うことができ、問題なく移送できます。そのため、開発資源の管理の観点で適切なUpdate Setに必ず含めたいということでなければ、リスクを冒して正しいUpdate Setに移し替える必要はなく、そのまま放置することも一つの選択肢です。

移送時

プラグインは移送先の環境で事前に有効化する

プラグインは各環境で個別に有効化する必要があります。開発環境で有効化したプラグインが前提となるUpdate Setを、プラグインが有効化されていない移送先の環境に適用すると、エラーが発生する可能性があります。これを防ぐため、移送先の環境でも同じプラグインを事前に有効化しておきます。

他の環境から直接Update Setを取得する場合はユーザの認証設定に注意

「ServiceNowにおける開発・資源移送（デプロイ）の全体像」でも解説しているように、Update Setの移送には、次の2つの方法があります。

本番インスタンス側で開発インスタンスの情報（URLや管理者権限を持つアカウントのID・パス）を設定し、Retrieve（取り込み）を行う
開発インスタンスからUpdate SetをXMLファイルとしてエクスポートし、それを本番インスタンスにアップロードする

前者の方法を採用する場合、開発インスタンスのユーザ情報を設定する際に以下の点に注意が必要です。

ユーザの2FAが有効になっている場合
ServiceNowの2段階認証が設定されていると、パスワードの末尾にワンタイムパスワードを追加します。パスワードのみを入力すると認証エラーとなります。
ユーザのパスワードリセットが強制されている場合
Update Set用に作成したユーザが一度もログインしていない場合などでパスワードリセットが強制されている（”Password needs reset” フィールドにチェックが入っている）と、エラーが発生します。

Update Set同士の依存関係はUpdate set baching機能で解消可能

複数のUpdate Setに依存関係がある場合、依存元のUpdate Setを依存先より先に、または同時に移送する必要があります。

ただし、依存関係にある複数のUpdate Setを同時に移送する場合、Update Setに親子関係を持たせることで、親のUpdate Setを移送すれば子も含めて一括で移送できる Update Set batching 機能を利用することが可能です。この機能を使うことで、依存関係を意識する必要がなくなります。

Update SetとXML移送の依存関係は特に注意する必要はない

Update SetとXML移送の依存関係については、基本的に大きな注意を払う必要はありません。

例えば、タスクのアサインを自動決定するためのAssignment Data Lookup設定と、そのアサイン先のグループ設定を考えた場合、グループ設定はUpdate Setに記録されないため、XMLで移送する必要があります。

この状態でLookup設定を先にUpdate Setで移送した場合、たとえAssignment Groupフィールドで指定しているグループのレコードが存在しなくても、フィールドの内部的な値であるSysIDは正しく移送されます。そのため、XMLを用いてSysIDを維持したままグループを後から移送すれば、結果的に正しく紐づきます。

ただし、グループを移送するまでは、Assignment Groupフィールドが設定画面上で空白に見える（＝設定されていないように見える）ため、基本的には依存元のデータ（XML）を先に移送することを推奨します。

この考え方は、XML移送するデータ間の依存関係にも同様に適用されます。

Preview（プレビュー）は事前に実施する

Update Setの移送は次の3ステップで行います。特に利用ユーザのログインを止めたり、システムメンテナンスとして事前周知を行った上で行う移送の場合、Preview（プレビュー）までは作業日よりも前に完了させておき、作業当日に行うのはCommit（コミット）だけにしましょう。

Update Setの移送（資源移送）　…　開発環境から検証・本番環境にUpdate Setを移送する
Preview（プレビュー）　…　Update Setを適用した場合に、既存の設定との衝突等がないかを確認する
Commit（コミット）　…　Update Setに含まれる変更を実際に適用する

Previewで問題が発覚した場合の対応

Previewで問題が発覚した場合、次の2つの対応方法があります。それぞれにメリットとデメリットがあるため、原因や状況に応じて使い分けます。

Update Setを修正して移送し直す
移送先の環境からRemote Update Set（リモート更新セット）を削除し、移送元環境でUpdate Setを修正して、再度移送します
Update Setを適用した上で、修正用のUpdate Setを追加移送する
問題のあるUpdate Setを適用、もしくは適用をスキップしてCommitした上で、修正用のUpdate Setを追加で移送します

移送後

移行後に注意すべき点は、移送元環境と移送先環境で異なる設定が必要な場合の設定漏れです。

外部連携（IF）における接続情報の変更漏れに注意

外部システムとの連携を行う場合、通常、ServiceNow側と対向システム側の双方に開発、ステージング、本番といった複数の環境が存在することがあります。

ServiceNowの移送元と移送先で接続する対向システムの環境が異なる場合は、移送後に手動で接続情報を変更しましょう。

Privateなシステムプロパティの設定漏れに注意

PrivateなSystem Property（システムプロパティ）の設定はそのインスタンスのみで有効な設定となり、別のインスタンスに移送されません。そのため、移送後に手動で設定を行う必要があります。

代表例はインスタンスのメール送信可否（メール送信On/Off）を制御するSystem Property “glide.email.smtp.active”で、設定が漏れるとメール通知が送信されない、といった障害に繋がります。

詳細は下記の記事をご確認ください。

ServiceNowのSystem Property（システムのプロパティ）とは何か

Update Setの移行で失敗しないために

これまで説明してきたように、Update Setの移送には多くの注意点があります。移行の失敗を避けるために、開発段階で以下の3つのドキュメントを作成し、注意が必要なポイントに気づき次第メモしておくことをお勧めします。

Update Set一覧
移送すべきUpdate Setの一覧と、依存関係を整理したもの。
XML移送対象一覧
Update Setには記録されずXMLで移送する対象の一覧。テーブル名やデータのフィルタ条件などを記載。
プラグイン一覧
プラグインと、それがどの環境で有効化されているか、または有効化する予定かを記録。
システムプロパティ一覧
利用するシステムプロパティの一覧と、環境ごとの値を記録。
移行手順書
Update SetやXMLの移送手順、移送後に手動で設定すべき項目についての手順を記載。

以上です。移送の成功率が少しでも上がれば幸いです。

ServiceNow – Auto-numbering(自動採番)の解説

Sun, 25 Aug 2024 00:00:00 GMT

ServiceNowにおいて、レコードの自動採番を行うための仕組みであるauto-numbering(自動採番)、もしくはNumber Maintenance(番号メンテナンス)機能について解説します。

Auto-numbering(自動採番)機能の基本

概要

Auto-numbering(自動採番)機能を使用すると、レコードに「接頭辞 + 0埋め連番」の形式で番号を自動的に付与できます。例えば、Incident(インシデント)テーブルには「INC」という接頭辞と7桁の0埋め連番が設定されています。

自動採番の設定はServiceNow上の各テーブル単位で行われます。例えば、Request(要求)テーブルであれば、依頼や要求の種別にかかわらず、共通の接頭辞と連番で番号が設定されます。

また、システムによっては「番号の上2桁を西暦にする」といった有意コードが採用されることがありますが、ServiceNowでは、接頭辞による最低限の意味付けはあるものの、それ以上の意味は持たない無意コードが採用されています。

構成要素

Auto-numbering(自動採番)は、次の要素で構成されています。

Number(番号)テーブル　…　各種テーブルの採番ルール（接頭辞、桁数、最初の番号）を管理
Number Counter(数カウンタ)テーブル　…　各テーブルの自動採番における連番部分の現在の値を管理
採番ロジック　…　Numberテーブルの定義とCounterテーブルのカウンターの値を用いて自動採番を行うロジック

Incident(インシデント)テーブルを例に、番号処理ロジックの動作を図示すると、次のようになります。

Auto-numbering(自動採番)の設定方法

ServiceNowでは、Incident(インシデント)やRequest(要求)などの主にトランザクションデータを格納する多くのテーブルには標準で自動採番が設定されています。しかし、マスタデータを格納するテーブルや新規に作成したカスタムテーブルには、標準で自動採番が設定されていません。ここでは、既存テーブルおよび新規テーブルに自動採番を設定する方法を説明します。

既存テーブルへの自動採番設定

既存のテーブルに自動採番を設定するには、以下の手順を実行します。

自動採番の設定

メニュー > System Definition > Number Maintenanceを開き、”New”ボタンをクリックして新しい設定を作成します

対象テーブル、接頭辞、連番の最初の値、連番の桁数を設定します

接頭辞は空白にして、接頭辞無しの連番で設定することも可能です
連番の最初の値の初期値は1,000です。これは、連番が小さい場合に0が多く連続することを避け、可読性を高めるためだと思われます（例：7桁の場合、初期値が1だと”0000001″のように0が続く）

番号フィールドの作成（自動）

Number(番号)の設定が正常に送信されると、次のメッセージが表示され、対象テーブルにNumber[u_number]フィールドが作成されます。

Default Valueに設定されているスクリプトが、採番ロジックを呼び出す設定です。

動作の確認

Numberフィールドをフォームに表示し、メニュー > Organization > Companiesを開いて”New”をクリックして新しいレコードを作成します。これにより、Numberフィールドに採番されたことを確認できます。

新規テーブル作成時の自動採番設定

新規テーブルの場合は、テーブル作成画面のControlsタブでAuto-numberを設定します。これにより、テーブル作成と同時に自動採番の設定が行われます。

フィールド名のカスタマイズ

前述の設定方法では、自動でNumber[u_number]フィールドが作成されます。フィールド名を自分で定義したい場合は、Number(番号)テーブルの設定を行う前に、採番ロジックを呼び出す設定をしたフィールドを作成しておきます。

Default value

javascript:global.getNextObjNumberPadded();

(補足1) global.getNextObjNumberPadded();は、この記事で紹介している過去の遺物であるGlobal Business Ruleの”getNextObjNumberPadded”内で定義されています。

(補足2) コードを書かずに次のように設定することもできます。Task(タスク)テーブルのNumber[number]フィールドはこのような設定になっています。

必要に応じて：設定後に連番の値を直接変更する

自動採番の設定後に現在の番号を変更したい場合は、Number Counter(数カウンタ)テーブルを直接変更します。このテーブルへのアクセスは、Number（番号）レコードのフォーム画面下部にあるリンクから行えます。

必要に応じて：レコード作成画面を開いた時点ではなく送信時に採番を行う（欠番防止）

標準ではレコード作成画面を開いた時点で採番が行われますが、レコードが保存されなかった場合は欠番が生じます。

System Properties(システムプロパティ)で”glide.itil.assign.number.on.insert”を”true”に設定することで、送信時にのみ採番されるようにすることが可能です。システムプロパティの設定方法は下記の記事を参照ください。

ServiceNowのSystem Property（システムのプロパティ）の設定方法

また、このプロパティを設定する際には、以下の点に注意が必要です。

フィールドの編集制限
標準の自動フィールドは、編集可能な設定になっていることが多く、フォームを開いた際にフィールドが空白だと、ユーザーが独自に番号を入力してしまう可能性が高まります。そのため、この設定を行う場合は、フィールドを読み取り専用に設定することも検討する必要があります
全テーブルへの影響
標準・非標準問わず全ての自動採番フィールドでフォームを開いたときではなく送信時に採番されるようになります。既に業務で利用されている他の機能がある場合は、プロパティ設定前に影響を確認しておきましょう

Tips

連番の値が設定した桁数を超えた場合は桁数を超えてカウントされる

連番の値が設定した桁数を超えると、カウントはそのまま続行され、リセットは行われません。たとえば、桁数を3桁に設定した場合、999の次は1000とカウントされ、4桁となります。

ただし、番号の桁数が揃っていないと次のような問題が発生する可能性があるため、レコード数を事前に見積もり適切な桁数を設定しておくことを推奨します。

ソート時に期待しない順序でレコードが並ぶ可能性がある
番号を格納するフィールドや外部システムとの連携で桁数制限に引っかかる可能性がある

標準のNumberフィールドは重複を許容

標準のNumberフィールドには一意性制約(ユニーク制約)が無く、重複が許容されています。これについてはCommunityでも疑問が上がっていますが、Documentation:Enforcing unique numberingによると、Numberフィールドに一意性制約(ユニーク制約)を設定した場合、予期せぬエラーが発生する可能性があるため、代わりにBusiness Ruleの設定が推奨されています。

個人的にはNumberフィールドの一意性制約については、次の対応方針が良いと考えます。

重複が発生しても深刻な影響がない場合は、特に対応を行わない
重複を確実に防ぎたく、かつ万が一重複した場合に画面上にエラーが表示されても業務影響が少ない場合は、NumberフィールドにUnique設定を適用する
重複を確実に防ぎたく、かつ万が一重複した場合に画面上にエラーが表示された場合に業務影響がある場合は、Documentationで紹介されているBusiness Ruleを設定する

資源移送時にNumber Counter(番号カウンタ)は移送されないため注意

Number(番号)テーブルは採番の設定を管理するため、開発資源として扱われ、Update Set（更新セット）などを使って移送することが可能です。しかし、Number Counter(番号カウンタ)テーブルは、連番の現在の値を格納するデータテーブルであるため、開発資源としては扱われず、移送されません。

多くの場合は特に問題になりませんが、マスタ系のテーブルやKnowledge(ナレッジ)テーブルに開発環境でデータを作成し、本番環境で利用するためにXML移送するような場合は、データ移行後に本番環境でNumber Counterの値を適切に設定しておかないと、本番環境で番号の重複が発生する可能性があります。

上述した通り、一意性制約がないため、気づきにくい点も厄介です。

連番の最大桁数は15桁

標準では、Number(番号)テーブルのDigit(桁数)フィールドの値、つまり連番の桁数は、15桁以下に制御されています。この制御はBusiness Rule “Validate Number”によって行われています。

なお、Prefix(プレフィックス)項目は、項目の最大桁数通りの40文字まで設定可能でした。

どちらの制約も、実務上はまず引っかかることは無いと思います。

接頭辞 + 0埋め連番以外の採番ルールについて

推奨はしませんが、「接頭辞 + 0埋め連番」以外のルールを適用することも可能です。設計と開発方針について以下に示します：

標準テーブルの採番

標準テーブルの場合、拡張テーブルも含め整合性が取れるように複雑な採番ロジックが設定されており、さらにその一部はブラックボックスなので、手を入れることは避けたほうがよいでしょう。代わりに、以下の方法を検討できます。

標準の採番ロジックは変更せず、採番後に番号を上書きする処理(Business Ruleなど)を追加する
Number Counter(数カウンタ)テーブルを条件に応じて変更する処理を追加する
例：上位2桁を西暦にしたい場合、毎年の初めにカウンタの上位2桁を設定

カスタムテーブルの採番

標準のテーブルとは無関係のカスタムテーブルであれば、採番ロジックを自作しても特に問題はないです。この場合、Global Business Rule “getNextObjNumberPadded”やScript Include “NumberManager”を参考にしつつ、必要な個所を変更するのがよいでしょう。

以上です。

ServiceNow – 個人開発者インスタンス（PDI）の概要と取得・設定方法

Mon, 19 Aug 2024 00:00:00 GMT

ServiceNowの個人開発者インスタンス（PDI）について解説します。

PDI（Personal Development Instance）とは？

ServiceNowが無料で提供し、自由に操作可能な個人開発用インスタンス

ServiceNow社は開発者向けに、開発者インスタンス（PDI）を提供しています。企業が所有するインスタンスと比較していくつかの制限（後述）はありますが、PDIは1人につき1つ、無料で、永久に所持することができます。ServiceNow開発者はPDIを活用して、企業が所有するインスタンスに影響を与えることなく、ServiceNowに関する学習・検証を実施することができます。
※インスタンスについては下記の記事で詳しく説明しています。あわせてご覧ください。

ServiceNowのインスタンスとは何か

PDIの入手手順

PDIを入手するためには、ServiceNow開発者プログラム（ServiceNow Developer）に登録し、PDIを取得する必要があります。

ServiceNow開発者プログラム（ServiceNow Developer）に登録

ServiceNow Developersを開き、「Sign up and Start Building」を押下します。
※Now Learning等で既にServiceNowアカウントを作成している場合、こちらまでスキップ可能です。

必要事項を入力し、「サインアップ」を押下します。

登録したメールアドレス当てに認証用メールが届くので、「Verify Email」を押下します。メールアドレスが検証され、Developerサイトにリダイレクトします。

初回ログイン時、2つの質問に回答します。Do you code?にはYesと回答しましょう。
※Noと回答すると、PDI起動時に、App Engine StudioというServiceNow内のアプリ開発者向け画面に遷移します。

任意で職務内容を選択し、左下のチェックボックスにチェックをつけ「Finish Setup」を押下します。

PDIを取得

アカウントの登録が完了したので、PDIを取得します。画面中央付近の「Start Building」もしくは「Request Instance」を押下します。

任意のファミリーバージョンを選択し、「Request」を押下後、数秒～数分程度待機待機します。
※PDIのリソースは限られているため、すぐにインスタンスが発行されず、順番待ちになることがあります。この場合、「Request」ではなく「Join Waitlist」ボタンが表示されますが、筆者の経験上数分でインスタンスが取得できることが多いです。

インスタンスセットアップが完了すると、インスタンスのURLと管理者アカウントのID・パスワードが表示されます。
PDIはdev<ランダムな数字>.service-now.comという個別のURL（サブドメイン）が割り振られます。
「Open Instance」を押下することで、管理者（admin）としてログインできます。

以降はインスタンスのURLにアクセスし管理者としてID（admin）、パスワードを入力してログインするか、Developer Siteのホーム画面の「Start Building」を押下することでインスタンスにログインすることができます。

PDIの設定

Developer Siteのホーム画面右上のアイコンを押下すると、My Instance画面が表示されます。PDIの稼働状態やファミリーバージョンの確認や、各種設定を変更することが可能です。

My Instance画面で設定可能な項目を順に解説します。

プラグインの有効化（Activete plugin）

PDIではアプリケーションやプラグインを有効化することが可能です。インスタンスアクションから有効化する方法以外に、通常通りApplication Managerから有効化する方法もあります。多くのプラグインはApplication Managerから有効化できるため、Application Managerでプラグインが見つからなかった場合はインスタンスアクションにて確認するのがおすすめです。

②インスタンスアクションから有効化

プラグインを選択し、有効化します。

プラグイン有効化中はその他のインスタンスアクションが実行できず、PDIはActivating Plugin状態となります。

プラグインの有効化が完了すると、登録したメールアドレスへ完了通知が届きます。

Application Managerから有効化

PDIに管理者でログインし、All > Pluginsに遷移し、インストールしたいアプリケーション/プラグインを検索・選択します。

選択したアプリケーション/プラグインにて「Install」を押下します。

しばらく待機すると、インストールが完了します。
※インストール中に、PDIでその他操作をすることも可能です。

メールプロパティの管理（Manage email properties）

PDIはメールの送受信を有効にすることができます（ただし後述しますが、制約があります）。まず、Enable email sending and receivingを有効にします。

次に、All > System Mailboxes > Administration > Email Accountsで新規レコードを作成し、以下のように入力します。

レコード保存後、Test Connectionの関連リンクを押下し、Connection Successfulと出ればOKです。

これでPDIからメールを送信できるようになりましたが、Docsの記事によると、スパム防止のため、PDIから送信できるドメインは「guerrillamail.com」のみに制限されているとのことです。

Unfortunately, personal developer instances (PDI) have been used both accidentally and maliciously to send email spam. In order to prevent spamming but still allow notifications on PDIs, we have restricted our email servers to sending to a single domain, guerrillamail.com. PDIs can receive email from any domain except guerrillamail.com.

ServiceNow DOCS: Managing email properties for your PDI

実際に試してみたところ、筆者のGmailアカウント宛にPDIからメールを送信することはできませんでしたが、guerrillamailで一時的に作成したアドレスにはメールを送信できました。

また、POP3アカウントはパスワードが必須なこともあり、PDI用のメール受信サーバの設定をすることはできませんでした。こちらはGmailやYahooメールのアカウントを登録することで、Inbound Action等の確認をすることも可能になります。
ServiceNowのメールについては下記の記事で詳しく説明していますので、あわせてご覧ください。

ServiceNow - Email(メール)送受信機能の図解解説

バージョンのアップグレード（Upgrade instance）

所持しているPDIのバージョンを、アップグレードすることができます。

その他の設定

その他、以下の操作が可能です。

インスタンスのリリース（Release Instance）
- 現在取得しているPDIをリリースすることができます。リリース後、新たにPDIを取得することが可能です。
  ※新たにPDIを取得すると、URLのdev以降のランダムな数字が変更されます。また、リリースしたPDIの開発データは引き継げないため注意してください。
ユーザロールの変更（Change User Role）
- こちらでNoと選択した等の理由によりPDIにてApp Engine Studio画面が表示されてしまう場合は、「Change User Role」からadminを選択し、「Change User Role」を押下することで解決します。

デモデータの削除（Remove Demo Data）
- PDIにデフォルトで含まれているデモデータを削除することができます。
初期状態へのリセット（Reset and Wipe Instance）
- 「インスタンスのリリース」と似ていますが、こちらはPDIのURLを変えずにデータを初期状態にリセットすることが可能です。ただし、「インスタンスのリリース」よりも時間を要する（数時間程度）場合があります。
インスタンスのパスワード管理（Manage instance password)
- PDIのURLや管理者のユーザ名・パスワードを確認することができます。その他、メールにて認証情報を送信したり、管理者のパスワードを変更したりできます。
履歴の確認（View history）
- パスワードリセット、プラグインの有効化、インスタンスのリセットの履歴が確認できます。
PDIに関するヘルプを取得する（Get instance help）
- インスタンスに関する文書等のリンクが記載されています。

PDIの注意事項

PDIは企業向けインスタンスと異なる点がいくつかあります。

10日間利用がないとインスタンスが消去される

PDIは一定時間操作がない場合に休止状態になります。この場合、PDIのURLを開いてもログインすることはできず、ServiceNow DevelopersへログインしてPDIを起動させる必要があります。

ログインした状態で再度ServiceNow Developersを開くと、自動でPDIの起動が開始します。10分程度待つことで、PDIが起動します。
休止状態の場合はインスタンス内のデータは保持されていますが、以下の操作の少なくとも1つが10日間確認できない場合、インスタンスは消去されます。

インスタンスへのサインイン
アプリケーションの作成
テーブルへのフィールドの追加
スクリプトインクルードの作成

この場合、インスタンス内の開発記録はすべて消去されてしまい、復旧もできません。Docs記事によると、10日間という期間はPDIの空き状況により変更される場合もあるとのことなので、消去されたくないデータがある場合はこまめに起動させましょう。

PDIs are returned to the pool of available instances if they go unused for ten days. Duration may change due to availability.

ServiceNow DOCS: Understanding PDIs

UpdateSetをXML形式で保管しておく等、うっかりPDIが消去されてしまった時に備えてバックアップを取るのも一案です。下記の記事が参考になります。

https://developer.servicenow.com/blog.do?p=/post/backup-your-pdi

インストール可能なプラグインが限定的

ServiceNowストア内の有償アプリや、ServiceNow社担当へ連絡が必要なプラグインはPDIにインストールできません。そのため、導入を検討しているがPDIで試せない…といったプラグインも往々にして存在します。

その他の制約

その他、以下の制約があります。筆者は以前ServiceNowの機械学習を試したくて学習させてみたところエラーが出た…という経験があります。

企業向けインスタンスをPDIにクローンしたり、企業向けインスタンスに対してPDIをクローンしたりすることはできない。
Team Developmentを介して企業向けインスタンスへリンクすることはできない。
PDIで作成したアプリケーションはServiceNow Application RepositoryやServiceNowストアに公開できない。
PDIで機械学習やInstance Data Replication、MetricBaseは機能しない。

以上です。

ServiceNow – Company(会社)テーブルの解説

Sun, 04 Aug 2024 00:00:00 GMT

ServiceNowにおける、会社の情報を格納するための標準テーブルであるCompany(会社)テーブルについて解説します。

Company(会社)テーブルとは？

自社、グループ会社、取引先など、自社に関連するすべての会社情報を格納するテーブル

ServiceNowには標準で会社の情報を格納するためのCompany(会社)テーブルが存在します。このテーブルは、自社・自社のグループ会社・取引先などの自社に関連するあらゆる会社や法人の情報を格納することができます。また、業務委託先の個人事業主などの非法人の取引先に関しても、より適したテーブルがあるわけではないので、他の法人の取引先と同様に管理したい場合はCompany(会社)テーブルで管理することもあります。その意味では、自社に関連するすべてのエンティティの情報を格納するテーブルと考えてもよいでしょう。

また、Company(会社)テーブルは、ユーザ情報を格納するUser(ユーザ)テーブルや、組織の情報を格納するDepartment(部署)テーブルなど、様々なテーブルから参照されており、ServiceNowにおける中心的なテーブルの一つです。

階層の管理が可能

Company(会社)テーブルには、親を指定するためのParent(親)フィールドが存在するため、階層構造の管理が可能です。

Customer Service Management (CSM)を利用する場合はより詳細な管理が可能に

カスタマーサポートの支援機能などを持つCustomer Service Management (CSM)という製品を購入する場合は、顧客を管理するための専用のテーブルや、顧客ごとに複数の連絡先を管理するためのテーブルなどが存在し、より詳細な管理が可能になります。

しかし、本記事では、購入する製品に関わらず常に利用できるCompany(会社)テーブルについて解説します。

Company(会社)テーブルのフィールド

Company(会社)テーブルに標準で含まれているフィールドについて、独断と偏見で分類して説明します。

基本情報を格納するフィールド

会社の基本的な情報を格納するためのフィールドとして、Name(名前)、Contact(連絡先)、Country(国)、State(都道府県)、City(市町村)などが存在します。

なお、Country(国)フィールドはCountry[core_country]テーブルへのReference型ではなく、String型になっています。

財務情報を格納するフィールド

財務情報を格納するためのフィールドとして、Stock Symbol(銘柄コード), Market Cap(時価総額), Revenue per year(1年あたりの利益), Profits(利益)などが存在します。

取引先の信用・与信の管理をCompany(会社)テーブルで行いたい場合など、財務情報を管理したいという要望がまれにあります。しかし、財務観点だと標準のフィールドは不要な項目が多く、逆に必要な項目が不足しているので、その場合はカスタムフィールドを追加する必要があります。

とはいえ、取引先の信用・与信管理は一般的にはERPなどで行うことが多いため、結果としてこれらのフィールドが実際に使用されることはあまりありません。

会社を分類するフィールド

前述のように、Company(会社)テーブルには様々なタイプの会社が格納される可能性があるため、それらを分類するために下記のチェックボックス(True/False)型のフィールドが用意されています。特に、自社の情報と取引先の情報をどちらもCompany(会社)テーブルで管理する場合は、これらの項目を用いて識別できるようにしておくのがよいでしょう。

Primary (プライマリ)
Customer (顧客)
Manufacturer (メーカー)
Vendor (ベンダー)

自社を表すPrimary(プライマリ)フィールド

Primary(プライマリ)フィールドは、自社、すなわち当該インスタンスを利用している会社を識別するためのフィールドです。

PrimaryフィールドはBusiness Rule(ビジネスルール)によって制御されており、Companyテーブル内でこのフィールドをTrueにできるレコードは1つだけです。

さらに、メニュー > System Properties > My Companyは、このPrimaryフィールドがTrueのCompanyレコードへのリンクになっています。このレコードのUI16 Banner Image(UI16バナーイメージ)フィールドとBanner text(バナーテキスト）フィールドは、それぞれメニュー > System Properties > Basic Configuration UI16からも設定できる、Classic UIの画面左上の画像およびその画像にマウスオーバーしたときに表示されるテキストとして使用されます。

自社のグループ会社を表すCustomer(顧客)フィールド

Customer(顧客)フィールドは、自社のグループ会社を識別するためのフィールドです。

Department(部署)テーブルやCMDB配下のテーブルなどにあるCompanyフィールド(CompanyテーブルへのReferenceフィールド)では、標準で”Customer = true”というフィルタが設定されています。

Company(会社)テーブルの標準仕様の注意点

Company(会社)テーブルの標準仕様の注意点と、それらの解決方法を説明します。

権限の弱いユーザは参照できない

Company(会社)テーブルの標準の権限制御(ACL)では、itilロールなどの一定以上の権限のロールを持つユーザでないと参照することができず、例えば問い合わせや依頼を行う際に、申請者に会社を選ばせるといったことができません。

申請者など、通常ロールを付与しないユーザにもCompany(会社)テーブルを参照させたい場合は、ACLの設定変更が必要です。ACLについては次の記事も併せて参照ください。

ServiceNowのAccess Control List（ACL）の概要と評価のプロセス

コードや番号を管理する項目が無い

特に取引先を管理するためにCompany(会社)テーブルを利用する場合、取引先のコードや番号を管理するフィールドが欲しいところですが、標準では適切なフィールドがありません。

コードや番号を管理するフィールドが必要な場合は、String(文字列)型のフィールドを追加し自動採番の設定を行います。自動採番については次の記事も併せて参照ください。

ServiceNow - Auto-numbering(自動採番)の解説

論理削除（有効・無効）を管理する項目が無い

会社の合併や廃業等で、会社情報を論理削除（無効化）したいことがあると思いますが、標準ではこの管理ができません。

論理削除を表現する必要がある場合は、カスタムフィールドを追加します。簡単な論理削除(有効 or 無効)であればチェックボックス(True/False)型、より複雑な状態を管理する場合はChoice(選択肢)型を選択します。

論理削除の実装については、次の記事も合わせて参照ください。

ServiceNow - Before Query Business Ruleの解説

以上です。

ServiceNowとJira Service Managementの比較

Sun, 21 Jul 2024 00:00:00 GMT

この記事では、ITSM・ワークフローツールとしてのServiceNowとJira Service Management（旧Jira Service Desk）を比較します。この記事は、特定の製品を推奨するものではなく、皆さんの組織の状況や要望に応じて、より適切な製品を選ぶ手助けをすることを目的としています。また、この記事で使用する比較軸は、他の製品を含めた比較する際にも参考になると思います。

できる限り公平な視点を心がけていますが、筆者の知識がServiceNowに偏っているため、一定のバイアスがかかっている可能性があることをご理解ください。また、本記事は2024年7月時点の情報に基づいており、将来的に変化する可能性があることにも留意してください。

各製品の概要

ServiceNowは、ServiceNow社が提供する製品で、『ServiceNowのシステムアーキテクチャの全体像』で詳述しているように、NowPlatformと呼ばれるアプリ開発基盤(aPaaS)の上に、IT Service ManagementやIT Operation Managementなどの業務アプリケーション(SaaS)が構築されています。ServiceNowは、これらの幅広い製品群全体を指します。

Jira Service Managementは、Atlassian社が提供するITサービス管理およびワークフローソリューションです。

Atlassianは、プロジェクト管理ツールのJira Softwareや社内WikiのConfluenceなどを独立したブランドとして提供しています。一方、ServiceNowは、社名と同じ名前で単一ブランドのクラウドサービスを提供しており、その中に様々な製品が含まれています。

競合するポイント

Jira Service Managementが競合するServiceNowの機能としては、ITサービス管理（IT Service Management）やNowPlatformにおけるワークフロー機能、データベース機能が挙げられます。

そのため、本記事では「ServiceNow」と言った場合、ITサービス管理、ワークフロー、データベース機能の部分のみを指すこととします。

2製品に共通する特徴

ServiceNowとJira Service Managementの共通する特徴は以下の通りです。これらの特長をすべて備えている製品は、単なる「チケット管理ツール」や「ワークフローシステム」ではほとんど見られません。そのため、多くの業務プロセスをシステムに組み込むためのソリューションを検討する場合、ServiceNowとJira Service Managementが最終候補になる可能性が高いです。

柔軟なワークフロー機能: 承認フローの柔軟性に加え、ワークフロー内でのタスクチケットの生成やデータベースへの読み書きが可能。また、様々な問い合わせや申請に利用するための申請画面の作成が可能
タスク管理・ダッシュボード機能: 問い合わせや依頼の状況を可視化し、必要なKPIをトラッキングするためのレポート・ダッシュボード機能が存在
データベース機能: 業務プロセスにおいて発生する様々な業務データを保持でき、細かな権限制御機能も備えたデータベース機能を持つ
外部システムとの連携機能: 他製品と連携して業務プロセスを自動化するための外部システムとの連携機能

製品の比較

筆者の独断で選んだ比較観点におけるそれぞれの製品の特長を説明します。

ライセンス体系・課金体系

ライセンス体系・課金体系はどちらの製品も類似しており、問い合わせや申請を行うユーザはライセンス不要（無償）で、対応を行うユーザに対して課金されるモデルになっています。

（なお、『ServiceNowのライセンス体系の基本』で紹介しているように、ServiceNowには様々なライセンス体系が存在しますが、本記事ではRequester/Fulfillerモデルと呼ばれる最も一般的な購入方法を前提として説明します）

ServiceNow

ServiceNowは次の3種類の役割によって必要なライセンスが決定されます。

役割	説明	必要ライセンス
Requester	問い合わせや申請を行うユーザ。一般従業員。	ライセンス不要（無償）
Business Stakeholder	申請に対して承認を行ったり、システムの各種データを閲覧するユーザ。管理職。	Business Stakeholderライセンス（有償）が必要
Fulfiller	問い合わせや申請の対応を行うユーザ。IT部門など、コーポレート部門のユーザ。	Fulfillerライセンス（有償）が必要

ServiceNowにおけるライセンス体系（Requester/Fulfillerモデルの場合）

Jira Service Management

Jira Service Managementも同様に3種類の役割によって必要なライセンスが決定されます。少し定義が異なります。

役割	説明	ライセンス
Customer	問い合わせや申請を行うユーザ。一般従業員。	ライセンス不要（無償）
Agent	Customerからの問い合わせや依頼に対応するユーザ。必要に応じてCollaboratorと協力して対応を行う。IT部門など、コーポレート部門のユーザ。	Jira Service Management（有償）のライセンスが必要
Collaborator	Agentからの依頼を受けて問い合わせや依頼の対応に協力する。開発部門などのユーザ。	Jira Softwareなどのライセンス（有償）が必要

Jira Service Managementにおけるライセンス体系

ライセンス体系の違い

主な違いは以下の通りです。

ワークフローで承認を行うユーザは、ServiceNowではBusiness Stakeholder（課金対象）になるが、Jira Service ManagementではCustomer（非課金対象）になる
Jira Service ManagementにおけるCollaboratorは、Jira Softwareなどのライセンスが必要で、既にJira Softwareライセンスを持っているユーザに関しては追加の費用は不要
ServiceNowのRequesterは他のユーザの申請を閲覧するのに制限がある（Watch listという機能を用いてby nameで追加した他のユーザのみ閲覧可能）
Jira Service ManagementのCollaboratorはCustomerの問い合わせに直接回答ができない（Customerからの問い合わせや依頼に直接対応できるのはAgentだけ）

重要なのは、実現したいことが無償のRequesterまたはCustomerで可能なのか、有償のライセンスが必要なのかをしっかり見極めることです。例えば、ワークフローの承認者は、Jira Service Managementでは無償ですが、ServiceNowでは有償です。また、Jira Softwareのライセンスを持っているユーザでも、問い合わせや依頼に直接コメントしたい場合は、Jira Service Managementの追加ライセンスが必要です。

外部システムとの連携に関するライセンス体系

外部システムとの連携に関するライセンス体系について、各製品の概要を補足します。他の製品と連携してワークフローを自動化する場合は、注意が必要です。

ServiceNow

Inbound連携: 外部システムからServiceNowのAPIを呼び出す場合（Inboundの連携）には課金はありません
Outbound連携: 外部システムのAPIを呼び出す場合は、Integration Hubと呼ばれる外部システムとの連携用ライセンスを別途購入する必要がありますこのライセンスは、トランザクション数に応じて課金されます
プログラムによる連携: 外部システムのAPIをIntegration Hubではなく、Rest Messageというプログラミングを必要とする機能を用いて実現する場合、課金されません

Jira Service Management

自動化機能: 外部システムとの連携に関しては、連携に対して課金というよりは、口述する自動化機能の実行数により課金されます。自動化機能の実行回数は購入ライセンス数に応じて付与され、別途購入は不要です
連携アプリ: 外部システムとの連携用のアプリ（プラグインのようなもの）を用いる場合、アプリごとに別の課金体系が適用されます（ほとんどの場合アプリは本体のライセンスよりも安価です）。

コスト

コストについては、一般的にJira Service Managementの方が優位（安価）です。ただし、ライセンス体系の違いや、要件による違い、そして各社が提示するディスカウントレートによる影響も考慮する必要がありますので、一概には言えない点にご注意ください。

無料トライアル

ServiceNowでは個人開発者インスタンス（PDI）という、登録さえすれば誰でも、無料で開発・検証用環境を受け取ることができます。
下記の記事で詳しく解説していますので、あわせてご覧ください。

ServiceNow – 個人開発者インスタンス（PDI）の概要と取得・設定方法

一方Jira Service Managementでは、こちらから無料トライアルが可能とのことです。実際に、筆者はGmailアカウントで申し込むことができ、すぐにJira Service Managementが使えるようになりました。

ITSM機能の充足性

ITSM機能については、両製品とも非常に強力であり、類似点が多く見受けられます。互いにベンチマークしつつ不足機能を補完していると思われるため、ほとんど差異はないと考えてよいでしょう。

GartnerによるIT Service Managementの比較を見ても、本記事執筆時点では同じレーティングになっています。

なお、筆者にて各機能の詳細まで触れているわけではないので、細かい要件がある場合は、もちろん各製品でそれが満たせるかを確認してください。

フォーム画面の柔軟性

フォーム画面の柔軟性については、どちらの製品も多くの入力形式に対応しており、操作性の高いフォームを実現することができます。しかし、以下の点で違いがあります。

レイアウトの柔軟性ならJira Service Management

Jira Service Managementでは、Form（フォーム）機能によって、Confluenceのページのように非常に柔軟なレイアウトを実現できます。一方で、ServiceNowのフォーム画面はレイアウトの自由度はあまり高くありません。

機能の柔軟性ならServiceNow

ServiceNowのフォーム画面では、以下のような細かい設定や制御が可能です。

動的に行数を増やせる表形式の入力項目（いわゆる「明細」を受け付けるためのUI）
過去の申請を参照して選択する入力項目
ユーザの属性や既に入力された別の項目に基づいて他の項目の表示・非表示を制御
ある項目の値の入力応じて別の項目の値を自動入力

一方で、Jira Service Managementのフォーム画面は、動的な制御はあまり得意ではありません。

ワークフロー機能

どちらの製品もGUIでパーツを配置していく簡単なUIでワークフローを作成できます。以下で説明するように、機能の概念が異なりますが、単純な承認フローとしてのワークフローであればJira Service Managementで十分です。一方、承認だけでなく、特定のワークフロー中で発生するタスク管理や外部システムとの連携などを含む一連の業務プロセスをシステムとして組み込む場合は、ServiceNowの機能に優位性があります。

Jira Service Managementのワークフロー機能

Jira Service Managementには、ワークフローを実現するための機能として、Workflow（ワークフロー）とAutomation（自動化）の2つの機能が存在します。

Workflow（ワークフロー）　…　問い合わせや依頼のステータス遷移（例：マネージャ承認 → 部長承認）を制御するための機能。どのボタンが押されるとどのステータスに遷移するかや、承認を取得するステータスで誰に承認依頼を行うかを設定します。
Automation（自動化）　…　特定の条件を満たした際に自動処理を実行するための機能。承認が完了した際に問い合わせや依頼に自動でコメントをする、特定の項目の値を更新する、データベースを自動更新する、外部システムと連携するといったことが可能です。

例えば「アカウント申請」というワークフローを作成し、申請者のマネージャの承認が得られたらAPIを用いて特定のシステムにアカウントを自動で作成する場合、次のように実現します。

(Workflow) アカウント申請のステータス遷移をワークフロー機能で作る
(Automation) 承認完了ステータスになったことをトリガとして、外部システムへのアカウント作成及びデータベースの更新ロジックを自動化機能で作る

そのため、「ワークフロー」を「承認フロー」とほぼ同じ意味で考えている場合は、Jira Service Managementで必要十分な機能があると言えるでしょう。

しかし、複雑な一連の業務プロセスをワークフローとして組み込む場合、Jira Service Managementはあまり得意ではありません。例えば、同様の「アカウント申請」で、マネージャ承認後にIT部門のユーザにアカウント手動作成のタスクを割り当て、タスク完了後に申請者に通知する場合、次のように実現します。

(Workflow) アカウント申請のステータス遷移をワークフロー機能で作成。
(Automation) 承認完了ステータスをトリガとして、IT部門向けにアカウント作成のJiraタスクを起票するAutomationを作成。
(Automation) Jiraタスクがクローズされたことをトリガとして、申請者にアカウント作成完了通知を行うAutomationを作成。

2.,3.の部分がポイントで、Automation機能では「条件を待つ」といった高度な制御ができないため、複雑なワークフローを組み込む場合、多くのAutomationを組み合わせなくてはなりません。

ServiceNowのワークフロー機能

ServiceNowは、Flow Designerという機能を使ってワークフローを作成します（以前はWorkflow Editorという機能もありましたが、現在はほとんど使用されていません）。

Flow Designerは、Jira Service ManagementのWorkflow（ワークフロー）とAutomation（自動化）を一つにまとめたような機能です。さらに、「条件を待つ」ことや、他の多くのシステムとの連携がパーツを配置するだけで簡単に組み込むことができます。

Flow Designerはより高い柔軟性を提供するため、複雑な一連の業務プロセスをシステムで組み込みたい場合には、とても魅力的です。

外部システムとの連携機能

どちらも多くの外部システムとInboud・Outboundいずれでも連携することができます。標準で用意されているコネクターの数ではServiceNowが、Atlassian社の他製品との親和性ではJira Service Managementが優れています。

ServiceNowの外部システム連携機能

ServiceNowは、グローバル標準のSaaSを中心とした数多くのサービスと、GUI上にパーツを配置するだけでシステム連携を構築できる非常に優れた外部システム連携機能を有しています。

Docs | ServiceNow

さらに、ServiceNowは外部システムからのアクセスを可能にする豊富なInbound APIを提供しており、外部システム起点のシステム連携にも強みを持っています。追加のWebhook URLを作成し、任意の動作をするエンドポイントを構築することも可能です。

とはいえ、いくつか弱点も存在します。まず、ノーコードでシステム連携を行うためにはIntegration Hubというライセンスを、ユーザごとのライセンスとは別で購入する必要があり、結構高いです。また、日本製品との標準コネクタはあまり提供されていないため、日系ツールとの連携を行う場合、3rdパーティ製のプラグインや日系SaaSに強いIntegration PaaS（iPaaS）を組み合わせる必要があります。

Jira Service Managementの外部連携機能

Jira Service Managementでは、標準でノーコードで簡単に連携できるシステムはあまりなく、多くの場合、3rdパーティーベンダが作成したアプリをインストールする必要があります。これにより、連携機能がプラグイン内に閉じ、既存の自動化機能との組み合わせが難しい場合や、アップデートや障害対応が3rdパーティベンダに依存するというデメリットがあります。

とはいえ、Jira Service Managementも次のような外部システムと連携するための必要十分な機能は有しています。

標準でREST APIをコールするためのステップがAutomation（自動化）に組み込まれているため、リクエストの作成やレスポンスのハンドリングを自分で行えば、Web APIを公開しているほぼすべてのシステムと連携が可能
（上記デメリットはあるものの）3rdパーティベンダのシステム連携アプリが豊富で、要件に合うアプリがあれば、大抵は低コストで利用可能
Webhookトリガで自動化を作成することで、Inboundのシステム連携にも対応可能

Atlassian製品との親和性

Jira Service Managementは、Atlassian社の他製品であるJira SoftwareやConfluenceとの親和性が非常に高いです。既にAtlassian製品を利用している企業にとっては、この点は大きなメリットとなります。

Jira Softwareとの親和性: Jiraタスクで仕事をする文化が根付いている場合、ワークフローで発生するタスクをJiraタスクとして生成できるのは大きな魅力だと思います
Confluenceとの親和性: 問い合わせや依頼を起票する画面において、自動で関連するConfluenceページを検索して「この記事を見たら解決できるのでは？」という提案をしてくれます。また、Confluenceページ内にJira Service Managementの問い合わせや申請フォームを埋め込むことができ、ナレッジの検索から問い合わせや申請の起票をシームレスに行えます。

データベース機能

両製品ともに業務データを管理するためのデータベース機能を備えていますが、ServiceNowに若干の優位性があります。

ServiceNowのデータベース機能

ServiceNowは内部のデータベースに直接に近い形で操作を行うことができます。具体的には、標準のテーブルへのフィールド追加、新たなテーブルの追加、ビューの作成、トリガーの作成など（に相当する操作）が可能です。また、ACLという機能を用いて非常にきめ細かい権限制御ができます。

ServiceNowのAccess Control List（ACL）の概要と評価のプロセス

Jira Service Managementのデータベース機能

Jira Service Managementでは、Asset（資産）という名前でデータベースにあたる機能を提供しています。元々はAsset、つまりPCやサーバなどのITサービス管理における「資産」を管理する機能であるためか、ServiceNowの生に近いデータベース機能と比べると、下記の点で不足があります。

キャパシティ　…　Atlassianの公式ページ「アセットに保存できるデータ量」に記載があるように、2024年7月時点では環境全体で100万件までのデータの制限があります。大規模な組織で多くの業務データを格納する場合には少し不足がありますが、件数は今後拡張される可能性があります。
権限制御　…　テーブル（スキーマ）単位やレコード単位の権限制御は可能ですが、フィールド単位での条件に応じた権限制御はできません。例えば、「従業員データベース」を作成した場合、住所や報酬などの機密情報が、ITヘルプデスクの対応を行うユーザにも見えてしまう可能性があります。この点はスキーマの工夫や、何らかのアプリを探して対応する必要がありそうです。

開発管理機能・変更容易性

意外と見落としがちな観点が開発管理機能です。特にワークフロー機能を積極的に活用する場合、新しい申請を追加したり、修正したりすることが頻繁に発生すると予想されるため、設定の追加や改修を安全に素早くできるか、という観点を見ておきましょう。この点については、ServiceNowに優位性があります。

資源移送機能

SAPやSalesforceなどと同様に、ServiceNowには開発環境で作成した開発物（資源）を本番環境に移送（移行）する機能が存在します。この機能により、開発と本番環境の同期を容易に行うことができます。一方、Jira Service Managementにはこの機能がなく、検証環境でテストを行った後、手動で同じ設定を本番環境に反映する必要があります。

環境コピー機能

ServiceNowでは本番環境と同等の環境（ステージング環境）や検証環境を作成するために、本番環境をコピーする機能があります。Jira Service Managementでは、データのコピー機能はありますが、設定値を含めた環境コピー機能はありません。

自動テスト機能

こちらは実現しているシステムの方が少ないと思いますが、ServiceNowはテストを自動化する機能があり、開発時のイニシャルコストはかかりますが、一度作っておけばバージョンアップ時や改修時のリグレッションテストを省力化できます。

管理（構築・運用・保守）の容易さ

管理（構築・運用・保守）の容易さについては、個人的にはJira Service Managementに優位性があると考えます。

Jira Service Managementは、直観的でキャッチアップしやすい管理画面を備えています。仕組み自体も複雑ではないため、失敗しても作り直せばよいという気軽さで使い始めることができます。これにより、管理する部門の体制が薄くても導入が可能だと考えます。

一方で、ServiceNowは非常に高い柔軟性を持つ反面、アーキテクチャが複雑で設定可能な箇所が多く、特に導入時には後戻りが難しい選択も多いため、慎重な設計が求められます。導入後も、最低一人は経験豊富なメンバーを確保することが望ましいです。

導入時にどのように体制を組むべきかについては、ITサービス管理のコンサルタントである加藤さんのnote記事も参考になります。

ServiceNow ITSMとJira Service Management -お供を一人連れていくとしたら？-｜Akira@デジタル時代のITサービスマネジメント

その他の参考になるデータソース

その他、ServiceNowとJira Service Managementを比較する上で参考になるデータソースを提示します。

導入事例

ServiceNow：https://www.servicenow.com/jp/customers.html
Jira Service Management：https://www.atlassian.com/ja/customers

他者による比較資料

各社による比較
- ServiceNowによる比較：https://www.servicenow.com/jp/servicenow-vs-jira.html
- Atlassianによる比較：https://www.atlassian.com/ja/software/jira/service-management/comparison/jira-service-management-vs-servicenow
個人的に参考になった比較
- https://deviniti.com/blog/enterprise-software/jira-service-management-vs-servicenow/
- https://www.adaptavist.com/blog/jira-service-management-and-servicenow-whats-the-difference

おわりに

各製品情報に関する訂正や、製品比較における支援が必要な場合は、サイト上部の問い合わせフォームよりお問い合わせください。

ServiceNow – ダッシュボードのインスタンス間移送

Sat, 06 Jan 2024 00:00:00 GMT

過去に開発環境や検証環境で作成していた、もしくはこれから作成するダッシュボードを、本番環境に移送したいことがあると思います。

そんなとき、恐らく「数ある更新セットの顧客アップデートを確認して、必要なものだけを移送用の更新セットに移して…」であったり、「めんどくさいから元環境の設定を見ながら本番環境で直接作成する」といったことをしている方もいるかもしれません。

今回は、そんな手間を省き、簡単にインスタンス間でダッシュボードを移送する方法を解説していきます。

※ 以降、移送元インスタンスをインスタンスAと記載し、ライトテーマで画像を貼ります
※ 以降、移送先インスタンスをインスタンスBと記載し、ダークテーマで画像を貼ります

ダッシュボードの作成

インスタンスAに画像のようなダッシュボードを作成してみました。
PDIを作成したときからデフォルトで存在するレポートやパフォーマンス分析をまとめたダッシュボードです。
私が作成したレポートが存在しないわけですが、これをインスタンスBに移送できるか試してみます。

移送前準備

更新セット

インスタンスAからインスタンスBにダッシュボードを移送するための更新セットを作成します。

インスタンスAで、メニュー > System Update Sets > ローカル Update Sets(Local Update Sets) をクリックします。

新規(New)をクリックし、任意の名前の更新セットを作成します。
名前を入力したら、送信して最新にする(Submit and Make Current)をクリックします。

フィルターナビゲーターに pa_dashboards.list と入力し、Enterキーを押下します。
インスタンスAに存在するすべてのダッシュボードのリストが表示されます。

先ほど作成した、サンプルダッシュボードをクリックします。
画面左上のハンバーガー（三本線）アイコンをクリックし、ダッシュボードのアンロード(Unload Dashboard)をクリックします。

これで、今の更新セットの中にレポート・ダッシュボードを作成したすべての顧客アップデートが集まりました。
一応、更新セットの中を見てみましょう。

タブやパネルなど、作成した履歴が登録されているのがわかります。
では、必要な顧客アップデートは全て集まったので、更新セットのステータスを完了に変更しましょう。
ここまでで更新セットの準備は完了です。

更新ソース

インスタンスAのadmin(System Administrator)のパスワードを再設定しコピーします。
※ 既にパスワードを控えている方は不要です。

インスタンスBにログインし、メニュー > System Update Sets > 更新ソース(Update Sources) をクリックします。

新規(New)をクリックし、下記のように値を入力します。

　名前(Name)：任意の名前
　タイプ(Type)：開発
　URL：移送元のインスタンスURL
　ユーザー名(Username)：admin
　パスワード(Password)：adminのパスワード
　アクティブ(Active)：true
　簡単な説明(Short description)：任意の説明

入力内容に誤りがないか確認し、テスト接続(Test Connection)ボタンをクリックします。
画像のように接続成功のメッセージが表示されれば更新ソースの準備は完了です。
送信(Submit)ボタンをクリックし、レコードを作成します。

移送

移送先であるインスタンスBにログインします。
前項で作成した更新ソースを開き、完了した更新セットを取得(Retrieve Completed Update Sets)ボタンをクリックします。
ゲージが100%になったらクローズ(Close)をクリックします。

関連リストの取得済み更新セット(Retrieved Update Sets)タブの、移送されてきたリモート更新セットレコードを開きます。

エラー表示が特になければ更新セットのコミット(Commit Update Set)ボタンをクリックします。
ゲージが100%になったらクローズ(Close)をクリックします。

これでインスタンスAで作成したダッシュボードの移送が完了しました。
実際にダッシュボードを見比べてみましょう。

インスタンスA

インスタンスB

うまく移送されていますね！
レコード数やデータにインスタンス間で差異があるので全く同じレポートにならないことも想定通りです。

まとめ

今回はレポート・ダッシュボードを更新セットを使用して簡単に移送する方法を解説しました。

やることはシンプルで、簡単にまとめると下記のようになります。

1.ダッシュボードを作成する
2.移送用の更新セットを作成する
3.pa_dashboards.list > 目的のダッシュボードレコード > ハンバーガーアイコン > ダッシュボードのアンロード
4.更新セットの移送

冒頭で述べたような、一から各インスタンスに作り直すといった工程を踏むよりは遥かに楽になると思います。

今回は以上です。ありがとうございました。

ServiceNowのコメントにHTMLタグを使用する

Sun, 17 Dec 2023 00:00:00 GMT

ServiceNowの追加コメントや作業メモにおいて、「@<user_id>」で任意のユーザーにメンションを付けてコメントを送信することができることは皆さんご存じかと思います。

しかしながら、コメント内にリンクを埋め込んだり、表を作成できることは意外と知られていません。

今回は、追加コメントや作業メモでHTMLタグを使う方法を解説していきます。

システムプロパティの確認

まず前提として、HTMLタグを使用できるかは、とあるシステムプロパティによって判断されます。
デフォルトで使用できる設定になっていますが、一応確認しに行きましょう。

フィルターナビゲータに sys_properties.list と入力しEnterを押します。

Name (名前)が glide.ui.security.allow_codetag のプロパティを探します。
Value (値)が true になっていれば、追加コメント・作業メモでHTMLタグを使用できます。
ユーザーにHTMLタグを使用させたくない場合は、こちらの値を false に変更してください。
※ 正確には、フィールドタイプが Journal Input (ジャーナル入力) のフィールドでHTMLタグを使用できます。

実践

設定の確認が終わったらいよいよ実践です。
試しに ServiceNow研究所という文字列を太字にするHTML文を記載します。

<b>ServiceNow研究所</b>

タグがそのまま残ってしまい、太字にもなりませんでした。
実は、ServiceNowの追加コメント・作業メモでそのままHTMLを使ったとしても、ただの文字列として認識されてしまい、期待通りに動作することはありません。

ではどうするかというと、下記のように [code][/code] でHTMLタグを囲んでしまいます。

[code]
<b>ServiceNow研究所</b>
[/code]

今度は期待通りに太文字で表示されました。

今のは簡単な例でしたが、こちらの[code][/code]タグ、HTML5でできることはおおよそできると考えていただいてよいです。例えば冒頭で述べたように…

埋め込みリンクを作成したり、

[code]
<a href="https://servicenow-lab.com/">ServiceNow研究所</a>
[/code]

表を作成したり、

[code]
<p>
  <a href="https://servicenow-lab.com/">ServiceNow研究所</a>
</p>
<table border="1" width="200">
  <tr bgcolor="#e0ffef">
    <th width="70%">カテゴリー</th>
    <th width="40%">記事数</th>
  </tr>
  <tr>
    <td>検討・企画</td>
    <td>20</td>
  </tr>
  <tr>
    <td>運用</td>
    <td>15</td>
  </tr>
  <tr>
    <td>開発・導入</td>
    <td>34</td>
  </tr>
</table>
[/code]

こんな感じに書くことも可能です。
※ ナレッジで書けと言われそうな内容ですが解説なので目を瞑ってください…

[code]
<h2><a href="https://servicenow-lab.com/">ServiceNow研究所</a></h2>
<h3>ServiceNowの日本語情報サイト</h3>
<p>ServiceNowエンジニア三人が数々の導入案件に関わった経験をもとにServiceNowに関する情報を日本語で発信中</p>

<ol>
  <li><a href="https://servicenow-lab.com/category/plan/">検討・企画</a></li>
  <li><a href="https://servicenow-lab.com/category/operation/">運用</a></li>
  <li><a href="https://servicenow-lab.com/category/install/">開発・導入</a></li>
  <li><a href="https://servicenow-lab.com/inquiry/">問い合わせ・仕事依頼</a></li>
</ol>

<h3>記事数</h3>
<table id ="lab" border="1" width="200">
  <tr bgcolor="#e0ffef">
    <th width="70%">カテゴリー</th>
    <th width="40%">記事数</th>
  </tr>
  <tr>
    <td>検討・企画</td>
    <td>20</td>
  </tr>
  <tr>
    <td>運用</td>
    <td>15</td>
  </tr>
  <tr>
    <td>開発・導入</td>
    <td>34</td>
  </tr>
</table>
<h3>カテゴリ別閲覧者数</h3>
<p>・・・・</p>
<h3>サイト再訪問者率</h3>
<p>・・・・</p>
[/code]

まとめ

今回は追加コメント・作業メモでHTMLタグを使用する方法を解説しました。

基本的に、HTMLフォーマットでの文書の保存は、HTMLタイプのフィールドを作成し、アクティビティストリームに出力されるように設定を行う方が、入力者の手間がかかりません。
標準のフィールドをHTMLタイプに変更するというのも一つの手ではあります。

しかし、追加コメント・作業メモのように、フィールドの作成元であるタスク [task]から数多くの子テーブルに継承している場合は、影響範囲が広すぎるためタイプの変更は推奨されません。

標準のフィールドに全く手を加えずリンクを作業メモに埋め込みたい、といった場合にご利用ください。

今回は以上です。ありがとうございました。

ServiceNow – 少数を表すデータ型の解説（Decimal, Floating Point Number）

Wed, 20 Sep 2023 00:00:00 GMT

ServiceNowにおいて、少数を表現するデータ型であるDecimal型とFloating Point Number型の仕様、それらの使い分けについて解説します。

Decimal, Floating Poit Number, 他のデータ型の使い分け（結論）

まずは、この記事の結論である使い分けを初めに示しておきます。後述すように、少数を表すデータ型は仕様がトリッキーで、きれいには分離できないため、独断を含んでいます。なお、ServiceNowでは、一般的に倍精度浮動小数点数を表すDouble型は存在しません。

やりたいこと	適切なデータ型	解説
大きな桁数の整数を保持したい	long, Decimal	Decimalを用いる場合約16桁までの値しか正確に保持できないが、long型であれば約19桁まで保持できる上に挙動がシンプルなので、longを推奨します。ただし、入力できる桁数を制限したい場合は、簡単な設定で桁数を制御できるDecimalが良いと思います。 *なお、”他システムから取得した値をスクリプト経由で計算処理無しで記録しておく”といった特殊ケースで、かつlongでは対応できない大きな桁数の値を保持したい場合は、Decimalを採用してもよいかもしれません。（詳細は後述）
桁数の比較的少ない少数を保持したい	Floating Point Number, Decimal	パーセント（e.g. 15.5%）や評価（e.g. 3.5点）、工数（e.g. 1.25人月）などの、口述のFloating Point Number型で表現できる範囲の桁数に収まることが確実な数であれば、Decimalよりも挙動が素直なFloatを推奨します。ただし、入力できる桁数を制限したい場合は、簡単な設定で桁数を制御できるDecimalが良いと思います。
桁数の大きい少数を保持したい	Decimal	金額（e.g. 123,456,789,012.5ドル）や精密な量（0.00005523kg）などで、Floating Point Numberで表現できる範囲を超える可能性のある少数を格納する場合は、Decimalしか対応できません。

Decimal, Floating Point Number, longの使い分け

Decimal型項目の解説

基本

少数を保持する項目（フィールド）を作成する場合のデータ型の選択肢の一つが、Decimal型です。

Decimal型フィールドでは、整数部と小数部を合わせた最大桁数をMax length項目で、小数部の最大桁数をScale属性（Attribute項目で指定する項目の設定）で指定できます。Max lengthを15、Scaleを7で指定した場合、整数部最大8桁、小数部最大7桁の少数を格納することができます。

Decimal型の不思議な挙動とその理由、対応方法

Decimalは数々のトリッキーな挙動を示すデータ型であり、以下に具体的な挙動とその理由、存在するものは対応方法を示します。

なお、これらは贔屓目に見ても謎な仕様ばかりなので、今後修正が入る可能性もあります。本記事は2023年Vancouverバージョンの挙動をもとに調査しているため、後発のバージョンでは挙動が変わっている可能性があります。

謎挙動をまとめると、次の通りです。

Max Lengthの最大値は38
ScaleはMax Length以下でなければならず、最大値は38（Max length = Scale = 38とした場合、0.<38桁>の形式の少数のみ保持できる）
標準ではHTML/CSS上でDecimal型フィールドに対応するformタグにmaxlength=14が指定されているため、小数点やカンマを含めて14桁までしか入力できないようになっているフォーム上で14桁以上入力させる必要がある場合はonloadのClient Scriptでこの制御を外さなければならない
標準ではDecimal型項目に対してフォーム上で入力を行うと、整数部のみ自動フォーマットが行われ、3桁ごとのカンマや、21桁を超えた場合の指数表記への変換が行われる。この自動フォーマットにおいて、数値はIEEE 754 倍精度浮動小数点数で処理されているため、9,007,199,254,740,991(10進数、16桁)を超えた数値を入れると、丸め誤差が発生する可能性がある。つまり、フォームからの入力を前提とする場合、正確な値を保持できる実質の最大桁数は15桁。

以下、一つずつ詳細を説明していきます。

謎仕様① Max Lengthを14以下にしようとすると強制的に15になる

Max lengthを14以下に変更しようとすると、”Set Length for Decimal”というBusiness Ruleによって強制的に15に変更されるようです。

基本的に桁数が大きい分には問題にならないと思いますが、例えば10桁以内の整数を格納する項目を作りたい場合などは、なぜこのような制御がかかっているかはわかりませんが、この制御が内部的なデータベースの扱いなどに関連している可能性もあるため、14桁以下に制御する必要がある場合は、標準のBusiness Ruleを無効化/変更せずUI PolicyやClient Script、Business Ruleを用いて制御するほうが良いでしょう。

謎仕様② Max Lengthを38より大きくしても内部的には38桁までしか保存できない

Decimal項目のMax lengthの値を38より大きくしようとすると、画面上は可能なのですが、内部的には38が限界なようです。ServiceNowの内部で用いられているMySQL(MariaDB)の仕様では、最大桁数は65桁ですので、この制約はServiceNowのアプリケーションレイヤでかけられているものと思われます。

ちなみに、Dictionary（項目定義）上では38桁より大きな値を入力しても、フォーム上でフィールドの情報を確認すると、38桁と表示されます。

謎仕様③ Scaleを変更しても小数点以下桁数が変更されない

Decimal型フィールドにおいてScale attributeだけを変更してもDBには反映されず、Max lengthを変更した際にMax lengthとScaleがまとめて反映されるそうです。そのため、Scaleだけを変更したい場合であっても、Scale変更後に一度Max lengthを変更して、元に戻す必要があります。

参考: KB0696658 Number of decimal places always rounds to 2 even when ‘scale’ is attribute is set

謎仕様④ Decimal型のフィールドに14文字までしか入力できない

Max lengthの設定とは無関係に、フォーム上でDecimal型フィールドに値を入力しようとすると、小数点を含め最大14文字までしか入力することができません。これは、HTML/CSS側で最大文字数が14文字に制御されているためです。

なぜこのような制御がかかっているかはわかりませんが、このままだと小数点を含めて14文字以内の値しか入力できなくなってしまうので、符号や小数点を含め15文字以上を入力できる必要がある場合はonloadのClient Scriptで次のように制約を外す必要があります。なお、ここで設定するmaxlengthは、テキストボックスへ入力できる最大文字数ですので、符号や整数の区切りのカンマ、小数点を考慮しておく必要があります。厳密に桁数を制御したい場合は、別途UI PolicyやClient Script、Business Ruleで制御すべきです。

maxlengthの制御を外すClient Script

function onLoad() {
	// Max length=15, Scale=7を前提として、小数点及び整数部のカンマを考慮し18文字に上書き
    g_form.getElement('u_decimal_field').setAttribute('maxlength', '18');
}

なお、MySQLの仕様だと、小数部の桁数の最大値は30のようですが、ServiceNowとしては、Max Length = Scale = 38、つまり小数部が38桁の少数も格納することができるようでした。

謎仕様⑤ フォーム上で数値を入力すると整数部に丸め誤差が発生する/整数部が22桁以上になる値を入力すると指数表記（例:”1e,+21″）になり保存できない

前提として、フォーム上でDecimal型フィールドに数値を入力すると、整数部に3桁ごとのカンマが入ります。これは、HTML/CSS側で値変更時に動作するformatNumber()関数によるものだと思われます。

整数部に16桁以上入力できるようにした上で、例えば”9007199254740993″と入力してみると、”9,007,199,254,740,992″に勝手に変更され、丸め誤差が発生します。

実機の挙動を見る限り、これは、上述のformatNumber()関数において、整数部の数値をIEEE 754 倍精度浮動小数点数で扱っているためだと思われます。

詳細は省きますが、IEEE 754 倍精度浮動小数点数では仮数部が53bitで表現できる9,007,199,254,740,991(10進数、16桁) = 1 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111(2進数、53桁)までの値を正確に保持できます。この値を超えると、仮数部が53bitを超える可能性があり、その場合に丸め誤差が発生します。例えば、9,007,199,254,740,992(10進数、16桁) = 10 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000(2進数、54桁) = 1 * 2^54は仮数部は1桁になるため丸め誤差は発生しまあせんが、9,007,199,254,740,993(10進数、16桁) = 10 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001(2進数、54桁)は仮数部が54桁となるため、53桁に丸められ9,007,199,254,740,992(10進数、16桁)に変更されます。

仮に丸め誤差を許容したとしても、フォーム上で整数部が22桁以上になる値を入力すると指数表記（例:”1e,+21″）になり、指数表記の状態だとエラーが出て値を保存することができません。

こちらもformatNumber()の仕様によるものだと思われます。

formatNumber()の処理を防ぐのは難しいと思われますが、onChangeのClientScriptで丸め誤差や指数表記をもとに戻すことは理論的には可能です。しかし、その処理を行うコードの中でも数値はIEEE 754 倍精度浮動小数点数で扱われてしまうため、実現するためには複雑な処理を実装しなければなりません。そのため、桁数の大きな整数を保持する場合、9,223,372,036,854,775,807(19桁)までで問題なければlong型を利用するのが良いです。

なお、フォーム経由ではなくスクリプト経由で値を入れる場合は、formatNumber()が動作しないためか、これらの挙動は確認されませんでした。とはいえ、やはりこの場合も、スクリプトの中では基本的に数値は数値はIEEE 754 倍精度浮動小数点数で扱われてしまうため、気を付けないと結局丸められてしまいます。

Floating Point Number型項目の解説

基本

少数を保持する項目（フィールド）を作成する場合のデータ型のもう一つの選択肢が、Floating Point Number型です。

Floating Point Number型は、Decimal型ほどではないですが、やはり少しトリッキーな挙動を示しますので、以下にそれらを示します。こちらも2023年Vancouverバージョンの挙動をもとに調査しているため、後発のバージョンでは挙動が変わっている可能性があります。

謎仕様① Floating Point Number型のフィールドに14文字までしか入力できない

Decimal型と同様にフォーム上でFloating Point Number型フィールドに値を入力しようとすると、小数点を含め最大14文字までしか入力することができません。これは、HTML/CSS側で最大文字数が14文字に制御されているためです。対応については前述した通りです。

謎仕様② 単精度浮動小数点数ではない

Floating Point Numberというと、一般的なプログラミング言語でいうFloat(float)型、つまりIEEE 754 単精度浮動小数点数を表すように見えますが、ServiceNowのFloating Point Number型は、単精度浮動小数点数よりももう少し表現力が高いようです。

内部のデータ構造はよくわかりませんでしたが、実機の挙動としては、少なくとも次のような値を表現することができました。

整数部	小数部	備考
11桁	0桁	整数部のみであれば11桁までの数値を格納できるようです。12桁以上の数値を入力したところ、100,000,000,000(11桁)に変更されてしまいました。
11桁	5桁	整数部11桁、小数部5桁もほとんどの数値を格納できました。ただし、99,999,999,999.99999としたところ、99,999,999,999.99998と変更されてしまったり、10,000,000,000.99999だと末尾の9はそのままだったりと、少し変な挙動は示します。規則性はわかりませんでした。
0桁	7桁	小数部ので可能な限り大きな桁数を格納しようとすると、7桁まで格納できました。
9桁	7桁	小数部を7桁格納できる、かつ整数部にできるだけ大きな桁数を格納しようとすると、9桁まで格納できました。

ServiceNowのFloating Point Number型で表現できる値

以上です。