Card |
---|
| A integração das marcações do Suricato para o Datasul ocorre através da execução da api recordClockMarkings. Esta api é de responsabilidade do Datasul. Ela realiza diversas validações com a marcação recebida e: - Se estiver tudo correto: atualiza a marcação na tabela marcac_nova_integr.
- Se houver algum problema com a marcação recebida: a atualização não é realizada e é gerado um json de retorno informando o problema ocorrido. Consequentemente, as marcações não aparecem no arquivo gerado através da execução do programa PE7110.
Problema | Possíveis Causas | Análise/Ação | Exemplo Prático |
---|
Erro "oauth2/api/v1/token was not found" ao executar o serviço que chama a api recordClockMarkings | Na execução da api recordClockMarkings está sendo executada a api do token, que se aplica apenas para o Protheus e RM. O Datasul utiliza autenticação básica para a execução da api. | Encaminhar para a equipe de suporte da Telemática validar a chamada da api.
| Consultar o ticket 17075658 | Marcações não estão sendo integradas | 1 - Verificar no arquivo de log do AppServer se a api recordClockMarkings está sendo executada no Datasul | 1) Verificar se o Suricato está conseguindo chamar a nossa api. 1.1) No arquivo do log do appserver verificar se consta a chamada da api rest rh/api/v1/recordClockMarkings. 1.2) Se não constar ou apresentar erro na sua execução: enviar o ticket para o atendimento da telemática para que seja verificado a maneira com a api rest está sendo executada. 1.3) Se constar: verificar se consta a chamada das api´s de: a) Integração prghur/pep/apiRecordClockMarkings.p b) Negócio prghur/pep/peapi016.p 1.4) Se constar algum erro na chamada de algum destes 3 programas, deve ser aberto uma issue de manutenção com a evidência do erro.
|
|
| Realizar um teste via postman para confirmar se a execução da api está OK. | Em se tratando da integração do Suricato x Datasul via api rest recordClockMarkings, a validação e atualização das marcações na tabela marcac_nova_integr é de responsabilidade do Datasul.
Para cada marcação recebida, realizamos as validações e, a API envia para o Suricato o retorno informando se a marcação foi gravada com sucesso ou se ocorreu algum erro nas validações. Atualmente, este retorno não é visível no Datasul; talvez esteja visível no Suricato (confirmar com a Telemática).
Em desenvolvimento: - estamos implementando a geração de um arquivo de log durante a execução da api. Quando estiver liberado, será possível gerar: - um arquivo de log técnico: que demonstrará o json recebido com as marcações enviadas pelo Suricato. - um arquivo de log detalhado: que demonstrará, entre outras informações, se a marcação foi integrada com sucesso ou, caso tenha ocorrido algum erro nas validações demonstrará qual erro ocorreu.
1) Confirmar com o cliente se a marcação que se está tentando integrar é referente à portaria 1510 ou portaria 671. 2) Tendo a confirmação sobre qual portaria se refere a marcação, pegar um exemplo do json para teste na documentação: https://tdn.totvs.com/display/INT/TOTVS+HCM+x+Suricato+-+Api+Rest+recordClockMarkings 3) Realizar o teste via Postman, conforme documento 'Teste via Postman.docx'. 4) Verificar o retorno do teste. Se for: a) 200 : a execução da api ocorreu com sucesso, independente do retorno do processamento da marcação. b) outro retorno: verificar a mensagem que retornou no Postman. Pode ter problema com o usuário e senha informados, ou o ambiente de testes estar fora do ar.
5) Após confirmar que a execução da api nãoe está com problemas, deve-se solicitar ao cliente um exemplo do json contendo algumas marcações que não estão sendo integradas via api. 6) Após receber o arquivo, verifique se a estrutura do mesmo está de acordo com a documentação: https://tdn.totvs.com/display/INT/TOTVS+HCM+x+Suricato+-+Api+Rest+recordClockMarkings 7) Realize testes com o arquivo json enviado pelo cliente, seguindo as orientações do documento "Teste via Postman.docx". Se o erro for simulado, abra uma issue de manutenção, anexando a evidência da simulação.
|
|
|
Card |
---|
label | Suricato via Integração Antiga |
---|
| A integração das marcações do Suricato para o Datasul é de responsabilidade da Telemática.
Problema | Possíveis Causas | Análise/Ação | Exemplo Prático |
---|
"ERRO | SqlExceptionHelper - [DataDirect][OpenEdge JDBC Driver][OpenEdge] Tabela/exibição/sinônimo "SYSPROGRESS.MSA_CONTROL_MARCAC" não pode ser encontrado. (15814)" | Não se trata de erro no produto Datasul, mas sim da conexão que a Telemática está tentando fazer com o banco do nosso produto. | Encaminhar para a equipe de suporte técnico.
| Consultar o ticket 13928979 |
|
Card |
---|
| A integração das marcações do Clock in para o Datasul ocorre através da execução do programa PE9696, e: - Se estiver tudo correto: atualiza a marcação na tabela msa_control_marcac.
- Se ocorrer algum problema durante o processamento: as marcações não são atualizadas e, consequentemente não aparecem no arquivo gerado através da execução do programa PE7110.
Pré-Requisitos: Para verificar os problemas na execução do programa PE9696 é necessário solicitar os seguintes arquivos: - Log de execução - PE9696.txt
- Log técnico
- Log detalhado
- Clientlog
- Extrato de versão
Problema | Possíveis Causas | Análise/Ação | Exemplo Prático |
---|
Fail to compare ORACLE schema; file hcm.CAROL_3C_QUEUE counted num flds: 11 fildes: 13. (2720)
RECIDFLG set; fldinfo count: 13. (4507)
| Erro de sincronismo indicando que existe diferença estrutural entre a tabela que está no schema holder com a estrutura da mesma tabela dentro do banco de dados oracle. | Há duas ações a serem feitas: 1) Encaminhar o ticket para a equipe de suporte técnico do produto, para que seja providenciado o envio de um script, o qual irá excluir o campo Status da tabela carol_3c_queue existente no banco: dthrpyc. 2) Encaminhar o ticket para a equipe que realiza a implantação do 2C para ajuste do arquivo app.config.yml, pois o modo de sincronismo é via BATCH e no DataSul já existe a tabela de fila. Neste caso, ignoreQueueTable deve estar com valor TRUE e o 2C não tentará criar a tabela de fila. | Consultar o ticket 13271595 | Marcações não estão sendo integradas
| 1 - Verificar se há problemas de conexão com a plataforma Carol relacionado ao protocolo TLSv1.1 x Progress 12.8 | Confirmar se a versão do Progress que o cliente utiliza é 12.8. Em caso afirmativo: analisar o arquivo clientlog enviado, verificando se existe o erro "Bad/Unsupported protocol name parameter value TLSv1.1" . - Se existir: verificar em qual patch o cliente se encontra, pois a correção do programa fpapi9696.p foi expedida nos patches 12.1.2407.5, 12.1.2403.11 e 12.1.2311.16. Se o cliente estiver em patch anterior, orientar o cliente a realizar a atualização do patch.
- Se não existir: verificar o item 2 - Problemas de conexão com a plataforma Carol.
Em caso negativo: verificar o item 2 - Problemas de conexão com a plataforma Carol. | Arquivo Clientlog
Consultar o ticket 21031512 | Marcações não estão sendo integradas | 2 - Problemas de conexão com a plataforma Carol | Analisar nos arquivos de log de execução, log detalhado e/ou log técnico se constam as mensagens sobre a finalização da requisição dos dispositivos. - Se não constarem: transferir o ticket para a equipe de suporte do Clock in para a verificação a respeito de certificados, conector e token.
- Se constarem: verificar o item 3 - Verificar se há problemas na requisição dos dispositivos.
OBS: o problema de conexão também pode ser verificado através do teste de conexão disponível no programa FP0540, pasta Carol/Con. | Arquivos de Log´s | Marcações não estão sendo integradas | 3 - Verificar se há problemas na requisição dos dispositivos | Analisar no arquivo do log técnico se constam as mensagens referentes ao detalhamento do json de retorno da requisição de dispositivos (log 9896, log 9895 e log 9894). - Se constarem: significa que a busca dos dispositivos ocorreu com sucesso. Verificar o item do roteiro 4 - Verificar se o dispositivo foi retornado na requisição.
- Se não constarem:
- Analisar no arquivo clientlog a expressão "get_device_list -> v_response_code:". Ela indica o retorno da execução da requisição.
- Caso v_response_code seja diferente de 200 e 201, se usou a opção "Um Dispositivo por Vez', como paliativo deve-se sugerir a utilização da baixa de marcações por Lote de Dispositivos, e vice-versa.
- Caso ainda não funcione, abrir issue de Apoio, contendo todos os arquivos do pré-requisito, além do detalhamento dos passos executados até o momento para tentar identificar o problema.
| Arquivos de Log´s | Marcações não estão sendo integradas | 4 - Verificar se o dispositivo foi retornado na requisição | Analisar no arquivo do log técnico se no JSON de retorno da requisição dos dispositivos consta o dispositivo em questão. - Se não constar: é provável que no Clock in este dispositivo não esteja parametrizado para integrar com o RH. Deve-se orientar o cliente a verificar esta informação e realizar a parametrização, caso necessário.
- Se constar: deve-se verificar o item 5 - Verificar se as informações dos dispositivos estão OK.
| Arquivo de Log Técnico | Marcações não estão sendo integradas | 5 - Verificar se as informações dos dispositivos estão OK | Analisar no arquivo de log detalhado ou arquivo do log de execução a validação dos dispositivos, que indica se o mesmo será ou não considerado para a baixa de marcações. - Se constar mensagem indicando que o dispositivo não será considerado para baixa de marcações (log 9994):
- Em primeiro lugar, deve-se verificar a mensagem que aparece na linha anterior, pois informa o problema que o dispositivo apresentou.
- Em seguida, realizar a parametrização faltante no Datasul ou no Clock in.
- Se constar a mensagem "Validação de Dispositivos Interrompida (log 9988)", indica que o dispositivo foi recebido mas está com alguma informação inconsistente, normalmente relacionado à informação "repcode". Nesse caso, não é possível identificar no arquivo de log detalhado qual é o dispositivo que está apresentando este erro mas, no arquivo de log técnico é possível. Para isto:
- No arquivo de log detalhado, pesquisar pela última palavra "Devicecode:" que aparece antes da mensagem "Validação de Dispositivos Interrompida (log 9988)". O texto que aparecer após esta palavra é o código do último dispositivo que foi validado antes da interrupção do processo de validação dos dispositivos. Anotar este código.
- No arquivo de log técnico, pesquisar o código do dispositivo encontrado no arquivo de log detalhado. Quando encontrar, verificar as informações do próximo dispositivo, pois foi o que apresentou o erro que interrompeu o processo de validação. A informação incorreta/faltante deve ser corrigida/informada no Clock in. Em seguida, deve-se realizar uma nova baixa de marcações (PE9696).
- Se constar mensagem indicando que o dispositivo em questão será considerado para baixa de marcações, deve-se verificar o item 6 - Verificar se há problemas na requisição das marcações.
| Arquivos de Log´s | Marcações não estão sendo integradas | 6 - Verificar se há problemas na requisição das marcações | Analisar no arquivo do log técnico se para o dispositivo em questão consta a mensagem log 9892 com o detalhamento do JSON de retorno das marcações. - Se constar: significa que a busca das marcações ocorreu com sucesso. Verificar o item 7 - Verificar se a marcação foi retornada na requisição.
- Se não constar:
- Analisar no arquivo clientlog a expressão "get_records_list -> v_response_code" para o dispositivo em questão. Ela mostra o retorno da execução da requisição. Se v_response_code for diferente de 200 e 201:
- Procurar na documentação Integração Datasul x Carol - Importação de Batidas Ponto se consta a mensagem que está no clientlog e que está descrito como possível origem.
- Se não identificar o problema, abrir issue de Apoio, contendo todos os arquivos mencionados no item 1, além do detalhamento dos passos executados até o momento para tentar identificar o problema.
| Arquivos de Log´s | Marcações não estão sendo integradas | 7 - Verificar se a marcação foi retornada na requisição | Analisar no arquivo do log técnico se consta a marcação em questão no JSON de retorno da requisição das marcações. - Se constar: analisar no arquivo do log detalhado se consta a marcação em questão.
- Se constar: ou marcação foi processada com sucesso ou já estava integrada. Neste caso, ao executar o programa PE7110, no arquivo CSV gerado, será demonstrada a marcação.
- Se não constar: pode ter ocorrido algum erro com informações de alguma marcação e a mesma não foi processada. Verificar o item 8 - Verificar se faltam informações nas marcações.
- Se não constar: deve-se verificar no Clock in se a marcação possui NSR.
- Se não possuir: transferir o ticket para a equipe de suporte do Clock in para a verificação a respeito da geração do NSR.
- Se possuir: pode ser que a marcação lá no Clock in esteja com um NSR menor que último NSR existente na tabela msa_control_marcac para o REP (dispositivo) onde ela foi registrada. Isto pode ocorrer quando o número do REP foi utilizado em um dispositivo (geralmente em período de testes) e depois foi informado para outro dispositivo. Neste caso, o NSR inicia no número 1 novamente para este segundo dispositivo. Para realizar a conferência:
- Solicitar ao cliente o arquivo gerado pelo programa PE7110, deixando a faixa de datas em aberto (01/01/2000 à 31/12/9999) para que sejam geradas no arquivos todas as marcações que foram baixadas para todos os REP´s.
- Após receber o arquivo, deve-se comparar o número do último NSR que consta para o REP aqui no Datasul com o número do NSR da batida lá no Clock in que não está sendo baixada. Se ficar comprovado que o NSR registrado para a marcação no Clock in está inferior ao último NSR registrado na tabela msa_control_marcac para o mesmo REP, a orientação é solicitar ao cliente que altere do número do REP do dispositivo no Clock in e no cadastro do relógio no Datasul (PE0620). Lembrando que somente as marcações realizadas a partir desta mudança é que serão baixadas para o Datasul.
| Arquivos de Log´s | Marcações não estão sendo integradas | 8 - Verificar se faltam informações nas marcações | Analisar: - No arquivo do log de execução PE9696.txt se consta a mensagem de erro número " 7 - Falha na requisição de marcações. Verifique na Carol Clock-in o conteúdo e o formato dos campos: nsrCode, eventdatestr e piscode".
- No arquivo do log detalhado se consta a mensagem "log 9976", que indica que a marcação possui dados incorretos. Ver para qual dispositivo esta mensagem foi apresentada.
- No arquivo do log técnico a mensagem "log 9889" que consta para o dispositivo em questão. Esta mensagem demonstra o retorno da requisição das marcações para o dispositivo. Verificar se constam as informações: nsrCode, eventdatestr, piscode e mdmpersonid".
- Caso não constem ou estejam sem valores ou valores incorretos transferir o ticket para a equipe de suporte do Clock para analisarem.
Se em pelo menos um destes arquivos constarem as mensagens descritas acima, transferir o ticket para a equipe de suporte do Clock para analisarem. | Não temos os arquivos de log´s demonstrando este problema. Mas por ser um cenário previsto (provavelmente ocorria no passado) mapeamos neste documento. |
|
|