¶ Identificando problemas relacionados ao serviço em Integrações Força de Vendas Com ETL SysMiddle ConnectUs
Esta página está em construção
- O conteúdo desta página, vai auxiliar a identificação de problemas comuns a todas as integrações força de vendas que utilizam o ETL SysMiddle ConnectUs.
- Para problemas específicos de cada integração, a sua documentação deverá ser consultada.
¶ Como identificar se o serviço está rodando?
- A partir da versão 10.24.01.13, no formulário Log de Integrações força de vendas, na aba Reg. Já enviados, foi adicionado o campo Último início de ciclo de integração.
As integrações, funcionam como uma lista de tarefas.
Ao iniciar a lista de tarefas, o campo será atualizado com a data/hora.
Quando a lista de tarefas chegar no final, ela será reiniciada, voltando para a primeira tarefa da lista e assim sucessivamente.
Este processo recebe o nome Ciclo de integração.
A duração do ciclo de integração, vai depender da quantidade de registros pendentes para envio/recebimento podendo demorar 5/10/20 minutos.
Se o campo ficar sem atualização por muito tempo, pode ser um indicador que o serviço não está rodando ou que não está conseguindo conectar com o banco de dados.
Se o campo estiver sendo atualizado, mas a integração está com sintomas de estar parada, pode ser que ela esteja com o layout desatualizado.
Isso pode ocorrer após uma atualização de versão do RZBusiness.
¶ Verificando o log de atualização de layout
-
A partir da versão 10.24.01.13, no formulário Log de Integrações força de vendas, na aba Recebim./Gerais, será possível consultar os logs de tentativas automáticas de atualização do layout (glc) da integração.
-
Abaixo um print exibindo um log que o layout precisa ser atualizado:
-
Abaixo, um log com falha na tentativa de baixar o arquivo:
As imagens acima, tratam apenas um cenário.
Diversas situações podem ocorrer.
Caso existam entradas recentes neste log, com mensagens repetidas, deve ser considerada a possibilidade de não estar sendo possível atualizar o layout automaticamente.
Importante:
Óbviamente, a gravação destes logs e qualquer outro que esteja persistido na base de dados, requer que o ETL esteja se conectando ao banco.
A atualização automática do layout da integração, só é possível caso todos os passos do tutorial de instalação, tenham sido seguidos à risca.
Nos casos nos quais não está sendo possível atualizar o layout automaticamente, deverá realizar o procedimento manualmente. (Consultar o link acima).
Nos casos nos quais as verificações acima não foram suficientes para determinar a causa do problema, ou se não tiver entrada de logs, deverá validar a conexão com o banco de dados e ou consultar os logs nativos do serviço ETL (arquivos).
O log de tentativas de atualização de layout, pode ser consultado no arquivo de log Default
¶ Últimas requisições com falha e sucesso
- No formulário de logs de integração força de vendas, na aba Reg. Já enviados, existem 2 campos de data/hora que representam as últimas requisições processadas pela API que retornaram respectivamente com falha e sucesso.
- O campo representando a última requisição com falha, se trata de requisições processadas pela API e capturadas pelo ETL de integração com retorno de falha, seja por não passar em alguma validação de regra de negócio da API ou por serviço inacessível. Registros que não puderam ser processados por falha no mapeamento, podem ser acompanhados pelos arquivos de log nativos do etl, detalhados mais adiante neste documento.
¶ Como funciona a conexão do serviço ETL com o banco de dados?
Os dados de conexão, são fornecidos ao serviço ETL pelo arquivo AliasRZ.ini, que deve estar na pasta Assemblies dentro da pasta onde o serviço foi instalado.
Quando a base do cliente é hospedada na nossa estrutura (nuvem), também é necessário ter os arquivos de certificado (ca.crt, client.crt e client.key) para estabelecer a conexão segura com o servidor.
Todos estes arquivos são baixados automaticamente, mas para isso ocorrer, é necessário estar corretamente configurado no aplicativo RZConfigIntegracaoFV.exe que pode ser encontrado dentro da pasta Assemblies.
Devido aos certificados expirarem a cada 72h, para bases de dados hospedadas na nossa estrutura, é obrigatório configurar o agendamento da atualização dos certificados em uma hora que o computador esteja ligado.
Os logs de atualização dos dados de certificado e alias, podem ser consultados no caminho: [PastaOndeOServicoFoiInstalado]/Log/RZAgenteIntegracao
¶ Como consultar os logs nativos (arquivos) do serviço ETL?
Os arquivos são salvos na pasta Log contida dentro da pasta onde o serviço foi instalado.
Abaixo os logs relevantes para os nossos serviços:
Default - Este log, registra eventos diversos de falha e sucesso e também registra logs comandados dentro do layout de integração, por exemplo, os logs de tentativas de atualização do layout.
Exception - Este log, registra eventos de falha nos processos.
Ele deve ser consultado para identificar qual é o log correto a ser verificado para encontrar a causa do problema.
Todos os logs detalhados abaixo, tem os eventos de erro e de sucesso separados em pasta:
APIConnector - Este log é gerado pelas interações com as APIs integradas.
DirectoryConnector - Este log é gerado pelas interações com as tarefas ligadas a diretórios (pastas).
São utilizados quando é necessário separar um arquivo JSon que representa um array (muitos registros) em um arquivo único.
RZAgenteIntegracao - Este log é gerado pelo agente que baixa os arquivos de alias e certificados requeridos para o serviço ETL se conectar ao banco de dados
SmartDbInputConnector - Este log é gerado em processos de entrada de banco (Insert ou Update).
SmartDbOutputConnector - Este log é gerado em processos de saída de banco (Select).
Para facilitar a identificação de problemas o ETL também gera uma cópia dos arquivos que foram encaminhados aos processos internos (pasta BkpDiretorios, contida dentro da pasta Servico contida na pasta onde o serviço foi instalado.
¶ Como consultar a pasta de cópia dos arquivos encaminhados aos processos internos (BkpDiretorios)?
As pastas são geradas de acordo com a próxima tarefa a ser executada.
Para cada arquivo gerado na pasta Diretorios que será a pasta que o serviço vai processar, é gerado o mesmo registro espelhado na pasta BkpDiretorios.
Exemplos de funcionamento:
1 - Cadastro de um registro na plataforma
É executado um conector de sáida de banco que executa uma consulta que retorna os registros pendentes de cadastro.
Cada registro retornado é salvo em um arquivo Json na pasta /Servico/Diretorios/API/Cadastro/NomeDaEntidade.
No próximo passo é executado um conector de API que lê a pasta anterior e passa cada registro para API e salva o retorno na pasta /Servico/Diretorios/BD/Insert/NomeDaEntidade.
No próximo passo é executado um conector de Entrada de Banco que lê a pasta e insere os registros no banco de dados, na tabela de dê/para correspondente á entidade.
Os retornos podem ser:
Sucesso, o registro é incluído na tabela de dê/para com a chaveintegração retornada pela plataforma no momento do cadastro
Falha, o registro é incluído na tabela de dê/para correspondente com a chaveintegração = 0, a mensagem de falha e o código HTTP de retorno
Nunca exclua ou renomeie a pasta BD/INSERT se houver arquivos dentro dela.
Isso vai impedir a inclusão do dê/para do registro, fazendo com que o mesmo registro seja enviado para a plataforma no próximo ciclo, causando problemas como duplicação de registros na plataforma entre outros.
Caso seja necessário reinstalar o serviço e a pasta BD/INSERT não estiver vazia, faça um backup dela antes do procedimento e após a instalação, copie de volta respeitando a mesma árvore original.
2 - Atualização de um registro na plataforma
É executado um conector de sáida de banco que executa uma consulta que retorna os registros pendentes de atualização.
Cada registro retornado é salvo em um arquivo Json na pasta /Servico/Diretorios/API/Atualizacao/NomeDaEntidade.
No próximo passo é executado um conector de API que lê a pasta anterior e passa cada registro para API e salva o retorno na pasta /Servico/Diretorios/BD/Update/NomeDaEntidade.
No próximo passo é executado um conector de Entrada de Banco que lê a pasta e atualiza os registros no banco de dados na tabela de dê/para correspondente á entidade.
Os retornos podem ser:
Sucesso, o campo correspondente á flag de pendência de atualização é atualizado na tabela de dê/para
Falha, os campos correspondentes à descrição da falha e código HTTP de retorno são atualizados na tabela de dê/para correspondente.
3 - Obtenção de registros da plataforma
É executado um conector de sáida de banco que executa uma consulta que retorna os dados para montar a requisição que será efetuada na API.
O resultado é salvo em um arquivo Json na pasta /Servico/Diretorios/API/Get/NomeDaEntidade.
No próximo passo é executado um conector de API que lê a pasta anterior e passa cada registro para API e salva o retorno na pasta /Servico/Diretorios/BD/Insert/NomeDaEntidade.
No próximo passo é executado um conector de Entrada de Banco que lê a pasta e inclui os registros no banco de dados na tabela correspondente á entidade.
Importante - Importação de pedidos geram logs.
Caso um pedido não seja internalizado, a primeira verificação, deve ser feita no formulário de logs de integração força de vendas, na aba específica.
Consulte a documentação específica da integração, para maiores informações.
Qual pasta devo consultar para verificar o arquivo que a API devolveu na requisição?
Conforme detalhado na explicação do funcionamento acima, os arquivos que devem ser consultados são os contidos na pasta BD (Insert ou Update), pois neles estão contidos os dados que a api retornou no momento da requisição.
Lembrando que quando o serviço processa um arquivo contido na pasta Diretorios ele é excluído após o processamento.
Por este motivo, deve-se consultar os arquivos nas pastas espelhadas BkpDiretorios
Arquivos que não foram processados por falha
Os arquivos cujo processamento gerou falha de processamento, por exemplo, falha ao gerar insert, falha ao executar o mapeamento (transformação do formato do arquivo) e etc, são movidos para a pasta de arquivos não processados:
[PastaOndeOServicoFoiInstalado]/Unprocessed
¶ Quais arquivos devem ser disponibilizados em caso de chamado referente à integrações Força de vendas?
- Para bases de dados locais, o backup deve ser disponibilizado.
- Nos casos onde será necessário validar como a API devolveu o registro envolvido, deverá disponibilizar a pasta BD da entidade correspondente, contida na pasta BkpDiretorios .
- Em caso de não processamento de registro pela API, a pasta "Unprocessed" ou a pasta API da entidade correspondente, contida na pasta BkpDiretorios.