外部データ取込の入口：データソース（sys_data_source）

2026年6月28日 15:31

ServiceNow に外部データを取り込むとき、最初に決めるのは「どこから・どんな形式で持ってくるか」です。CSV ファイルなのか、データベース直結（JDBC）なのか、LDAP や OIDC（SSO）なのか。この「取り込み元の定義」を1レコードで表すのが データソース（sys_data_source / 画面ラベルは Data Source） です。

この記事は、Incident や CMDB は触ったことがあるが、外部データ取込の入口をこれから理解したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で sys_data_source を実際に開きます。type（取り込み元の種類）・format（形式）・file_retrieval_method（取得方法）という3つの軸でデータソースを読み解きます。データソースが指す import_set_table_name は Import Set ＆ Transform Map につながります。そこから sys_user などの業務テーブルへ流れていく、取込パイプライン全体における「入口」としての位置づけを確認します。

この記事で分かること

データソースが「どこから・どんな形式で取り込むか」を1レコードで定義するものであること
sys_data_source が Application File（sys_metadata） を継承し、更新セットで運べる構成であること
type（File / JDBC / LDAP / OIDC / REST / Custom）と、PDI 実機の全17件の内訳
format（CSV / Excel / XML / JSON 等）と file_retrieval_method（Attachment / FTP / HTTP 等）の違い
import_set_table_name が Transform Map の source_table につながり、業務テーブルへ流れる仕組み
データソースが取込パイプラインの入口にあたること（変換は Transform Map が担当）

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、データソースの件数・type・format の分布が異なります。

データソース（sys_data_source）とは

データソースとは、ServiceNow が外部データを取り込むときの「取り込み元の定義」です。1件のデータソースが「どこから（ファイル？DB？LDAP？）」「どんな形式で（CSV？Excel？JSON？）」「どうやって取得するか（添付？FTP？HTTP？）」をまとめて表します。アプリナビで「System Import Sets > Administration > Data Sources」を開くと見えるのが、この sys_data_source です。

下の画面は、PDI（Zurich / OOTB）のデータソースを type でグループ化したものです。File・JDBC・LDAP・OIDC といった取り込み元の種類ごとに、サンプルのデータソースがまとまって並びます。

PDI（Zurich / OOTB）には、すべて「Example」系のサンプルとして 全17件のデータソースが用意されていました。内訳は File が8件、OIDC が5件、JDBC が2件、LDAP が2件です。いずれも実際の取込（Load Data）は走らせていない、設定のひな型としてのデータソースです。

sys_data_source はどんなテーブルか

テーブルの継承元を確認すると、性格がはっきりします。今回の PDI（Zurich / OOTB）では、sys_data_source の super_class（継承元）は Application File（sys_metadata） でした。これは Transform Map（sys_transform_map）と同じ継承関係です。つまり「更新セットで運べるアプリケーション構成」という位置づけを意味します。取込のたびに作られるランタイムデータ（Import Set）とは性質が違い、データソースは構成として常駐します。

このデータソースが取込パイプラインのどこにいるかが一番大事です。

取込は次の4段階で流れます。

外部データ
データソース（sys_data_source）が取り込み
import_set_table_name が指すインポートセットテーブルに生データが溜まる
Transform Map が変換して業務テーブルへ insert / update する

データソースは、この一連の流れの「入口」です。「どこから持ってくるか」を決めるのがデータソース、「溜めた生データをどう実テーブルへ流すか」を決めるのが Transform Map という役割分担です。変換側は「Import Set ＆ Transform Map を実機で確認する」で扱っています。本記事と合わせて読むとつながって見えます。

1件のデータソースが持つ主なフィールドは次のとおりです（全部で62フィールドありますが、実務で触るのはこのあたりです）。

中心になるのは name・type・import_set_table_name の3つです（いずれも必須）。ほかに、形式まわりの format / file_retrieval_method / file_path も使います。フィールド定義は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_data_source^elementISNOTEMPTY

type：どこから取り込むか

type は、そのデータソースがどこからデータを持ってくるかを表す、最も重要な軸です。PDI では選択肢が6種類ありました。

実機で type の選択肢を開くと、内部値（value）と表示名（label）の対応が確認できます。

PDI 実機で type 別に件数を数えると、内訳ははっきりしました。

File（8件） … CSV / Excel / XML / JSON などのファイルを取り込みます。最も基本的で件数も多い種類です。
OIDC（5件） … Okta / Azure AD / Auth0 / Google / ADFS といった OIDC（SSO）連携のユーザー取込の例です。
JDBC（2件） … MySQL / Oracle など、データベースに直接つないで取り込む例です。
LDAP（2件） … LDAP ディレクトリの Users / Groups を取り込む例です。
このほか選択肢には REST (IntegrationHub) と Custom (Load by Script) があります。OOTB にサンプルはありませんでした（検証範囲外）。

type を選ぶと、意味を持つフィールドが切り替わります。File なら format や file_path、JDBC なら jdbc_server や sql_statement というように、フォームの入力欄が type に応じて変わります。

format と file_retrieval_method：形式と取得方法

File 型のデータソースでは、さらに2つの軸を決めます。format（データの形式） と file_retrieval_method（ファイルの取得方法） です。

format は、ファイルの中身がどんな形式かです。PDI の選択肢には、ファイル系の CSV / CSV (tab) / Excel (.xlsx/.xls) / XML / JSON / Custom (Parse by Script) がありました。ほかに JDBC のドライバ系（Oracle / MySQL / SQLServer）もあります。既定は CSV です。形式ごとの補助フィールドもあります。Excel なら sheet_number（シート番号）や header_row（見出し行）です。CSV なら csv_delimiter（区切り文字）、JSON なら jpath_root_node（1行を指すパス）が効いてきます。

file_retrieval_method は、そのファイルをどこから取ってくるかです。選択肢は Attachment（レコードに添付）/ FTP / FTPS / HTTP / HTTPS / SCP / SFTP で、既定は Attachment でした。PDI の実測では Attachment が11件で大半を占めます。ほかに FTP・FTPS (Auth TLS)・HTTP・SCP がそれぞれ1件ずつ、デモ用に用意されていました。

下の画面は、データソースを format でグループ化したものです。CSV (tab) が4件、CSV が3件、Excel が1件、JDBC ドライバ（Oracle / MySQL）が各1件と並びます。LDAP / OIDC の7件は、format が空であることも分かります。

import_set_table_name：取込先の入口（Transform Map へつながる）

データソースで見落とされがちですが、パイプライン上重要なのが import_set_table_name（Import set table name）です。これは「取り込んだ生データを、どのインポートセットテーブルに溜めるか」を指定する必須フィールドです。

ここで指定したテーブル名が Transform Map の source_table と一致します。これにより「データソースが溜めた生データ → Transform Map が変換 → 業務テーブル」という流れがつながります。データソースと Transform Map は、このテーブル名でつながっているわけです。

OOTB の実測では、LDAP / OIDC のデータソースに次のような対応が見られました。

Example LDAP Users → import_set_table_name = ldap_import（→ LDAP User Import の変換 → sys_user）
Example LDAP Groups → ldap_group_import（→ sys_user_group）
Okta Example → oidc_okta_import、Azure AD Example → oidc_azure_ad_import（いずれも → sys_user）

下の画面は、その Okta Example のデータソースをフォームで開いたものです。Type=OIDC、Import set table name=oidc_okta_import が設定されているのが分かります。

なお、import_set_table_name は辞書上は必須（mandatory）ですが、OOTB の File 系8件では空のままでした。これは古い Example レコードです。File 型は別のUI（Load Data）側で取込先を指定してきた経緯によるものと考えられます。実行時に取込先がどう確定するかは 検証範囲外としています。

代表的なデータソース（OOTB 17件）

最後に、データソース一覧をそのまま見てみます。すべて「Example」で始まるサンプルで、type・format・取得方法の組み合わせが一望できます。

こうして並べると、性格の違いがよく分かります。File 型は format と取得方法の組み合わせで多様です（CSV を FTP で / Excel を添付で / CSV(tab) を HTTP で…）。一方で LDAP / OIDC は import_set_table_name で取込先が決まっているという違いです。定期的に同じソースから取り込みたい場合は、データソースをスケジュールインポートと組み合わせます。PDI では scheduled_import_set が2件ありました。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# データソースを取り込み元(type)でグループ化
https://<YourInstance>/sys_data_source_list.do?sysparm_query=GROUPBYtype

# 形式(format)でグループ化
https://<YourInstance>/sys_data_source_list.do?sysparm_query=GROUPBYformat

# データソース一覧
https://<YourInstance>/sys_data_source_list.do

# sys_data_source のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_data_source^elementISNOTEMPTY

まとめ

データソース（sys_data_source）は「どこから・どんな形式で取り込むか」を1レコードで定義するもの。取込パイプラインの入口。
sys_data_source は Application File（sys_metadata）を継承し、更新セットで運べる構成。PDI では全17件のサンプルがあった。
type（File 8 / OIDC 5 / JDBC 2 / LDAP 2）が取り込み元を決め、type に応じて効くフィールドが切り替わる。
File 型は format（CSV / Excel / XML / JSON 等）で形式を指定する。あわせて file_retrieval_method（Attachment / FTP / HTTP 等）で取得方法を指定する。
import_set_table_name が Transform Map の source_table につながり、生データが変換されて業務テーブルへ流れる。
「どこから持ってくるか」がデータソース、「どう変換するか」が Transform Map、という役割分担。

データソースが分かると、Import Set ＆ Transform Map と定期実行のつながりが見えてきます。流れは「取り込み元を決める → 生データを溜める → 変換して実テーブルへ → 定期実行する」です。