ServiceNow®データのデータインジェスチョンの設定¶

アーカイブ済みの記録¶

コネクタは、インジェストされたテーブルに対してSnowflake側で ServiceNow でアーカイブされた記録 を積極的に反映しません。ある日付より古い非アクティブな記録をアーカイブすると想定すると、以下のようになります。

• コネクタがインジェストする前（たとえば、テーブルの 初期ロード の前）にアーカイブされた記録は、Snowflake側のテーブルにはまったく存在しません。

• コネクタによって既にインジェストされた後にアーカイブされた記録は、アーカイブアクションが発生したことを示すことなく、Snowflake側に残ります。

• 既に 増分更新 モードで動作しているテーブルに対して復元されたアーカイブ記録は、その後にその記録も変更されない限り（その sys_updated_on 値が現在の時刻に更新されない限り）、Snowflake側でインジェストされることはありません。

• テーブルの 初期ロード 中に復元されたアーカイブ記録は、 sys_id 列の ID によっては、Snowflake側でインジェストされる場合があります。

アクティブなアーカイブルールがあるテーブルを最新の状態にしたい場合、 テーブル全体をリロード することができます。しかし、リロード終了後にアーカイブまたは復元された記録は、上記と同じ原則に従います。

ServiceNow アーカイブテーブル ar_[table_name] の同期を有効にすることができます。ただし、そのようなテーブルの 初期ロード に続く最初の 増分更新 は、アーカイブテーブルの 初期ロード が開始された日以降に作成/更新された記録のために検索されます。 sys_updated_on または sys_created_on のどちらも記録のアーカイブ時には変更されないため、アーカイブテーブルの 初期ロード 以降、ある時点までにアーカイブされた記録は、Snowflake側で欠落しています。たとえば、1年以上前の記録をアーカイブする場合、アーカイブテーブルの 初期ロード の後、1年間アーカイブされた記録は、Snowflake側のアーカイブテーブルにインジェストされません。アーカイブテーブルの 初期ロード の後、 destroyルール によって復元たは削除されたアーカイブ記録は、Snowflake側でそのテーブルから削除されることはありません。

Snowsightを使用したデータインジェスチョンの変更¶

インジェストされる ServiceNow®テーブルまたはテーブルの同期スケジュールを変更するには、次を実行します。

1. ACCOUNTADMIN ロールを持つユーザーとして Snowsight にサインインします。

2. ナビゲーションメニューで Data Products » Apps を選択します。

3. Snowflake Connector for ServiceNow®V2アプリを検索し、コネクタのタイルを選択します

4. Snowflake Connector for ServiceNow®V2 のページで、 Data Sync を選択します。

5. 編集モードに入るには、 Edit tables ボタンを選択します。

6. インジェストするテーブルを変更します。

   1. インジェストするテーブルを検索します。

   2. 選択する、または選択解除するテーブルの左から Status 列のチェックボックスを選択します。

   3. Sync Schedule で、Snowflakeと ServiceNow®間でテーブルを同期する頻度を選択します。

7. Update data sync を選択します。

テテーブル同期の有効化または無効化¶

このセクションでは、 ServiceNow®でテーブルの同期を有効または無効にする方法について説明します。同期の有効化は、デフォルト構成とカスタム構成の両方で実行できます。

CALL ENABLE_TABLES(<tables_to_enable>);

CALL ENABLE_TABLES(['table1', 'table2', 'table3']);

CALL DISABLE_TABLES(<tables_to_disable>);

CALL DISABLE_TABLES(['table1', 'table2']);

CALL ENABLE_TABLE('<table_to_enable>', <table_config>);

CALL ENABLE_TABLE('<table_to_enable>', <table_config>);

CALL ENABLE_TABLE('u_table', { 'include_columns': ['sys_id', 'sys_updated_on'] });

CALL ENABLE_TABLE('u_table', { 'exclude_columns': ['col_1'] });

CALL ENABLE_TABLE('<table_to_enable>', <table_config>);

CALL ENABLE_TABLE('sys_audit', {
  'row_filter': 'tablename = "incident" AND fieldname = "cause" AND newvalue LIKE "privacy"'
});

CALL ENABLE_TABLE('incident', {
  'row_filter': 'active = "true" AND sys_created_by STARTSWITH "support" OR sys_created_by ENDSWITH "admin" AND category IN ("Network", "Cloud Management")'
});

CALL ENABLE_TABLE('incident', {
  'row_filter': 'incident_state IN ("1", "2", "3")', -- "New", "In Progress", "On Hold"
  'include_columns': ['incident_state', 'description']
});

同期スケジュールの指定¶

Snowflake Connector for ServiceNow®V2 は、指定されたスケジュールですべての ServiceNow®テーブルからSnowflakeにデータを同期します。デフォルトでは、すべてのテーブルが毎時（1時間ごとに）同期されます。

すべてのテーブルのデフォルトの同期スケジュールを変更するには、次の引数で CONFIGURE_DATA_INGESTION_SCHEDULE ストアドプロシージャを呼び出します。

CALL CONFIGURE_DATA_INGESTION_SCHEDULE(<schedule>);

条件:

schedule

同期の頻度を指定します。次の JSON 値のいずれかを指定できます。

• { 'type': 'interval', 'value': '<interval_value>' }。ここで、 interval_value は以下の文字列値のいずれかです。

  • '30m'

  • '1h'

  • '3h'

  • '6h'

  • '12h'

  • '1d'

• { 'type': 'custom', 'value': { 'hour': <hour>, 'day_of_week': '<day_of_week>' } }。ここで、 hour は UTC のタイムゾーンでインジェスチョンを開始する時刻を指定し、 day_of_week はインジェスチョンを実行する曜日を指定します。次のような特殊式を曜日として使用することができます。

  • '*' は、インジェスチョンを毎日実行する。

  • '1-3' は、月曜日から水曜日までインジェスチョンを実行する。

  • '0,5,6' は、金曜日、土曜日、日曜日にインジェスチョンを実行する。

  day_of_week 構成の式で可能な値は次のとおりです。

  • '0' - 日曜日

  • '1' - 月曜日

  • '2' - 火曜日

  • '3' - 水曜日

  • '4' - 木曜日

  • '5' - 金曜日

  • '6' - 土曜日

  月の最終金曜日を示す '5L' や、金曜日から日曜日までの範囲を示す 'FRI-SUN' のような、数字以外の値はサポートされていません。

有効化中に特定のテーブルのインジェスチョンスケジュールを設定することが可能です。単一のテーブルを有効にして、そのインジェスチョンスケジュールを設定するには、以下の引数を指定して ENABLE_TABLE ストアドプロシージャを呼び出します。

CALL ENABLE_TABLE('<table_name>', <table_config>);

条件:

table_name

有効にする ServiceNow®テーブル名を指定します。

table_config

テーブル同期の構成を指定する schedule プロパティを含むオブジェクト。詳細は CONFIGURE_DATA_INGESTION_SCHEDULE ストアドプロシージャの schedule をご参照ください。

たとえば、テーブル table_1 のインジェスチョンを有効にし、3時間ごとにデータを同期するには、以下のストアドプロシージャを呼び出します。

CALL ENABLE_TABLE('table_1', { 'schedule': { 'type': 'interval', 'value': '3h' } });

コネクタでは、同期が有効になっているテーブルごとに異なるスケジュールを指定することもできます。選択した一連のテーブルの同期スケジュールを変更するには、次の引数で CONFIGURE_TABLES_SCHEDULE ストアドプロシージャを呼び出します。

CALL CONFIGURE_TABLES_SCHEDULE(<table_names>, <schedule>);

条件:

table_names

同期スケジュールを構成するテーブル名の配列を指定します。

schedule

同期の頻度を指定します。詳細は CONFIGURE_DATA_INGESTION_SCHEDULE ストアドプロシージャの schedule をご参照ください。

たとえば、毎週土曜日と日曜日の11:00 PM UTC にテーブル table_1 と table_2 をインジェストするには、以下のストアドプロシージャを呼び出します。

CALL CONFIGURE_TABLES_SCHEDULE(['table_1', 'table_2'], { 'type': 'custom', 'value': { 'hour': 23, 'day_of_week': '0,6' } });

デフォルトでは、コネクタはスケジュールされた開始時刻から3時間の時間ウィンドウでインジェスチョンの開始を試みます。コネクタが他のテーブルをインジェストしている場合など、その時間枠内にインジェスチョンを開始できない場合、現在スケジュールされた実行は実行されません。コネクタは次のスケジュールされた時間枠でインジェスチョンの実行を試みます。 CONFIGURE_CUSTOM_SCHEDULE_START_INGESTION_WINDOW ストアドプロシージャを呼び出すと、時間枠の期間を変更できます。

CALL CONFIGURE_CUSTOM_SCHEDULE_START_INGESTION_WINDOW(<window_length>);

ここで、 window_length は ISO 8601期間形式のウィンドウの長さです。継続時間は1時間単位に切り上げられ、少なくとも1時間継続する必要があります。たとえば、値 'PT12H' は12時間継続するウィンドウを指定し、 'P2D' は2日間継続するウィンドウを指定します。

カスタムスケジュールを持つテーブルのみを有効にすると、この構成は構成されたテーブルのフラット化されたビューの作成とリフレッシュにかかる時間にのみ影響します。フラット化されたビューは、以下の条件が満たされた後、最初のインジェスチョンサイクルで作成されます。

• メタデータテーブルのインジェスチョンが完了している

• 構成されたテーブルのインジェスチョンが開始されている。

メールアラートが有効になっている場合、カスタムスケジュールを使用するときにアラート頻度を Once per day に変更することをSnowflakeはお勧めします。

data range start timeの指定¶

デフォルトでは、 Snowflake Connector for ServiceNow®V2 は対応する ServiceNow テーブルのすべての記録を同期します。 sys_updated_on または sys_created_on 列（以降、 time列 と呼ぶ）が存在するテーブルでは、 data range start time （つまり記録の対応する time列 の値の下限）を設定することで、同期データの範囲を制限することができます。

このような構成では、対応する time列 の値が data range start timestamp より古い記録はインジェスト されません。このプロシージャで使用される対応する time列 は、増分更新と 同じ方法 で決定されます。

data range start timestamp 値を変更するには、 CONFIGURE_TABLES_RANGE_START ストアドプロシージャを次の引数で呼び出します。

CALL CONFIGURE_TABLES_RANGE_START(<table_names>, <range_start>);

Copy

条件:

table_names

data range start time を構成するテーブル名の配列を指定します。

range_start

data range start time を TIMESTAMP_TZ フォーマットで指定するタイムスタンプ、または NULL で現在値の設定を解除します。

• テーブルのインジェスチョンがまだ開始されていない場合、 data range start time の値は、最初のインジェスチョンで考慮されます。

• テーブルのインジェスチョンが既に開始されている場合（リロード中など）、 data range start time 値は無視され、対応する time列 値が古すぎる記録をフィルターするために（別の） テーブルのリロード が必要になります。

したがって、テーブルの最初のインジェスチョンを開始する前（つまり、テーブルを有効にする前）に、 data range start time を設定することをお勧めします。

例えば、テーブル table1 と table2 に必要な time列 がある場合、これら2つのテーブルの data range start time を2022-11-23 07:00:00 UTC に設定するには、次のコマンドを実行します。

CALL CONFIGURE_TABLES_RANGE_START(['table1', 'table2'], TO_TIMESTAMP_TZ('2022-11-23 07:00:00 +00:00'));

Copy

コマンド実行後：

• 例えば、テーブル table1 の場合、インジェスチョンがまだ開始されていない場合、2022-11-23 07:00:00 より前に対応する time 列 の値を持つすべての記録はインジェスト されません。

• 例えば、テーブル table2 に対して、そのインジェスチョンが既に開始されている場合、このテーブルをリロードするまで、すべてのデータ同期で data range time start 値は無視されます。リロード中、2022-11-23 07:00:00より前に対応する time列 値を持つ記録はすべてインジェストされません。

data range start time の設定を解除しないことも可能です。例えば、テーブル table1 の設定を解除するには、次のコマンドを実行します。

CALL CONFIGURE_TABLES_RANGE_START(['table1'], NULL);

Copy

この場合も、テーブル table1 のインジェスチョンが既に開始されている場合、 ServiceNow®からすべての記録をインジェストするには、このテーブルのリロードが必要です。

テーブルへのデータのリロード¶

特定のテーブルにデータをリロードするには、 RELOAD_TABLE ストアドプロシージャを呼び出します。

CALL RELOAD_TABLE('<table_name>');

条件:

table_name

リロードするテーブルの名前を指定します。

RELOAD_TABLE ストアドプロシージャを呼び出すと、コネクタは次の例を実行します。

1. コネクタは、インジェスチョンのために元のテーブルを一時的に中断します。

   注釈

   テーブルのリロード中は、インジェスチョンのためにテーブルを再度有効にすることはできません。

2. コネクタは、インジェスチョン用に別の仮テーブルを作成します。

3. コネクタは、この新しい仮テーブルにデータをインジェストします。このテーブルは、 __tmp サフィックスが付いた名前のテーブルとして CONNECTOR_STATS ビューに表示されます。

   注釈

   リロードのたびに data range start time の値が考慮され、どの記録がインジェストされるかを制限することができます。

4. データがインジェストされた後、コネクタは元のテーブルのデータを仮テーブルのデータに置き換えます。

5. コネクタは仮テーブルを削除します。

6. コネクタは、インジェスチョンのために元のテーブルを再度有効にします。

このプロセス中、元のテーブル内にある既存のデータに対して引き続きクエリを実行できます。ただし、ServiceNow®テーブルのデータへの変更は、インジェスチョンプロセスが完了するまでSnowflakeテーブルに反映されません。

ServiceNow®インスタンスの過負荷を回避するには、一度に1つのテーブルのみをリロードします。

テーブルのリロードのキャンセル¶

テーブルにデータをリロードするプロセスをキャンセルするには、次の例に示すように CANCEL_RELOAD_TABLE ストアドプロシージャを使用します。

CALL CANCEL_RELOAD_TABLE('<table_name>');

条件:

table_name

リロードをキャンセルするテーブルの名前を指定します。

リロードをキャンセルすると、コネクタはリロード中に作成されたすべての仮オブジェクトをドロップします。その後、テーブルは通常の同期スケジュールの一部としてインジェスチョン可能になります。

テーブルの単一ページフェッチのサイズ構成¶

コネクタは、テーブルをページと呼ばれる小さなチャンクに分割することで、テーブルからデータをフェッチします。ServiceNow®への API リクエストごとに1ページがフェッチされます。

これを考慮して、コネクタは単一の API リクエスト内でフェッチされる行数を制限します。この制限はページサイズです。

コネクタは、次のプロセスを使用してページサイズを決定します。

1. 最初にデフォルトのページサイズは10,000行に設定されています。

2. 応答サイズを超えたためにインジェスチョン中にフェッチリクエストが失敗した場合、リクエストが成功するか、最終的なページサイズが1に設定されるまで、ページサイズは1000、100、10、1と徐々に減少します。

3. 成功したページサイズはコネクタの状態に保存され、この値が後続のリクエストで使用されます。

テーブルの現在のページサイズは TABLES_STATE ビューで確認できます。ページサイズを確認するには、次のコマンドを実行します。

SELECT PAGE_SIZE FROM TABLES_STATE WHERE TABLE_NAME = '<table_name>';

条件:

table_name

インジェストされる ServiceNow®テーブルの名前を指定します。

コネクタがページサイズを決定するために使用するプロセスは、非効率につながる可能性があります。このプロセスは、ページサイズを縮小するだけです。ページサイズは増加しません。これは、ページサイズがより低い値に設定される原因となる、単一の大きな行がテーブルにある場合に発生する可能性があります。

この状況を回避するには、次の例に示すように、 RESET_PAGE_SIZE ストアドプロシージャを呼び出してページサイズを手動で設定できます。

CALL RESET_PAGE_SIZE('<table_name>');

条件:

table_name

インジェストされる ServiceNow®テーブルの名前を指定します。

インジェスチョン実行¶

所定のテーブルのインジェスチョン実行は、設定されたスケジュールに従ってトリガーされます。実行は、ループ内でソーステーブルから前の段落で述べたページに分割された関連するすべての行をダウンロードします。

初期ロードおよび更新

データのページは、フェッチされるとすぐに対応するイベントログテーブルに挿入されます。このステージでは、新しくフェッチされた変更は同期テーブルやフラット化ビューではまだ利用できません。終了すると、何らかのデータが返される限り、条件を更新した次のリクエストが発行されます。インジェスチョン実行が完了し、ソーステーブルにフェッチするデータがなくなると、非同期マージタスクがトリガーされ、最後のマージ以降に挿入されたイベントログのすべての変更が取得され、同期テーブルに適用されます。それが完了すると、データは同期テーブルとフラット化ビューで利用できるようになります。

切り捨ててロード

切り捨ててロードモードでは、インジェスチョン実行ごとに仮テーブルが作成されます。フェッチされた行の各ページは、まずこの仮テーブルに挿入されます（このテーブルは内部コネクタスキーマに存在し、コネクタユーザーは利用できません）。このステージでは、新しく取得された変更はまだ同期テーブルやフラット化された表示では利用できず、前回の実行でフェッチされたデータが表示されます。インジェスチョン実行が完了し、ソーステーブルに利用可能なデータがなくなると、同期テーブルの既存のデータは仮テーブルのデータに置き換えられます。フェッチされた行はすべてイベントログにも追加されます。最後に仮テーブルはドロップされます。

進捗状況のモニター

現在または過去のインジェスチョン実行のステータスを確認するには、 CONNECTOR_STATS ビューをクエリできます。 STATUS 列に表示されます。データのフェッチに成功し、すべての変更が同期テーブルに適用された場合にのみ、 DONE に設定されます。インジェスチョンを実行中、または同期テーブルへのマージまたは同期テーブル内の行の置換がまだ完了していない場合、ステータスは RUNNING となります。