Problembehandlung des Konnektors¶

Der Snowflake-Konnektor für ServiceNow® unterliegt den Nutzungsbedingungen für Konnektoren.

Unter diesem Thema finden Sie Richtlinien zur Problembehandlung bei Problemen mit dem Snowflake Connector for ServiceNow®.

Unter diesem Thema:

Bemerkung

In den folgenden Abschnitten werden gespeicherte Prozeduren beschrieben, die im PUBLIC-Schema der Konnektor-Datenbank definiert sind. Bevor Sie diese gespeicherten Prozeduren aufrufen, wählen Sie diese Datenbank als die für die Sitzung zu verwendende Datenbank aus.

Wenn diese Datenbank beispielsweise my_connector_servicenow heißt, führen Sie den folgenden Befehl aus:

USE DATABASE my_connector_servicenow;

Copy

Überprüfen der Verbindung zur ServiceNow-Instanz¶

Um zu überprüfen, ob der Snowflake Connector for ServiceNow® auf die ServiceNow-Instanz zugreifen kann, rufen Sie die gespeicherte Prozedur TEST_SN_CONNECTION auf, die im PUBLIC-Schema der Konnektor-Datenbank definiert ist:

CALL TEST_SN_CONNECTION('<table_name>');

Copy

Wobei:

table_name: Gibt den Namen einer Tabelle der ServiceNow-Instanz an.

Wenn der Konnektor korrekt eingerichtet ist, gibt die gespeicherte Prozedur eine Zeile aus der angegebenen Tabelle zurück.

Wenn die Datenbank für Ihren Konnektor beispielsweise my_connector_servicenow heißt und Sie die Verbindung überprüfen möchten, indem Sie eine Zeile aus einer Tabelle namens my_table in Ihrer ServiceNow-Instanz abrufen, führen Sie die folgenden Befehle aus:

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

Copy

Vergleichen der Anzahl von Tabellenzeilen in ServiceNow und Snowflake¶

Um die aktuelle Zeilenzahl einer Tabelle sowohl in ServiceNow als auch in Snowflake zu vergleichen, rufen Sie die Prozedur CHECK_SN_ROW_COUNT auf:

CALL CHECK_SN_ROW_COUNT('<table_name>');

Copy

Wobei:

table_name: Gibt den Namen einer Tabelle der ServiceNow-Instanz an.

Wenn die Prozedur eine Zeitüberschreitung aufweist, konnte die Prozedur die Zeilenzahl der Tabelle in ServiceNow nicht mithilfe der stats-API ermitteln. Dies kann bedeuten, dass die Anzahl der Zeilen in dieser Tabelle zu groß ist, um von dieser API gezählt zu werden.

Bemerkung

Die Anzahl der zurückgegebenen Zeilen kann variieren. Eine ServiceNow-Tabelle kann mehr Zeilen enthalten als die äquivalente Snowflake-Tabelle. Dies kann durch die Regeln der Zugriffssteuerungsliste (ACLs) verursacht werden, die für eine bestimmte Tabelle in ServiceNow festgelegt wurden.

Wenn für eine Tabelle eine Startzeit des Datenbereichs konfiguriert ist, wird die zurückgegebene Anzahl von Zeilen wahrscheinlich unterschiedlich sein. Der ServiceNow-Zeilenzähler gibt immer noch die Gesamtzahl aller Zeilen an, auch wenn gemäß der Konfiguration nur eine begrenzte Anzahl von Zeilen in Snowflake erfasst wurde.

Der Konnektor verwendet verschiedene Endpunkte zum Abrufen von Informationen über die Anzahl der Zeilen in einer ServiceNow-Tabelle. Der Konnektor verwendet stats für Informationen über eine Tabelle, einschließlich der Anzahl der Zeilen. Er verwendet table, um Daten in Snowflake zu importieren.

Überprüfen des Status der Erfassung einer Zeile¶

Um den Status der Erfassung einer Zeile an allen möglichen Stellen in ServiceNow und Snowflake zu prüfen, rufen Sie die Prozedur CHECK_RECORD_HISTORY auf:

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

Copy

Wobei:

table_name: Gibt den Namen einer Tabelle der ServiceNow-Instanz an.
sys_id: Gibt die sys_id der zu prüfenden Zeile an.

Die Prozedur gibt ein JSON-Objekt zurück, das die folgenden Eigenschaften enthält:

Eigenschaft	Beschreibung
`table_name`	Name der Tabelle.
`sys_id`	Eindeutiger Bezeichner für die Zeile in ServiceNow.
`status`	Status der Erfassung der Zeile.
`is_present_in_servicenow`	`true`, wenn die Zeile in der Tabelle in ServiceNow vorhanden ist, sonst `false`.
`is_present_in_servicenow_audit_table`	`true`, wenn die Zeile in der Audit-Tabelle in ServiceNow verfolgt wird, sonst `false`.
`is_present_in_snowflake_destination_table`	`true`, wenn die Zeile bereits erfasst wurde und in der Datenbank `dest_db` in Snowflake verfügbar ist, sonst `false`.
`event_log_records`	Array von JSON-Objekten, die Einträge im Ereignisprotokoll für die Zeile mit dieser `sys_id` repräsentieren. Jedes Objekt enthält die folgenden Eigenschaften, die den Spalten in der Ereignisprotokolltabelle entsprechen, die die Zeitstempel und Ereignistypen der Datenänderung angeben: `sys_updated_on` `event_date` `event_type`

Feststellen, ob eine Tabelle auf Löschungen überwacht wird¶

Der Snowflake Connector for ServiceNow® stützt sich auf Auditing, um das Löschen von Datensätzen an Snowflake weiterzugeben.

Um zu überprüfen, ob eine bestimmte Tabelle in ServiceNow so konfiguriert ist, dass das Löschen von Datensätzen überwacht wird, rufen Sie die gespeicherte Prozedur CHECK_IF_AUDIT_ENABLED auf:

CALL CHECK_IF_AUDIT_ENABLED('<table_name>');

Copy

Wobei:

table_name: Gibt den Namen einer Tabelle der ServiceNow-Instanz an.

Diese gespeicherte Prozedur prüft die audit- und no_audit_delete-Konfiguration für die angegebene Tabelle und gibt die Information aus, ob Auditing aktiviert ist oder nicht.

Abrufen von Daten zur Problembehandlung¶

Um Daten zur Problembehandlung zu erhalten, rufen Sie die gespeicherte Prozedur GET_TROUBLESHOOTING_DATA auf:

CALL GET_TROUBLESHOOTING_DATA(<number_of_days>);

Copy

Wobei:

number_of_days: Gibt die Anzahl der Tage in der Vergangenheit an, für die Daten abgerufen werden sollen.

Diese gespeicherte Prozedur gibt die folgenden Daten im Tabellenformat zurück:

Informationen zur Konfiguration
Fehler, die vom Konnektor erkannt werden
Erfassungsverlauf

Das folgende Beispiel zeigt, wie Sie diese gespeicherte Prozedur aufrufen:

USE DATABASE my_connector_servicenow;
  CALL GET_TROUBLESHOOTING_DATA(1);

Copy

Sie können die zurückgegebenen Daten im CSV-Format speichern und an den Snowflake-Support senden.

Testen der Verbindung zu ServiceNow¶

Um zu überprüfen, ob der Konnektor auf eine ServiceNow-Instanz zugreifen kann, rufen Sie die gespeicherte Prozedur GET_CONNECTION_STATUS auf.

Diese gespeicherte Prozedur prüft die Verbindung und die Anmeldeinformationen, die in dem bei der Einrichtung angegebenen Geheimnis gespeichert sind. Sie gibt eine Variante mit zwei Schlüsseln zurück:

Status
details

Das folgende Beispiel zeigt, wie Sie die gespeicherte Prozedur GET_CONNECTION_STATUS aufrufen:

USE DATABASE my_connector_servicenow;
CALL GET_CONNECTION_STATUS();

Copy

Wiederherstellen eines unzugänglichen Objekts¶

Der Konnektor setzt mehrere Datenbankobjekte voraus, die sich außerhalb der Konnektor-Datenbank befinden. Wenn diese Objekte nicht verfügbar sind, funktioniert der Konnektor nicht oder nicht mehr korrekt. Zu den Situationen, in denen Objekte nicht mehr verfügbar sein können, gehören:

Löschen eines Objekts
Wiederherstellen eines Objekts ohne Beibehaltung oder Wiederherstellung der erforderlichen Berechtigungszuweisungen
Entziehen der Berechtigungen, die der Konnektor für die Nutzung dieser Objekte benötigt

In den meisten Fällen können Sie diese Objekte manuell wiederherstellen, indem Sie sie neu erstellen und die erforderlichen Berechtigungen erteilen. In den folgenden Abschnitten wird beschrieben, wie Sie verschiedene Objekte wiederherstellen können.

Wiederherstellen des Konnektor-Warehouses¶

Wenn der Konnektor den Zugriff auf sein Warehouse verliert, konfigurieren Sie ein neues, indem Sie die gespeicherte Prozedur CONFIGURE_WAREHOUSE aufrufen.

Wiederherstellen des Geheimnisobjekts des Konnektors¶

Wenn das vom Konnektor verwendete Geheimnisobjekt gelöscht wird, müssen Sie das Geheimnis unter demselben Namen in derselben Datenbank und demselben Schema neu erstellen.

Führen Sie den folgenden Befehl aus, um den vollqualifizierten Namen des Geheimnisses zu überprüfen:

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

Copy

Außerdem müssen Sie der vom Konnektor verwendeten kundenspezifischen Rolle, die USAGE-Berechtigung für das neu erstellte Geheimnis erteilen.

Wenn die Datenbank oder das Schema des Geheimnisobjekts gelöscht wird, können Sie es durch Ausführen des Befehls UNDROP wiederherstellen. Dieser Befehl stellt auch das Geheimnisobjekt wieder her.

Wenn Sie den Befehl UNDROP nicht verwenden können, müssen Sie die Datenbank und das Schema mit denselben Namen neu erstellen. Außerdem müssen Sie der vom Konnektor verwendeten kundenspezifischen Rolle die USAGE-Berechtigung für die Datenbank und das Schema erteilen.

Wiederherstellen der API-Integration¶

Wenn die vom Konnektor verwendete API-Integration gelöscht wird, müssen Sie sie unter demselben Namen neu erstellen. Um den Namen der API-Integration zu überprüfen, die der Konnektor erwartet, führen Sie den folgenden Befehl aus:

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

Copy

Denken Sie daran, dass Sie beim Neuerstellen der API-Integration denselben vollqualifizierten Geheimnisnamen und dieselbe ServiceNow-Instanz-URL wie zuvor verwenden müssen.

Um den vollqualifizierten Namen des Geheimnisses zu ermitteln, führen Sie den folgenden Befehl aus:

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

Copy

Um die ServiceNow-Instanz-URL zu ermitteln, führen Sie den folgenden Befehl aus:

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

Copy

Außerdem müssen Sie der vom Konnektor verwendeten kundenspezifischen Rolle die USAGE-Berechtigung für die wiederhergestellte API-Integration erteilen.

Wiederherstellen der Datenbank und des Schemas für die ServiceNow-Daten¶

Wenn die Datenbank oder das Schema der ServiceNow-Daten gelöscht wird, kann das Wiederherstellen nur durch Ausführen des Befehls UNDROP erfolgen. Wenn dieser Befehl nicht verfügbar ist, müssen Sie den Konnektor neu installieren und die ServiceNow-Daten erneut erfassen.

Wenn eine Ansicht, die ServiceNow-Daten enthält, gelöscht wird, sollte sie automatisch neu erstellt werden, wenn die für ihre Erstellung zuständige Hintergrundaufgabe das nächste Mal ausgeführt wird.

Wenn eine der Tabellen, die die ServiceNow-Daten enthalten (entweder die Ereignisprotokolltabelle oder die Rohdatentabelle), gelöscht wird, und Sie diese nicht mit dem Befehl UNDROP TABLE wiederherstellen können, können Sie Folgendes tun, um die Erfassung der ServiceNow-Tabelle erneut zu starten:

Stellen Sie sicher, dass sowohl die Ereignisprotokoll- als auch die Rohdatentabelle für diese ServiceNow-Tabelle gelöscht wurden.
Deaktivieren Sie die ServiceNow-Tabelle.
Rufen Sie die DELETE_TABLE-Prozedur auf.
Aktivieren Sie die ServiceNow-Tabelle.

Wiederherstellen der kundenspezifischen Rolle des Konnektors¶

Wenn die vom Konnektor verwendete kundenspezifische Rolle gelöscht wird, müssen Sie sie unter demselben Namen neu erstellen. Um den Namen der Rolle zu ermitteln, die der Konnektor erwartet, führen Sie die folgende Abfrage aus:

SELECT value FROM GLOBAL_CONFIG WHERE key = 'data_owner_role';

Copy

Außerdem müssen Sie die aufgeführten Berechtigungen der Rolle wiederherstellen. Sie können die Namen der entsprechenden Objekte mithilfe der Ansicht GLOBAL_CONFIG ermitteln.

Außerdem muss die Rolle Eigentümer aller Tabellen und Ansichten sein, die ServiceNow-Daten aus dem entsprechenden Schema enthalten.

Wenn in diesem Schema keine zusätzlichen Tabellen oder Ansichten manuell erstellt wurden, können Sie die Rollen wiederherstellen, indem Sie die Befehle GRANT OWNERSHIP ON ALL TABLES/VIEWS IN SCHEMA ... TO ROLE ... ausführen.

Wenn beispielsweise die ServiceNow-Daten in der Datenbank dest_db und dem Schema dest_schema gespeichert sind, führen Sie zum Wiederherstellen einer Rolle mit dem Namen connector_resources_provider die folgenden Befehle aus:

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

Die neu erstellte Rolle muss auch für die Konnektor-Datenbank erteilt werden. Um beispielsweise die Rolle connector_resources_provider der Datenbank my_connector_servicenow zuzuweisen, führen Sie den folgenden Befehl aus:

GRANT ROLE connector_resources_provider TO DATABASE my_connector_servicenow;

Copy

Wiederherstellen der Benachrichtigungsintegration für den Konnektor¶

Wenn der Konnektor den Zugriff auf das Benachrichtigungsintegrationsobjekt verliert, führen Sie die Verfahren zur Konfiguration von Alerts erneut durch und erstellen Sie das Benachrichtigungsintegrationsobjekt gegebenenfalls neu.

Wenn E-Mail-Benachrichtigungen über Snowsight konfiguriert sind, können Sie diese einfach deaktivieren und wieder aktivieren, um die erforderlichen externen Objekte wiederherzustellen.