Histórico da Página

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, sendo necessário informar o usuário e senha.

Encaminhar Transferir o ticket para a equipe de suporte da Telemática validar a chamada da api.

Solicitar ao cliente o arquivo do log do servidor de aplicação gerado durante um período no qual houve a execução da api recordClockMarkings e que as marcações não foram baixadas para o Datasul. 

Analisar o arquivo enviado, verificando se consta a expressão "rh/api/v1/recordClockMarkings".

• Se não constar: transferir o ticket para o atendimento da telemática para que seja verificado sobre a execução da api rest.
• Se constar: verificar se constam as mensagens "#novaapi       pi_recebe_marcac -> Início criação tt_marcac" e "#novaapi       pi_analisa_marcacoes -> Início Validações".
  • Se constar:  significa que as api´s de integração e negócio: prghur/pep/apiRecordClockMarkings.p e prghur/pep/peapi016.p, respectivamente, foram executadas.

Se a versão do patch que o cliente se encontra for 12.1.2411.2, 12.1.2407.8, 12.1.2403.14  ou superior:

• • • Verificar o item2 - Analisar os arquivos de logs técnico e detalhado.

Se a versão do patch que o cliente se encontra for inferior à 12.1.2411.2, 12.1.2407.8 ou 12.1.2403.14:

• • • Transferir o ticket para a equipe da Telemática analisar o JSON retornado na execução da API para verificar se consta algum erro nas marcações enviadas para o Datasul.
  • Se não constar: erros, verificar o item 2 - Realizar um teste via postman para confirmar se a execução da api está OK.

Arquivo Log Servidor de Aplicação

Solicitar que o cliente ative a geração dos log´s detalhado e técnico no programa PE0400 e envie os arquivos gerados para análise.

Analisar os arquivos de log´s verificando se as marcações apresentaram alguma inconsistência.

• Em caso afirmativo: verificar na documentação da api recordClockMarkings se a mensagem de erro se refere a alguma informação que pode ser corrigida no Datasul (ex: mensagem 9985). 
  • Em caso afirmativo: orientar o cliente com relação à correção a ser feita.
  • Em caso negativo: transferir o ticket para a equipe da Telemática analisar as informações das marcações, anexando os arquivos de log´s detalhado e técnico.
• Em caso negativo ou se a mensagem de erro estiver relacionada à alguma informação que está inconsistente no JSON gerado para o envio das marcações via api: transferir o ticket para a equipe da Telemática analisar as informações das marcações, anexando os arquivos de log´s detalhado e técnico.

Confirmar com o cliente se a marcação que se está tentando integrar é referente à portaria 1510 ou portaria 671.

Tendo a confirmação sobre qual portaria se refere a marcação, pegar um exemplo do json para teste na documentação da api recordClockMarkings.

Realizar o teste via Postman, conforme documento Teste via Postman.

Verificar o retorno do teste. Se for:

• 200 : a execução da api ocorreu com sucesso. 
• 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.

Transferir o ticket para a equipe da Telemática analisar se as informações das marcações estão de acordo com a estrutura definida na documentação api recordClockMarkings.

Encaminhar  para a equipe de suporte técnico.

Fail to compare ORACLE schema; file hcm.CAROL_3C_QUEUE counted num flds: 11 fildes: 13. (2720)

RECIDFLG set; fldinfo count: 13. (4507)

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

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

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.

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

• 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.

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.

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.

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.

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

• • • arquivo 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.

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.