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

認証ステップのエラー¶

インストールウィザードで ServiceNow に接続 するとき、または SET_CONNECTION_CONFIGURATION プロシージャを手動で実行するときに問題が発生する可能性があります。このステップでエラーが発生した場合は、コネクタのインストールに使用したユーザーが sys_db_object テーブルにアクセスできることを確認してください。

SET_CONNECTION_CONFIGURATION プロシージャから返される JSON オブジェクトの中で、 ACL の問題に関連する可能性のあるエラーステータスコードは次のとおりです。

• REQUEST_FAILED

コネクタと同様の以下のクエリを実行すると、アクセスを確認できます。リクエストが期待どおりの結果を返すまで、コネクタをインストールできません。たとえば、curlを使用して HTTP リクエストを送信する場合は、

# checking access to the sys_db_object table
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_db_object?sysparm_limit=1"

条件:

servicenow_instance

ServiceNow®インスタンスの名前を指定します。

username および password

ServiceNow®インスタンスの認証情報を指定します。

応答例

• 少なくとも一部のフィールドが返される - ユーザーにはテーブルにアクセスするために必要な権限があります。

• 応答が空である - ユーザーにはテーブルにアクセスする権限がありますが、処理された記録にアクセスする権限はありません。これは後で問題になる可能性があります。

• 応答にエラーが含まれている - ユーザーにテーブルにアクセスするための必要な権限がありません。

ソースステップのエラーの検証¶

インストールウィザードで ソースを検証 するとき、または FINALIZE_CONNECTOR_CONFIGURATION プロシージャを手動で実行するときに問題が発生する可能性があります。このステップでエラーが発生した場合は、コネクタのインストールに使用したユーザーがメタデータテーブルにアクセスするために必要な権限を持っていることを確認してください。

FINALIZE_CONNECTOR_CONFIGURATION プロシージャから返される JSON オブジェクトの中で、 ACL の問題に関連する可能性のあるエラーステータスコードは次のとおりです。

• METADATA_TABLE_ACCESS_VALIDATION_ERROR

• JOURNAL_TABLE_ACCESS_VALIDATION_ERROR

コネクタと同様の以下のクエリを実行すると、アクセスを確認できます。リクエストが期待どおりの結果を返すまで、コネクタをインストールできません。たとえば、curlを使用して HTTP リクエストを送信する場合は、

# checking access to the sys_db_object table
# expected fields in the result object: sys_id, super_class, name
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_db_object?sysparm_fields=sys_id,super_class,name&sysparm_limit=1&sysparm_query=name=sys_db_object"

# checking access to the sys_dictionary table
# expected fields in the result object: sys_id, name, element, internal_type
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_dictionary?sysparm_fields=sys_id,name,element,internal_type&sysparm_limit=1&sysparm_query=name=sys_dictionary"

# checking access to the sys_glide_object table
# expected fields in the result object: sys_id, name, scalar_type
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_glide_object?sysparm_fields=sys_id,name,scalar_type&sysparm_limit=1&sysparm_query=name=datetime"

# checking access to the sys_table_rotation table
# expected fields in the result object: sys_id, name
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/sys_table_rotation?sysparm_fields=sys_id,name&sysparm_limit=1&sysparm_query=name=syslog"

# (optional) - check only if deletions auditing is going to be used
# checking access to the journal table
# if known, "&sysparm_query=tablename=<table_name>" or "&sysparm_query=documentkey=<sys_id>" can be appended to the request
# expected fields in the result object: sys_id, sys_created_on, documentkey, tablename
curl -u '<username>:<password>' "https://<servicenow_instance>.service-now.com/api/now/table/<journal_table>?sysparm_fields=sys_id,sys_created_on,documentkey,tablename&sysparm_limit=1"

条件:

servicenow_instance

ServiceNow®インスタンスの名前を指定します。

username および password

ServiceNow®インスタンスの認証情報を指定します。

journal_table

削除監査に使用する ServiceNow®テーブルの名前を指定します。通常、この値は sys_audit_delete になります。

応答例

• 期待されるフィールドがすべて応答に存在する - ユーザーには必要な権限があります。

• 期待されるフィールドの一部が欠落している - ユーザーにはすべての列に対する必要な権限がありません。

• 応答が空である - ユーザーにはすべての行に対する必要な権限がありません。

• 応答にエラーが含まれている - ユーザーにはテーブルに対する必要な権限がありません。

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

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

CALL GET_TROUBLESHOOTING_DATA(<from_timestamp>, <to_timestamp>);

条件:

from_timestamp

データを取得する日付範囲の開始日を指定します（UTC タイムゾーン）。

to_timestamp

データを取得する日付範囲の終了日を指定します（UTC タイムゾーン）。

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

• 構成情報

• コネクタで発生したエラー

• インジェスチョン履歴

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

CALL GET_TROUBLESHOOTING_DATA('2024-02-05 10:00:00', '2024-02-10 22:30:00');

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

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

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

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

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

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

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

• この ServiceNow®テーブルのイベントログと生データテーブルの両方がドロップされていることを確認します。

• ServiceNow®テーブルを無効 にします。

• DELETE_TABLE プロシージャ を使用します。

• ServiceNow®テーブルを有効 にします。

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

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

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

列のメタデータがSnowflakeに存在するかどうかのチェック¶

Snowflake上の sys_dictionary テーブルに列メタデータが存在するかどうかを確認するには、以下のクエリを実行します。

SELECT * FROM <dest_db>.<dest_schema>.sys_dictionary__view WHERE name = '<table_name>' AND element = '<column_name>';

調査対象のテーブルに親テーブル（ServiceNow®内の別のテーブルから継承）があり、探している列が親テーブルに追加されている場合は、親テーブル名を代わりに使用する必要があります。

興味のあるテーブルが継承しているすべてのテーブルをリスト表示するには、以下のクエリを使用してください。

SELECT
    sys_id,
    name,
    PARSE_JSON(super_class):value::string AS super_class_sys_id
FROM <dest_db>.<dest_schema>.sys_db_object__view
START WITH name = '<table_name>'
CONNECT BY sys_id = PRIOR super_class_sys_id;

行が返された場合、列のメタデータはSnowflakeに正しくインジェストされましたが、ビューはまだリフレッシュされていません。ステータスを確認し、もし:

• 最近表示がリフレッシュされたけれども列が存在しない場合、サポートに連絡してください。

• 表示がまだリフレッシュされていない場合、次のインジェスチョンスケジュールをお待ちください。

空の結果が返された場合は、コネクタがこの列のメタデータをまだインジェストしていないことを意味します。記録がコネクタに表示され、タイムスタンプが正しいかどうかを ServiceNow®側で検証する必要があります。

リフレッシュステータスの表示¶

指定したテーブルの表示が最後にリフレッシュされたのはいつか、その操作が成功したかどうかを検証するには、以下のクエリを実行します。

SELECT flattened_views_status, flattened_views_last_updated FROM tables_state WHERE table_name = '<table_name>';

最後のリフレッシュに失敗した場合は、イベントテーブルをクエリし、コネクタから報告されたエラーを検索します。

ServiceNow®列メタデータの可用性を表示します¶

フラット化されたビューで列が見つからないのは、列のメタデータがコネクタによってインジェストされないためである可能性があります。これは、 sys_dictionary テーブルの行が API テーブルから返されるのを防いでいる ACLs が原因である可能性があります。もう1つの原因として考えられるのは、 sys_updated_on 列のタイムスタンプ値が過去になっていることです。また、列/テーブル定義が別の ServiceNow®インスタンスからインポートされた場合もあります。コネクタが列メタデータにアクセスできるかどうかを調べるには、次のエンドポイントに対して GET リクエストを実行します。

https://<servicenow_instance>.service-now.com/api/now/table/sys_dictionary?sysparm_query=name=<table_name>^element=<column_name>

空の結果が返された場合、コネクタはその列にアクセスできません。列は、ACL で保護されている場合と、存在しない場合があります。

列定義が返された場合は、 sys_updated_on フィールドの値を調べます。日付がテーブルに列が追加された推定時刻と一致していることを確認します。他のインスタンスからインポートされた場合は、列が作成された時点が表示される場合があります。コネクタの CDC （増分更新）メカニズムは、過去の日付の記録が追加されたことに気づかないことがあります。この場合、 sys_dictionary テーブルのリロードをトリガーします。