Atualmente em nossos servidores dedicado do Perceptive, temos alguns processos de proatividade a ser realizado no banco de dados. Essa proatividade visa a melhoria na entrega das integrações de retorno para nossos parceiros, Midas e Plathion. O intuito dessa publicação é o repasse de conhecimento e proatividade no banco Webtransfer.
Entendendo o processo de consulta
No banco de dados do webtrasnfer, existe uma tabela chamada “TBDATATRANSFER”, onde fica armazenado o status da integração de cada cliente. Existe uma coluna que informa em que ponto o processo está. Essa coluna é a STATUS, segue explicação de cada status:
-
Status 0 – Documento recebido no WebTransfer.
-
Status 1 – Documento transformado pelo mapeador da NDD e disponível para captura.
-
Status 2 – Documento consultado.
-
Status 3 – Documento capturado com sucesso, confirmando a integração.
Observações importantes
-
Alguns clientes realizam a captura diretamente no WebTransfer, mas não executam a chamada final necessária para alterar o status para 3. Nesses casos, o status permanecerá como 2 devido à ausência dessa última chamada.
-
Para os clientes que utilizam o AppAgent em seu ambiente, o status é alterado automaticamente para 3 quando o documento é consumido na pasta de retorno parametrizada no WebTransfer.
Processo de consulta no banco de dados
1º - Precisa verificar qual é o status de integração de cada cliente, com isso você pode executar o seguinte script:
Select count (*) from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 2
OBS: Alguns clientes utilizam o status nº 3 e outros status nº 2 para finalização do processo, conforme explicação na observação acima.
A execução do script é para verificar o status do documento que o jobkey mais tem volumetria, assim, você consegue verificar o status final para cada job.
2º - Com a informação do STATUS final de cada JOBKEY, você irá rodar novamente o script de consulta, porém, para os demais status, segue alguns exemplos abaixo:
Exemplo 1
Verificação da volumetria de documentos travados no banco
No exemplo 1, o status final do jobkey é o 3, você irá realizar o select count com o status nº 2 e nº 1 para verificar quantos documentos estão pendentes de integração.
Select count (*) from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 1
Select count (*) from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 2
Coleta de ID para o Update
Select * from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 1
Select * from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 2
A quantidade de documento que voltar, você irá precisar pegar todos os registros da coluna “ID”, montar o script de update e posteriormente solicitar ao N2 a abertura da task para o time do SRE executar o update desses documentos para o status 0.
Esse update irá permitir que as consultas sejam realizadas novamente e assim realizar a integração do documento no cliente.
Script do Update
UPDATE TBDATATRANSFER SET STATUS = 0 WHERE ID IN (000,000,000,000)
EXEMPLO 2
Verificação da volumetria de documentos travados no banco
No exemplo 2, o status final do jobkey é o 2, você irá realizar o select count com o status nº 1 para verificar quantas notas estão com esse status “nº 1”.
Select count (*) from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 1
Select count (*) from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 2
Coleta de ID para o Update
Select * from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 1
Select * from TBDATATRANSFER where JOBKEY like '%NomedoJob%' and status = 2
A quantidade de documento que voltar, você irá precisar pegar todos os registros da coluna “ID”, montar o script de update e posteriormente solicitar ao N2 a abertura da task para o time do SRE executar o update desses documentos para o status 0.
Esse update irá permitir que as consultas sejam realizadas novamente e assim realizar a integração do documento no cliente.
Script do Update
UPDATE TBDATATRANSFER SET STATUS = 0 WHERE ID IN (000,000,000,000)
Importantes
Temos atualmente dois tipos de integração final com cada cliente, existe clientes que utilizam consultas via wbservice da WebTransfer e outros clientes utilizam o AppAgent Webtransfer no servidor.
A diferença de cada processo é:
1- Clientes que utilizam o WebTransfer, ele tem o processo de realizar as consultas das notas e mantem os status das notas como status 2, para que se necessário realize a consulta de novo.
2- Clientes que usa o AppAgent Webtransfer, será depositado na pasta configurada dentro do servidor do cliente, ao fazer a leitura dos documentos disponibilizados na pasta, volta um retorno ao servidor DC da NDD Perceptive e atualiza o status para nº 3.