ServiceNowへのSFTPからのCMDBインポート

このページで、SSHファイル転送プロトコル（SFTP）サーバーからServiceNowへのデータインポート手順をご覧ください。

Nexthinkは、構成管理データベース（CMDB）へのデータインポートにServiceNowの標準手続きを使用することを推奨します。

以下に、さらなる参考のために公式のServiceNowドキュメントを示します。

• ServiceNow | インポートセットのランディングページ

また、Nexthinkは参照用として、アップデートセットの形で一連の構成変更を提供しています。 このアップデートセットの詳細はこちらをご覧ください。

• Nexthink SFTPインポートコネクタインストールガイド

前提条件

Nexthink SFTPインポートコネクタは、Nexthinkクラウドプラットフォームのインスタンスを必要とします。 システムは、Nexthinkプラットフォームのアウトバウンド統合機能を使用して生成されたCSVファイルをSFTPサーバーに保存し、ServiceNowのデータソースとして消費する形で、ServiceNowへデータをインポートします。

プロセスをスムーズに実行するためには、次のコンポーネントが必要です。

• Nexthinkクラウドインスタンス。

• SFTPサーバー。

• ServiceNowインスタンス。

• CSVファイルをSFTPサーバーにエクスポートするアウトバウンドコネクタセクションを使用して作成されたデータエクスポーター。

• CMDB戦略

インポートプロセスに関わるユーザーは、ターゲットテーブルのACLルールに準拠するために必要なロールを持っている必要があります。

メインServiceNowコンポーネント

データソース

プロセスの最初のステップは、SFTPサーバーからデータを取得し、指定されたデータでインポートセットテーブルをポピュレートするアーティファクトを作成することです。

公式のServiceNowドキュメントで詳細をご覧ください: データソース | ServiceNow

データソースの例

データソースの作成方法

データソースを作成するには、システムインポートセット > 管理 > データソースモジュールに移動して、新規ボタンをクリックします。

次のテーブルでは、各フィールドのデータをどのように構成できるかを説明しています。

フィールド	詳細
名前	任意の名前を設定可能です。
インポートセットテーブルラベル	任意のテーブルラベルを設定可能です。
インポートセットテーブル名	前のフィールドの値に基づいて自動的に補完されます。
タイプ	ファイル取得方法としてSFTPを使用する場合、「ファイル」と設定する必要があります。
フォーマット	CSV
ファイル取得方法	SFTP
サーバー	SFTP DNS情報
ポート	SFTPポート。 デフォルトで"22"。 SFTPサーバーの設定でカスタマイズされている場合は、別のポートを設定してください。
ファイルパス	サーバー内でシステムがファイルを保存する絶対パス。 ファイル名を含める必要があります。例: /folder/folder/file_name.csv。
ユーザー名	SFTPユーザー名。
[パスワード]	SFTPユーザーパスワード。
CSV区切り文字	システムが異なるカラムに分割するためにファイルに設定された区切り文字。

データソースを構成した後、関連リンクのテストロード20レコードをクリックして接続性をテストします。 このユーティリティで提供されたすべての詳細が正しいことを確認し、システムがSFTPサーバーからのデータをServiceNowのインポートセットテーブルにインポートしたことを確認します。

テストロードの期待結果

テストで挿入されたデータは、テストのために生成されたインポートセットであるため、ターゲットテーブルに移行することはできません。 CMDBテーブルにデータをインポートするには、_すべてのレコードをロード_ 関連リンクをクリックしてください。

アップデートに含まれるデータソースを例として以下に紹介します。

ServiceNowインポートviaSFTPインストールガイド | スケジュールドインポート設定

変換マップ

変換マップはフィールドマップのセットで、インポートセットのフィールドと既存のServiceNowテーブルのフィールド間の関係を決定します。 プロセスのこの部分では、インポートセットにインポートされたデータを修正、スライス、変換し、要求に応じて最終テーブルにデータを格納することも可能です。

変換マップの作成方法

システムはテーブル sys_transform_map で全ての変換マップを作成します。 システムは直接テーブルフォームでこれらを作成可能です。 しかし、データソースから始めて変換マップを作成しそれにリンクさせることをお勧めします。

データソースフォームの下部に変換という関連リストがあります。 このタブをクリックして新規ボタンをクリックすると、新しい変換マップを作成するフォームにリダイレクトされます。

変換マップの例

新しいレコードフォームでは、以下のフィールドを入力する必要があります。

フィールド	詳細
名前	任意の名前を設定可能です。
ソーステーブル	データソース用に作成されたインポートセットテーブルを設定します。
アクティブ	このフィールドのチェックボックスをオンにします。
ターゲットテーブル	システムがデータを挿入する必要のある最終CMDBテーブル。

上記で説明した詳細を設定した後、レコードを保存し、ページがリロードされるのを待ってから、関連リンクの マッピングアシスト を使ってフィールドマッピングを作成します。

フィールドマップアシスタント

このツールはフィールドマップの作成を容易にします。 変換マップ内にある フィールドマップ 関連リストを使用してすべてのマッピングを最初から作成する代わりに、この目的のために マッピングアシスト の使用を強くお勧めします。 必要に応じて、フィールドマップ 関連リストで小さな調整を行います。

このツールを使用するには、左の列（データソースのソース）と右の列（ターゲットテーブル）のフィールドを中央のディスプレイにあるフィールドマップ列に移動します。 その後、ソースとターゲットフィールドを同じ行の各列で一致させ、正しくマッピングされていることを確認します。

例えば、ソースフィールド device.name をコンピュータテーブルの Name フィールドにマップするときは、フィールドマップの同じ行に両方のフィールドを配置します。

最後に、将来インポートされようとする際にシステムがレコードを更新するようにするために必要な方法として、結合フィールドを設定することが重要です。 例えば、システムがCIsを識別するためにテーブル内のフィールド name を使用している場合、重複を作成しないことが重要です。 これを避けるために、変換マップ設定でフィールドを結合として設定し、システムがターゲットテーブルのレコードを更新し、再度挿入しないことを確認します。

結合として設定された名前フィールド

結合フィールドの挙動に関するさらなる情報はこちらで確認できます。

結合を使用したレコードの更新 | ServiceNow

カスタム変換の作成方法

時々、SFTPサーバーからのデータは予期されたフォーマットになっていなかったり、システム全体ではデータの一部だけを格納する必要がある場合があります。 これらの場合、マッピングアシスト は十分ではなく、カスタム変換を作成する必要があります。

次のセクションでは、カスタム変換を作成する方法の詳細を説明します。 さらに情報が必要な場合、公式のServiceNowドキュメントをこちらで確認できます。

• フィールドマップの作成 | ServiceNow

• フィールドマップスクリプト変数 | ServiceNow

カスタム変換を作成するには、ソーススクリプトを使用 ボックスをチェックして、ソースフィールドの代わりにスクリプトを使用します。

これを有効にすると、ソーススクリプトエディターが表示されます。

ソーススクリプトエディター

ここで、ターゲットフィールドに挿入される値を計算するための任意のJavaScriptコードを追加できます。 何がターゲットフィールドに挿入されるべきかを設定するものはすべて、フィールドマップに設定されているターゲットフィールドに挿入されます。

これ以外にも、最も役立つのは、このスクリプトからインポートセットテーブルの任意のカラムがソースオブジェクトを通じてアクセス可能であることです。 したがって、例えば、このオブジェクトをベースにしたスクリプトを使用することが可能です。

アップデートに含まれる変換マップの詳細については、以下をご覧ください。

ServiceNowインポートviaSFTPインストールガイド | 変換マップ設定

カスタム変換サンプル

Nexthinkからよくインポートされるフィールドの1つはディスクスペース情報です。 NQLデータモデルリファレンスで文書化されているように、_system_drive_free_space_フィールドはバイト単位のフォーマットでデータを保存します。 しかし、この情報をストアするためのコンピュータテーブルのターゲットフィールドはデータをGB単位で求めています。 この状況を解決するために、カスタムスクリプトを使用します。

前のセクションで説明したように、フィールドマップ設定フォームに移動して、ソーススクリプトを使用 ボックスを有効にします。 エディタが表示されたら、次のスクリプトを設定します。

answer = (function transformEntry(source) {\n    var value = source.u_disk_capacity;\n return value / Math.pow(1024, 3);\n})(source);

上記のスクリプトは、Nexthink（バイトで）から受け取るデータを変数 value に格納し、同じ値を1024で3回割ったものを返します。 言い換えれば、バイトをGBに変換します。

スケジュールドインポート

スケジュールドインポートは、システムが特定のインポート操作を定期的に実行することを指定します。これは、日次、週次、定期的または異なる時間枠として定義できます。 デフォルトで、統合によって提供されるスケジュールドインポートは非アクティブであり、別のスクリプトがプログラム的に実行します。 下記のセクションでさらに詳細を見つけてください。

スケジュールドインポートの作成方法

スケジュールドインポートを作成するには、システムインポートセット > 管理 > スケジュールド インポートモジュールに移動し、新規ボタンを押します。 これにより、スケジュールドデータインポート新規レコードフォームにジャンプします。

新しいスケジュールドインポートフォーム

新しいレコードフォームでは、以下のフィールドを入力してください。

フィールド	詳細
名前	任意の名前を設定可能です。
データソース	データソースをスケジュールしてデータをインポートします。
アクティブ	このフィールドにチェックを入れます。
実行	これは、システムがインポートを実行する頻度です。 このフィールドに選択した項目に応じて、下部のフィールドは異なります。

上記で最も重要なのは_アクティブ_設定です。 このフィールドをアクティブにしたら、日付またはスケジュールドインポートの間隔の詳細を構成するための新しいフィールドが_run_フィールドの下に表示されます。 これらのオプションに関する詳細情報は、ServiceNowドキュメントで見つけることができます。

参照として、アプリケーションアップデートセットに作成されたスケジュールドインポートはこちらで確認できます。

ServiceNowインポートviaSFTPインストールガイド | スケジュールドインポート設定

インポート手順の実行

データをインポートする主な方法が2つあります。

手動実行

データインポート手順を手動で実行するには、インポートセットを作成し、インポートセットテーブルをNexthinkデータでポピュレートします。

この目的のために、データソースに移動して_全レコードをロード_ 関連リンクをクリックします。

関連リンクのすべてのレコードをロード

システムはインポートステータスフォームにリダイレクトします。

期待される結果

成功以外の結果が出た場合は、返されたエラーを参照し、データソース設定を調整するために構成をダブルチェックします。

このフォームで、変換を実行リンクをクリックして、インポートセットと変換マップがデータをどこにインポートするかを選択します。

変換ボタンをクリックすると、変換が完了し、再びインポートステータスフォームが表示されます。

また、ステータスに加えて、_インポートセット、変換履歴_及び_インポートログ_へ移動して、システムがすべてのCIを予想通りにインポートしたことを確認することができます。

スケジュールド実行

インポートセット実行をスケジュールするには、フィルターナビゲータで システムインポートセット → 管理 → スケジュールド インポート に移動し、新規作成し入力例に従ってフォームを完成させます。

以下の3つのフィールドを正確に記入することが重要です。

フィールド	詳細
データソース	最初に作成したデータソースを使用します。
実行者	スケジュールドインポートはここにリストされたユーザーの代わりに実行されます。 このユーザーに割り当てられたロールが全体のプロセスに影響を及ぼす可能性があることに注意してください。
実行	インポートを実行したい頻度を選択してください。

このフィールドをアクティブにした後、_実行_フィールドで選択したオプションに応じてシステムが表示する列の方法が異なります。

• 毎月

• 毎週

• 毎日

• 定期的に

スケジュールに関する詳細情報は、このリンクをクリックしてください。

よくある質問

CIタイプをインポートする方法は？

まず、必要なNexthinkデータを含むCSVファイルを生成し、SFTPサーバーに保存します。

Nexthinkは、Nexthink Infinity > Integrations > Outbound connector セクションでデータエクスポーターの作成を推奨しています。 ここでは、このガイドに従って、ワークステーションに関連する列をエクスポートするためのクエリを使用して、CSVファイルをSFTPサーバーにエクスポートできます。

devices
| where hardware.machine_serial_number != "" and (hardware.type == laptop or hardware.type == desktop)
| include cpus
| compute num_of_cores = number_of_cores.count(), number_of_cpus = count(), freq = frequency.sum()
| include disks
| compute disk_capacity = capacity.sum()
| list group_name, entity, hardware.manufacturer, hardware.model, operating_system.architecture, hardware.machine_serial_number, name, hardware.memory, num_of_cores, number_of_cpus, freq ,disk_capacity, operating_system.name, operating_system.build

CSVファイルをSFTPサーバーに保存した後、データソースの作成方法セクションで説明されているようにデータソースを設定し、インポート手順の実行sectionで説明されているようにスケジュールされたインポートを手動で実行またはスケジュールします。

データインポート時の参照フィールドとsys_choiceフィールドの処理は？

この種のフィールドは、トランスフォームマップの設定に基づいてデータが単純に挿入される他の型（文字列、整数、その他の型）とは、最初は同じように機能しません。

これらのフィールドは、実際には別のテーブル内の異なるCIを参照しているため、システムはレコードを挿入する前に参照先レコードが存在することを期待します。

アプリケーションの動作は、1つのパラメータによって変わります。

• _Choice action_設定がフィールドマップでCreateに設定されている場合、システムは参照テーブルに新しい選択肢またはレコードを作成します。

• _Choice action_設定がフィールドマップでIgnoreに設定されている場合、ソーステーブルの新しい値が無視され、CIはとにかく挿入または更新され、参照フィールドは空のままになります。

• _Choice action_設定がフィールドマップでRejectに設定されている場合、新しい値を含むレコード全体がスキップされ、インポートプロセスは次の行に進みます。

CI関係をインポートする方法は？

まず、必要なNexthinkデータを含むCSVファイルを生成し、SFTPサーバーに保存します。

Nexthink Infinity > Integrations > Outbound connector セクションでデータエクスポーターの作成を推奨します。 ここでは、このガイドに従って、ワークステーション-ソフトウェア関係に関連する列をエクスポートするためのクエリを使用して、CSVファイルをSFTPサーバーにエクスポートできます。

package.installed_packages
| summarize c1=count() by package.name, package.version , device.name
| list package.name, package.version , device.name

CSVファイルをSFTPサーバーに保存した後、データソースの作成方法sectionで説明されているようにデータソースを設定し、インポート手順の実行sectionで説明されているように、スケジュールされたインポートを手動で実行またはスケジュールします。

ServiceNowの中で関係はどのように機能しますか？

関係のために設定されたテーブル内のフィールドは、実際には外部テーブルを指す参照フィールドです。 たとえば、cmdb_rel_personテーブルには、他のテーブルを参照する2つのフィールドがあります。

• CI → 参照 cmdb_ci.

• ユーザー → 参照 sys_user.

したがって、要件に応じて戦略を決定する必要があります。

1. 関係の欠けているCIを作成したい場合 トランスフォーム内で設定されているフィールドマップの_Choice action_設定をCreateに設定してください。

2. 参照されたCIを作成せずに関係を作成したい場合 トランスフォーム内で設定されているフィールドマップの_Choice action_設定をIgnoreに設定してください。 これにより、キーの1つが空のままである関係が作成されます。 このオプションは推奨されません。

3. CIが欠けている場合に関係を作成しない場合 フィールドマップで_Choice action_がRejectに設定されている場合、新しい値を含むレコード全体がスキップされ、インポートプロセスは次の行に進みます。

他にインポートメカニズムが同時に動作している場合はどうなりますか？

CMDBテーブルに異なるコネクタがデータをインポートしている場合は、同一フィールドが正確に構成されていることを確認してください。 トランスフォームマップの作成方法sectionで説明されていますが、コネクタの動作は同一フィールドに依存します。 次に、同一フィールドの値がすでに存在するターゲットテーブルにレコードが見つかった場合、システムは最後のインポートセットの情報でCIを更新します。

この手順では、システムがIREエンジンを使用することがありません。 したがって、システムは異なるソースから挿入されたデータをマージするための識別ルールを一切使用しません。

このプロセスを自動的に実行できますか？

残念ながら、現在はできません。

システムがデータをインポートする前にデータソースのファイルパスを更新する必要があるため、この制限があります。 将来的なリリースでは、それを解決する自動メカニズムが提供される可能性があります。

SFTPステップを使用したアクションを呼び出すフロー を使用して自動化の追加のレベルを追加することが可能です。その際、Get File ListがSFTPサーバーに保存されているCSVファイルを一覧表示します。

システムがファイルを2回インポートした場合はどうなりますか？

ファイルパスを更新せずにインポートプロセスを2回スケジュールした場合、システムはCMDBに同じ情報を挿入しようとします。 したがって、_sys_import_set_テーブルには2つの異なるインポートセットが存在し、最初のインポートセットは挿入済み/更新済みとしてすべてのレコードを表示し、2番目のインポートセットはターゲットテーブルにすでに同じ情報があるレコードを無視/スキップします。

将来的なリリースでは、データソースのファイルパスを手動で更新するステップを回避する自動メカニズムが提供される予定です。