コネクタのトラブルシューティング¶

このトピックでは、 ServiceNow 用Snowflakeコネクタの問題をトラブルシューティングするためのガイドラインを提供します。

このトピックの内容:

ServiceNow インスタンスへの接続の確認
ServiceNow とSnowflake内のテーブル行数の比較
行のインジェスチョンステータスの確認
テーブル削除が監査済みかどうかの判断
- トラブルシューティングデータの取得
ServiceNow への接続のテスト
アクセスできないオブジェクトの復元

注釈

以下のセクションでは、コネクタのデータベースの PUBLIC スキーマで定義されているストアドプロシージャについて説明します。これらのストアドプロシージャを呼び出す前に、そのデータベースをセッションに使用するデータベースとして選択します。

たとえば、そのデータベースの名前が my_connector_servicenow の場合は、次のコマンドを実行します。

USE DATABASE my_connector_servicenow;

Copy

ServiceNow インスタンスへの接続の確認¶

ServiceNow 用Snowflakeコネクタが ServiceNow インスタンスにアクセスできることを確認するには、コネクタのデータベースの PUBLIC スキーマで定義されている TEST_SN_CONNECTION ストアドプロシージャを呼び出します。

CALL TEST_SN_CONNECTION('<table_name>');

Copy

条件:

table_name: ServiceNow インスタンス内のテーブルの名前を指定します。

コネクタが正しく設定されている場合、ストアドプロシージャは指定されたテーブルから行を返します。

たとえば、コネクタのデータベースの名前が my_connector_servicenow で、 ServiceNow インスタンスの my_table という名前のテーブルから行を取得して接続を確認する場合は、次のコマンドを実行します。

USE DATABASE my_connector_servicenow;
CALL TEST_SN_CONNECTION('my_table');

Copy

ServiceNow とSnowflake内のテーブル行数の比較¶

ServiceNow とSnowflakeの両方でテーブルの現在の行数を比較するには、 CHECK_SN_ROW_COUNT プロシージャを呼び出します。

CALL CHECK_SN_ROW_COUNT('<table_name>');

Copy

条件:

table_name: ServiceNow インスタンス内のテーブルの名前を指定します。

プロシージャがタイムアウトした場合は、プロシージャが stats API を使用して ServiceNow 内のテーブルの行数を確定できませんでした。これは、このテーブルの行数が多すぎて、この API でカウントできないことを意味している可能性があります。

注釈

返される行数は異なる場合があります。ServiceNow テーブル内には、同等のSnowflakeテーブル内よりも多くの行が含まれる場合があります。これは、 ServiceNow の特定のテーブルに設定されたアクセス制御リストルール（ACLs）が原因である可能性があります。

テーブルに対してデータ範囲の開始時間が設定されている場合、返される行数は異なる可能性が高くなります。ServiceNow 行のカウントは依然としてすべての行のカウントを表していますが、構成によると、限られた数の行のみがSnowflakeにインジェストされました。

コネクタは、 ServiceNow テーブルの行数に関する情報を取得するために、さまざまなエンドポイントを使用します。コネクタは、行数などのテーブルに関する情報に stats を使用します。コネクタは、 table を使用してデータをSnowflakeにインジェストします。

行のインジェスチョンステータスの確認¶

ServiceNow とSnowflakeのすべての可能な場所で行のインジェスチョンのステータスを確認するには、 CHECK_RECORD_HISTORY プロシージャを呼び出します。

CALL CHECK_RECORD_HISTORY('<table_name>', '<sys_id>');

Copy

条件:

table_name: ServiceNow インスタンス内のテーブルの名前を指定します。
sys_id: チェックする行の sys_id を指定します。

このプロシージャは、次のプロパティを含む JSON オブジェクトを返します。

プロパティ	説明
`table_name`	テーブルの名前。
`sys_id`	ServiceNow 内にある行の一意の識別子。
`status`	行のインジェスチョンのステータス。
`is_present_in_servicenow`	行が ServiceNow のテーブルに存在する場合は `true`。それ以外の場合は `false`。
`is_present_in_servicenow_audit_table`	行が ServiceNow の監査テーブルで追跡されている場合は `true`。それ以外の場合は `false`。
`is_present_in_snowflake_destination_table`	行がすでにインジェストされており、Snowflakeの `dest_db` データベースで使用できる場合は `true`。それ以外の場合は `false`。
`event_log_records`	この `sys_id` を持つ行のイベントログのエントリを表す JSON オブジェクトの配列。各オブジェクトには、データ変更のタイムスタンプとイベント型を指定するイベントログテーブルの列に対応する、次のプロパティが含まれています。 `sys_updated_on` `event_date` `event_type`

テーブル削除が監査済みかどうかの判断¶

ServiceNow 用Snowflakeコネクタは、監査に依存して、記録の削除をSnowflakeに反映します。

ServiceNow 内の特定のテーブルが記録の削除を監査するように構成されていることを確認するには、 CHECK_IF_AUDIT_ENABLED ストアドプロシージャを呼び出します。

CALL CHECK_IF_AUDIT_ENABLED('<table_name>');

Copy

条件:

table_name: ServiceNow インスタンス内のテーブルの名前を指定します。

このストアドプロシージャは、指定されたテーブルの audit および no_audit_delete 構成をチェックし、監査が有効かどうかに関する情報を出力します。

トラブルシューティングデータの取得¶

トラブルシューティングデータを取得するには、 GET_TROUBLESHOOTING_DATA ストアドプロシージャを呼び出します。

CALL GET_TROUBLESHOOTING_DATA(<number_of_days>);

Copy

条件:

number_of_days: データをフェッチする過去の日数を指定します。

このストアドプロシージャは、データを表形式で返します。

構成情報
コネクタで発生したエラー
インジェスチョン履歴

次の例は、このストアドプロシージャを呼び出す方法を示しています。

USE DATABASE my_connector_servicenow;
  CALL GET_TROUBLESHOOTING_DATA(1);

Copy

返されたデータを CSV 形式で保存して、 Snowflake サポートに送信できます。

ServiceNow への接続のテスト¶

コネクタが ServiceNow インスタンスにアクセスできるかどうかを検証するには、 GET_CONNECTION_STATUS ストアドプロシージャを呼び出します。

このストアドプロシージャは、セットアップ中に提供されたシークレットに格納されている接続と認証情報をチェックします。これは、2つのキーを持つバリアントを返します。

ステータス
詳細

次の例は、 GET_CONNECTION_STATUS ストアドプロシージャを実行する方法を示しています。

USE DATABASE my_connector_servicenow;
CALL GET_CONNECTION_STATUS();

Copy

アクセスできないオブジェクトの復元¶

コネクタには、コネクタのデータベースの外部にある複数のデータベースオブジェクトが必要です。これらのオブジェクトが使用できない場合、コネクタは失敗するか、正しく動作しなくなります。オブジェクトが使用できなくなる状況には、次のものがあります。

オブジェクトをドロップする。
必要な付与を保持または復元せずにオブジェクトを再作成する。
コネクタがこれらのオブジェクトを使用するために必要な付与を取り消す。

ほとんどの場合、これらのオブジェクトを再作成して必要な権限を付与することにより、これらのオブジェクトを手動で復元できます。次のセクションでは、さまざまなオブジェクトを復元する方法について説明します。

コネクタのウェアハウスの復元¶

コネクタがそのウェアハウスにアクセスできなくなった場合は、 CONFIGURE_WAREHOUSE ストアドプロシージャを呼び出して新しいものを構成します。

コネクタのシークレットオブジェクトの復元¶

コネクタが使用するシークレットオブジェクトがドロップされた場合は、同じデータベースとスキーマで同じ名前を使用してシークレットを再作成する必要があります。

シークレットの完全修飾名を確認するには、次のコマンドを実行します。

SELECT value:secret FROM GLOBAL_CONFIG WHERE key = 'connection_config';

Copy

さらに、再作成されたシークレットに対する USAGE 権限を、コネクタで使用されるカスタムロールに付与する必要があります。

シークレットオブジェクトのデータベースまたはスキーマがドロップされた場合は、 UNDROP コマンドを実行して復元できます。このコマンドは、シークレットオブジェクトも復元します。

UNDROP コマンドを使用できない場合は、同じ名前を使用してデータベースとスキーマを再作成する必要があります。また、データベースとスキーマに対する USAGE 権限を、コネクタで使用されるカスタムロールに付与する必要があります。

API 統合の復元¶

コネクタで使用されている API 統合がドロップされた場合は、同じ名前を使用して再作成する必要があります。コネクタが想定している API 統合の名前を確認するには、次のコマンドを実行します。

SELECT value:apiIntegrationName FROM GLOBAL_CONFIG WHERE key = 'connection_config';

Copy

API 統合を再作成するときは、以前に使用したものと同じ完全修飾シークレット名と ServiceNow インスタンス URL を使用することを忘れないようにします。

シークレットの完全修飾名を確認するには、次のコマンドを実行します。

SELECT value:secret FROM GLOBAL_CONFIG WHERE key = 'connection_config';

Copy

ServiceNow インスタンス URL を特定するには、次のコマンドを実行します。

SELECT value:serviceNowUrl FROM GLOBAL_CONFIG WHERE key = 'connection_config';

Copy

また、再作成された API 統合に対する USAGE 権限を、コネクタで使用されるカスタムロールに付与する必要があります。

ServiceNow データのデータベースおよびスキーマの復元¶

ServiceNow データのデータベースまたはスキーマがドロップされた場合、復元する唯一の方法は UNDROP コマンドを実行することです。このコマンドを使用できない場合は、コネクタを再インストールして ServiceNow データを再度インジェストする必要があります。

ServiceNow データを含むビューがドロップされた場合は、それらの作成を担当するバックグラウンドタスクが次に実行されたときに、ビューが自動的に再作成されます。

ServiceNow データ（イベントログまたは生データのテーブル）を含むテーブルの1つがドロップされ、 UNDROP TABLE コマンドを使用して復元できない場合は、以下を実行して ServiceNow テーブルのインジェスチョンを再度開始します。

この ServiceNow テーブルのイベントログと生データテーブルの両方が削除されていることを確認します。
ServiceNow テーブルを無効にします。
DELETE_TABLE プロシージャを使用します。
ServiceNow テーブルを有効にします。

コネクタのカスタムロールの復元¶

コネクタで使用されているカスタムロールがドロップされた場合は、同じ名前を使用して再作成する必要があります。コネクタが想定しているロールの名前を確認するには、次のクエリを実行します。

SELECT value FROM GLOBAL_CONFIG WHERE key = 'data_owner_role';

Copy

また、リストされた権限をロールに復元する必要があります。GLOBAL_CONFIG ビューを使用して、対応するオブジェクトの名前を特定できます。

さらに、ロールは、対応するスキーマからの ServiceNow データを含むすべてのテーブルとビューに対する所有権を持っている必要があります。

このスキーマに追加のテーブルまたはビューが手動で作成されていない場合は、 GRANT OWNERSHIP ON ALL TABLES/VIEWS IN SCHEMA ... TO ROLE ... コマンドを実行してロールを復元できます。

たとえば、ServiceNow データがデータベース dest_db とスキーマ dest_schema に格納されている場合に connector_resources_provider という名前のロールを復元するには、次のコマンドを実行します。

GRANT OWNERSHIP ON ALL TABLES IN SCHEMA dest_db.dest_schema TO ROLE connector_resources_provider;
GRANT OWNERSHIP ON ALL VIEWS IN SCHEMA dest_db.dest_schema TO ROLE connector_resources_provider;

Copy

再作成されたロールは、コネクタのデータベースにも付与する必要があります。たとえば、 connector_resources_provider という名前のロールをデータベース my_connector_servicenow に付与するには、次のコマンドを実行します。

GRANT ROLE connector_resources_provider TO DATABASE my_connector_servicenow;

Copy

コネクタの通知統合の復元¶

コネクタが通知統合オブジェクトにアクセスできなくなった場合は、アラートの構成の手順を再度実行し、必要に応じて通知統合オブジェクトを再作成します。

メール通知が Snowsight を介して構成されている場合は、それらを無効にしてから再度有効にするだけで、必要な外部オブジェクトを復元できます。