Solução de problemas do conector¶

Este tópico fornece diretrizes para a solução de problemas com o conector Snowflake para ServiceNow.

Neste tópico:

Nota

As seções seguintes descrevem os procedimentos armazenados que são definidos no esquema PUBLIC do banco de dados do conector. Antes de chamar esses procedimentos armazenados, selecione esse banco de dados como o banco de dados a ser utilizado para a sessão.

Por exemplo, se esse banco de dados for nomeado my_connector_servicenow, execute o seguinte comando:

USE DATABASE my_connector_servicenow;

Copy

Verificação da conexão com a instância do ServiceNow¶

Para verificar se o conector Snowflake para ServiceNow pode acessar a instância do ServiceNow, chame o procedimento armazenado TEST_SN_CONNECTION, que é definido no esquema PUBLIC do banco de dados do conector:

CALL TEST_SN_CONNECTION('<table_name>');

Copy

Onde:

table_name: Especifica o nome de uma tabela na instância do ServiceNow.

Se o conector for configurado corretamente, o procedimento armazenado retorna uma linha da tabela especificada.

Por exemplo, se o banco de dados de seu conector for chamado my_connector_servicenow, e você quiser verificar a conexão recuperando uma linha de uma tabela chamada my_table em sua instância do ServiceNow, execute os seguintes comandos:

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

Copy

Comparação de contagem de linhas de tabela no ServiceNow no Snowflake¶

Para comparar a contagem atual de linhas de uma tabela no ServiceNow e Snowflake, chame o procedimento CHECK_SN_ROW_COUNT:

CALL CHECK_SN_ROW_COUNT('<table_name>');

Copy

Onde:

table_name: Especifica o nome de uma tabela na instância do ServiceNow.

Se o tempo do procedimento expirar, o procedimento não poderia usar o stats API para determinar a contagem de linhas da tabela no ServiceNow. Isto pode significar que o número de linhas nesta tabela seja muito grande para ser contado por esta API.

Nota

O número de linhas retornadas pode variar. Uma tabela do ServiceNow pode conter mais linhas que a tabela equivalente do Snowflake. Isto pode ser causado pelas regras da lista de controle de acesso (ACLs) definida para uma determinada tabela no ServiceNow.

Quando um horário de início do intervalo de dados é configurado para uma tabela, os números de linhas retornados provavelmente serão diferentes. A contagem de linhas do ServiceNow ainda representa a contagem de todas as linhas, enquanto, de acordo com a configuração, apenas um número limitado de linhas foi ingerido no Snowflake.

O conector usa diferentes pontos de extremidade para recuperar informações sobre o número de linhas em uma tabela do ServiceNow. O conector usa stats para informações sobre uma tabela, incluindo o número de linhas. Ele usa table para ingerir dados no Snowflake.

Verificação do status da ingestão de uma linha¶

Para verificar o status da ingestão de uma linha em todos os lugares possíveis no ServiceNow e Snowflake, chame o procedimento CHECK_RECORD_HISTORY:

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

Copy

Onde:

table_name: Especifica o nome de uma tabela na instância do ServiceNow.
sys_id: Especifica o sys_id da linha a ser verificada.

O procedimento devolve um objeto JSON contendo as seguintes propriedades:

Propriedade	Descrição
`table_name`	Nome da tabela.
`sys_id`	Identificador único para a linha no ServiceNow.
`status`	Status da ingestão da linha.
`is_present_in_servicenow`	`true` se a linha estiver presente na tabela no ServiceNow; caso contrário, `false`.
`is_present_in_servicenow_audit_table`	`true` se a linha for rastreada na tabela de auditoria no ServiceNow; caso contrário, `false`.
`is_present_in_snowflake_destination_table`	`true` se a linha já tiver sido ingerida e estiver disponível no banco de dados `dest_db` no Snowflake; caso contrário, `false`.
`event_log_records`	Conjunto de objetos JSON que representam entradas no log de eventos para a linha com este `sys_id`. Cada objeto contém as seguintes propriedades, que correspondem às colunas na tabela de log de eventos que especificam os carimbos de data/hora e os tipos de eventos da alteração de dados: `sys_updated_on` `event_date` `event_type`

Como determinar se uma tabela é auditada para exclusão¶

O conector Snowflake para ServiceNow depende de auditoria para propagar a exclusão de registros para o Snowflake.

Para verificar se uma determinada tabela no ServiceNow está configurada para auditar a exclusão de registros, chame o procedimento armazenado CHECK_IF_AUDIT_ENABLED:

CALL CHECK_IF_AUDIT_ENABLED('<table_name>');

Copy

Onde:

table_name: Especifica o nome de uma tabela na instância do ServiceNow.

Este procedimento armazenado verifica a configuração audit e no_audit_delete para a tabela especificada e imprime as informações sobre se a auditoria está ou não habilitada.

Obtenção de dados para solução de problemas¶

Para obter dados de solução de problemas, chame o procedimento armazenado GET_TROUBLESHOOTING_DATA:

CALL GET_TROUBLESHOOTING_DATA(<number_of_days>);

Copy

Onde:

number_of_days: Especifica o número de dias no passado em que os dados devem ser buscados.

Este procedimento armazenado retorna os seguintes dados em formato tabular:

Informações de configuração
Erros experimentados pelo conector
Histórico de ingestão

O exemplo a seguir mostra como chamar este procedimento armazenado:

USE DATABASE my_connector_servicenow;
  CALL GET_TROUBLESHOOTING_DATA(1);

Copy

Você pode salvar os dados retornados no formato CSV para enviar para o suporte Snowflake.

Teste da conexão com o ServiceNow¶

Para validar se o conector pode acessar uma instância ServiceNow, chame o procedimento armazenado GET_CONNECTION_STATUS.

Este procedimento armazenado verifica a conexão e as credenciais armazenadas no segredo fornecidas durante a configuração. Ele retorna uma variante com duas chaves:

status
detalhes

O exemplo a seguir mostra como chamar e executar o procedimento armazenado GET_CONNECTION_STATUS:

USE DATABASE my_connector_servicenow;
CALL GET_CONNECTION_STATUS();

Copy

Recuperação de um objeto inacessível¶

O conector requer múltiplos objetos de banco de dados que são externos ao banco de dados do conector. Se esses objetos não estiverem disponíveis, o conector falhará ou deixará de funcionar corretamente. Situações em que os objetos podem ficar indisponíveis incluem:

Descarte de objetos.
Recriação de um objeto sem manter ou restaurar as concessões necessárias.
Revogação das concessões necessárias para que o conector utilize esses objetos.

Na maioria dos casos, você pode restaurar estes objetos manualmente recriando-os e concedendo os privilégios necessários. As seções a seguir descrevem como restaurar diferentes objetos.

Restauração do warehouse do conector¶

Se o conector perder o acesso a seu warehouse, configure um novo chamando o procedimento armazenado CONFIGURE_WAREHOUSE.

Restauração do objeto secreto do conector¶

Se o objeto secreto usado pelo conector for descartado, você deverá recriar o segredo usando o mesmo nome no mesmo banco de dados e esquema.

Para verificar o nome completo qualificado do segredo, execute o seguinte comando:

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

Copy

Além disso, você deve conceder o privilégio USAGE no segredo recriado à função personalizada usada pelo conector.

Se o banco de dados ou esquema do objeto secreto for descartado, você poderá recuperá-lo executando o comando UNDROP. Este comando também recuperará o objeto secreto.

Se você não puder usar o comando UNDROP, então você deverá recriar o banco de dados e o esquema usando os mesmos nomes. Você também deve conceder o privilégio USAGE no banco de dados e esquema à função personalizada usada pelo conector.

Restauração da integração de API¶

Se a integração de API usada pelo conector for descartada, você deverá recriá-la usando o mesmo nome. Para verificar o nome da integração de API que o conector está esperando, execute o seguinte comando:

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

Copy

Ao recriar a integração de API, lembre-se de usar o mesmo nome secreto totalmente qualificado e URL da instância do ServiceNow como os usados anteriormente.

Para determinar o nome totalmente qualificado do segredo, execute o seguinte comando:

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

Copy

Para determinar o URL da instância do ServiceNow, execute o seguinte comando:

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

Copy

Você também deve conceder o privilégio USAGE na integração recriada de API à função personalizada utilizada pelo conector.

Restauração do banco de dados e esquema para os dados do ServiceNow¶

Se o banco de dados ou esquema para os dados do ServiceNow for descartado, a única maneira de recuperar é executando o comando UNDROP. Se este comando não estiver disponível, você deverá reinstalar o conector e fazer a ingestão dos dados do ServiceNow novamente.

Se uma exibição contendo os dados do ServiceNow for descartada, ela deverá ser recriada automaticamente na próxima vez em que a tarefa de fundo responsável pela sua criação for executada.

Se uma das tabelas contendo os dados do ServiceNow (a tabela de logs de eventos ou dados brutos) for descartada e não for possível usar o comando UNDROP TABLE para recuperá-la, faça o seguinte para iniciar a ingestão da tabela do ServiceNow novamente:

Certifique-se de que os logs de eventos e as tabelas de dados brutos desta tabela do ServiceNow sejam descartados.
Desative a tabela do ServiceNow.
Use o procedimento DELETE_TABLE.
Ative a tabela do ServiceNow.

Restauração da função personalizada do conector¶

Se a função personalizada usada pelo conector for descartada, você deverá recriá-la usando o mesmo nome. Para determinar o nome da função que o conector está esperando, faça a seguinte consulta:

SELECT value FROM GLOBAL_CONFIG WHERE key = 'data_owner_role';

Copy

Você também deve restaurar os privilégios listados para a função. Você pode determinar os nomes dos objetos correspondentes usando a exibição GLOBAL_CONFIG.

Além disso, a função deve ser a proprietária de todas as tabelas e exibições que contenham dados do ServiceNow do esquema correspondente.

Se nenhuma tabela ou exibição adicional foi criada manualmente neste esquema, você poderá restaurar as funções executando os comandos GRANT OWNERSHIP ON ALL TABLES/VIEWS IN SCHEMA ... TO ROLE ....

Por exemplo, se os dados do ServiceNow estiverem armazenados no banco de dados dest_db e o esquema dest_schema, para restaurar uma função chamada connector_resources_provider, execute os seguintes comandos:

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

A função recriada também deve ser concedida ao banco de dados do conector. Por exemplo, para conceder a função chamada connector_resources_provider ao banco de dados my_connector_servicenow, execute o seguinte comando:

GRANT ROLE connector_resources_provider TO DATABASE my_connector_servicenow;

Copy

Restauração da integração da notificação do conector¶

Se o conector perder o acesso ao objeto de integração de notificação, faça os procedimentos para configurar novamente os alertas, recriando o objeto de integração de notificação, se necessário.

Se as notificações por e-mail forem configuradas via Snowsight, então você pode simplesmente desativá-las e reativá-las para restaurar os objetos externos necessários.