Problembehandlung des Konnektors

Der Snowflake Connector für ServiceNow® V2 unterliegt den Nutzungsbedingungen für Snowflake Connector.

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

Unter diesem Thema:

Bemerkung

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

Wenn diese Anwendung beispielsweise my_connector_servicenow heißt und Sie die Prozedur des Konnektors TEST_CONNECTION aufrufen, indem Sie die folgenden Befehle ausführen:

USE APPLICATION my_connector_servicenow;
CALL TEST_CONNECTION();
Copy

Probleme bei der Installation des Konnektors beheben

Die meisten Probleme bei der Installation des Konnektors stehen im Zusammenhang mit der ACLs-Einstellung in den Metadaten-Tabellen wie sys_db_object, sys_dictionary und sys_glide_object. Darüber hinaus benötigt der Konnektor Zugriff auf die Tabelle sys_table_rotation, um die richtige Datenaufnahme-Strategie zu bestimmen, und optional auf die Journal-Tabelle (in der Regel sys_audit_delete), um das Löschen von Daten zu propagieren.

Fehler bei der Authentifizierung

Es können Probleme auftreten, wenn eine Verbindung zu ServiceNow im Installationsassistenten herstellt oder die Prozedur SET_CONNECTION_CONFIGURATION manuell ausführt. Wenn bei diesem Schritt Fehler auftreten, stellen Sie bitte sicher, dass der Benutzer, der den Konnektor installiert hat, Zugriff auf die Tabelle sys_db_object hat.

Die Fehler-Statuscodes, die mit ACL in Zusammenhang stehen könnten, sind in dem von der Prozedur SET_CONNECTION_CONFIGURATION zurückgegebenen JSON-Objekt die folgenden:

  • REQUEST_FAILED

Sie können die folgende Abfrage ähnlich der des Konnektors durchführen, um den Zugriff zu überprüfen. Solange die Anfrage nicht das erwartete Ergebnis liefert, ist es nicht möglich, den Konnektor zu installieren. So verwenden Sie zum Beispiel curl zum Senden der HTTP-Anfrage:

# 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"
Copy
Wobei:
servicenow_instance

Gibt den Namen Ihrer ServiceNow®-Instanz an.

username und password

Geben Sie die Anmeldeinformationen für Ihre ServiceNow®-Instanz an.

Beispielhafte Antworten:

  • Zumindest einige der Felder werden zurückgegeben – der Benutzer hat die erforderlichen Berechtigungen für den Zugriff auf die Tabelle.

  • Die Antwort ist leer – der Benutzer hat die Berechtigung zum Zugriff auf die Tabelle, aber nicht auf den verarbeiteten Datensatz. Das könnte zu einem späteren Zeitpunkt Probleme verursachen.

  • Die Antwort enthält einen Fehler – der Benutzer verfügt nicht über die erforderlichen Berechtigungen für den Zugriff auf die Tabelle.

Fehler im Quellschritt validieren

Es können Probleme auftreten, wenn die Quelle im Installationsassistenten validiert oder die Prozedur FINALIZE_CONNECTOR_CONFIGURATION manuell ausführt. Wenn bei diesem Schritt Fehler auftreten, vergewissern Sie sich bitte, dass der Benutzer, der den Konnektor installiert hat, über die erforderlichen Berechtigungen für den Zugriff auf die Metadaten-Tabellen verfügt.

Die Fehler-Statuscodes, die mit ACL in Zusammenhang stehen könnten, sind in dem von der Prozedur FINALIZE_CONNECTOR_CONFIGURATION zurückgegebenen JSON-Objekt die folgenden:

  • METADATA_TABLE_ACCESS_VALIDATION_ERROR

  • JOURNAL_TABLE_ACCESS_VALIDATION_ERROR

Sie können die folgenden Abfragen ähnlich denen des Konnektors durchführen, um den Zugriff zu überprüfen. Solange die Anfragen nicht die erwarteten Ergebnisse liefern, ist es nicht möglich, den Konnektor zu installieren. So verwenden Sie zum Beispiel curl zum Senden der HTTP-Anfrage:

# 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"
Copy
Wobei:
servicenow_instance

Gibt den Namen Ihrer ServiceNow®-Instanz an.

username und password

Geben Sie die Anmeldeinformationen für Ihre ServiceNow®-Instanz an.

journal_table

Gibt den Namen Ihrer ServiceNow®-Tabelle an, die für die Löschungsprüfung verwendet wird. Normalerweise hat dies den Wert sys_audit_delete.

Beispielhafte Antworten:

  • Alle erwarteten Felder sind in der Antwort vorhanden – der Benutzer hat die erforderlichen Berechtigungen.

  • Einige der erwarteten Felder fehlen – der Benutzer verfügt nicht über die erforderlichen Berechtigungen für alle Spalten.

  • Die Antwort ist leer – der Benutzer verfügt nicht über die erforderlichen Berechtigungen für alle Zeilen.

  • Die Antwort enthält einen Fehler – der Benutzer verfügt nicht über die erforderlichen Berechtigungen für die Tabelle.

Überprüfen der Verbindung zur ServiceNow®-Instanz

Um zu überprüfen, ob Snowflake Connector for ServiceNow®V2 auf die ServiceNow®-Instanz zugreifen kann, rufen Sie die gespeicherte Prozedur TEST_CONNECTION auf:

CALL TEST_CONNECTION();
Copy

Wenn der Konnektor korrekt eingerichtet ist, gibt die gespeicherte Prozedur die folgende Antwort zurück:

{
  "responseCode": "OK",
  "message": "Test request to ServiceNow succeeded."
}
Copy

Überprüfen des Zugriffs auf eine bestimmte Tabelle in der ServiceNow®-Instanz

Um zu überprüfen, ob Snowflake Connector for ServiceNow®V2 auf Daten aus der spezifischen Tabelle in der ServiceNow®-Instanz zugreifen kann, rufen Sie die in TEST_TABLE_ACCESS gespeicherte Prozedur auf:

CALL TEST_TABLE_ACCESS('<table_name>');
Copy

Wobei:

table_name

Gibt den Namen einer Tabelle der ServiceNow®-Instanz an.

Wenn der Konnektor korrekt eingerichtet ist und dem Benutzer, der den Konnektor verwendet, Daten zur Verfügung stehen, gibt die gespeicherte Prozedur die folgende Antwort zurück:

{
  "responseCode": "OK",
  "message": "Test request to ServiceNow® succeeded."
}
Copy

Bemerkung

Wenn die Tabelle leer ist oder alle Zeilen aufgrund von ACLs vor dem Konnektor verborgen sind, wird folgende Meldung angezeigt: Test request to ServiceNow® succeeded but it didn't return any record.. Vergewissern Sie sich in dieser Situation, dass die Tabelle wirklich leer ist. Wenn Zeilen über die UI sichtbar sind, bedeutet dies, dass der Konnektor nicht in der Lage ist, sie aufzunehmen.

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_ROW_COUNT auf:

CALL CHECK_ROW_COUNT('<table_name>');
Copy

oder

CALL CHECK_ROW_COUNT('<table_name>', <max_sys_created_on>);
Copy

Wobei:

table_name

Gibt den Namen einer Tabelle der ServiceNow®-Instanz an.

max_sys_created_on

Gibt einen zusätzlichen optionalen Filter auf den Maximalwert der Spalte sys_created_on an. Nur Zeilen, die mit diesem Filter übereinstimmen, werden gezählt. Der Standardwert für diesen Parameter ist NULL, was bedeutet, dass der Filter nicht angewendet wird. Dieser Parameter hilft Ihnen, nur die Anzahl der Datensätze zu vergleichen, die bereits in Snowflake aufgenommen wurden, ohne dabei Konten zu berücksichtigen, die kürzlich in ServiceNow® erstellt, aber noch nicht in Snowflake aufgenommen wurden.

Das folgende Beispiel zeigt, wie Sie die gespeicherte Prozedur CHECK_ROW_COUNT mit dem Parameter max_sys_created_on aufrufen:

CALL CHECK_ROW_COUNT('sys_db_object', '2021-09-10 12:34:56');
Copy

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 gegebene Tabelle in ServiceNow® festgelegt wurden.

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 Datenaufnahmestatus einer Zeile

Um den Datenaufnahmestatus 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 der 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®V2 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.

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

Eigenschaft

Beschreibung

response_code

OK-Wert, wenn die Prozedur erfolgreich war, oder ein Code des Fehlers im Falle eines Fehlers.

audit

Wert des Attributs audit für die geprüfte Tabelle. Wenn diese Einstellung auf „true“ gesetzt ist, ist die Prüfung für die Tabelle aktiviert.

no_audit_delete

Wert des Attributs no_audit_delete für die geprüfte Tabelle. Wenn es eingestellt ist, überschreibt es den Wert aus dem Feld audit für Ereignisse zum Löschen.

summary

Von Menschen lesbare Erklärung, ob die Prüfung in der Tabelle aktiviert ist, basierend auf den Werten der Felder audit und no_audit_delete. Die Prüfung wird in der Tabelle aktiviert, wenn entweder:

  • das audit-Feld auf „true“ gesetzt ist und no_audit_delete nicht auf „true“ gesetzt ist.

  • no_audit_delete auf „false“ gesetzt ist.

Abrufen von Daten zur Problembehandlung

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

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

Wobei:

from_timestamp

Gibt den Beginn des Datumsbereichs (in der Zeitzone UTC) an, für den Daten abgerufen werden sollen.

to_timestamp

Gibt das Ende des Datumsbereichs (in der Zeitzone UTC) an, für den 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:

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

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

Wiederherstellen eines unzugänglichen Objekts

Der Konnektor erfordert mehrere Datenbankobjekte, die sich außerhalb der Konnektoranwendung 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 UPDATE_WAREHOUSE aufrufen.

Wiederherstellen von Datenbank und Schema 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 aufnehmen.

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 Datenaufnahme der ServiceNow®-Tabelle erneut zu starten:

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.

Ermitteln des Grundes für fehlende Spalten in vereinfachten Ansichten

Der Konnektor erstellt vereinfachte (flat) Ansichten im Zielschema auf der Grundlage der ServiceNow®-Metadaten. Es gibt mehrere Gründe, warum eine Spalte auf der Snowflake-Seite fehlen kann.

Prüfen, ob Spaltenmetadaten in Snowflake vorhanden sind

Um zu überprüfen, ob Spaltenmetadaten in der Tabelle sys_dictionary auf Snowflake vorhanden sind, führen Sie die folgende Abfrage aus:

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

Wenn die Tabelle, die Sie untersuchen, übergeordnete Tabellen hat (geerbt von einer anderen Tabelle in ServiceNow®) und die Spalte, die Sie suchen, der übergeordneten Tabelle hinzugefügt wurde, sollten Sie stattdessen den Namen der übergeordneten Tabelle verwenden.

Um alle Tabellen aufzulisten, von denen die Tabelle, die Sie interessiert, erbt, verwenden Sie die folgende Abfrage:

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;
Copy

Wenn Zeilen zurückgegeben werden, wurden die Metadaten für die Spalte korrekt in Snowflake aufgenommen, aber die Ansicht wurde noch nicht aktualisiert. Prüfen Sie den Status, und prüfen Sie außerdem Folgendes:

  • Wenn die Ansicht kürzlich aktualisiert wurde, aber die Spalte immer noch nicht vorhanden ist, wenden Sie sich bitte an den Support.

  • Wenn die Ansicht noch nicht aktualisiert wurde, warten Sie auf den nächsten Datenaufnahme-Zeitplan.

Wenn ein leeres Ergebnis zurückgegeben wird, bedeutet dies, dass der Konnektor noch keine Metadaten für diese Spalte aufgenommen hat. Sie müssen auf der Seite ServiceNow® überprüfen, ob der Datensatz für den Konnektor sichtbar ist und den richtigen Zeitstempel hat.

Aktualisierungsstatus anzeigen

Um zu überprüfen, wann die Ansichten für eine bestimmte Tabelle zuletzt aktualisiert wurden und ob der Vorgang erfolgreich war, führen Sie die folgende Abfrage aus:

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

Wenn die letzte Aktualisierung fehlgeschlagen ist, können Sie die Ereignistabelle abfragen und nach Fehlern suchen, die vom Konnektor gemeldet wurden.

ServiceNow®-Verfügbarkeit von Spaltenmetadaten anzeigen

Es ist möglich, dass der Grund für die fehlenden Spalten in der vereinfachten Ansicht darin liegt, dass die Spaltenmetadaten nicht vom Konnektor aufgenommen werden können. Dies kann dadurch verursacht werden, dass ACLs verhindern, dass die Zeile in der Tabelle sys_dictionary von der Tabellen-API zurückgegeben wird. Ein anderer möglicher Grund ist ein vergangener Zeitstempelwert in der Spalte sys_updated_on. Es kann auch der Fall sein, dass die Spalten-/Tabellendefinition aus einer anderen ServiceNow®-Instanz importiert wurde. Um festzustellen, ob der Konnektor auf die Spaltenmetadaten zugreifen kann, führen Sie eine GET-Anfrage auf dem folgenden Endpunkt aus:

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

Wenn ein leeres Ergebnis zurückgegeben wird, kann der Konnektor nicht auf die Spalte zugreifen. Die Spalte kann durch eine ACL geschützt oder nicht vorhanden sein.

Wenn eine Spaltendefinition zurückgegeben wurde, prüfen Sie den Wert im Feld sys_updated_on. Prüfen Sie, ob das Datum mit dem erwarteten Zeitpunkt übereinstimmt, an dem die Spalte der Tabelle hinzugefügt wurde. Wenn die Spalte aus einer anderen Instanz importiert wurde, wird möglicherweise der Zeitpunkt ihrer Erstellung angezeigt. Der CDC-Mechanismus (inkrementelle Aktualisierungen) im Konnektor bemerkt möglicherweise nicht, dass der Datensatz mit einem Datum hinzugefügt wurde, das in der Vergangenheit liegt. Lösen Sie in diesem Fall ein Neuladen der Tabelle sys_dictionary aus.

Der Konnektor ist nicht verfügbar

Der Konnektor kann in den ERROR-Zustand übergehen, was aus verschiedenen Gründen geschehen kann. Zum Beispiel ein interner Fehler im Konnektor, der nicht behoben werden kann. In solchen Situationen wird die Fehlermeldung Connector unavailable angezeigt, wenn der Zustand des Konnektors untersucht wird.

Derzeit gibt es keinen automatischen Wiederherstellungsmechanismus für diesen Zustand. Sie können jedoch immer noch verschiedene Funktionen des Konnektors ausführen, darunter die Prozedur EXPORT_CONNECTOR_STATE.

Um zu prüfen, ob sich der Konnektor in einem ERROR-Zustand befindet, führen Sie die Abfrage aus:-

CALL GET_CONNECTOR_STATUS();
Copy

Bitte wenden Sie sich außerdem an den Snowflake Support, damit wir das Problem besser verstehen oder feststellen können, wie es möglicherweise vermieden werden kann. Sie sollten auch manuelle Neuinstallation des Konnektors ausführen, um den Konnektor wieder in einen funktionierenden Zustand zu versetzen. Beachten Sie, dass zuvor aufgenommene Daten nicht verloren gehen und der Konnektor die Aufnahme dort fortsetzen kann, wo er zuvor aufgehört hat.