Explicação do funcionamento da integração com a Feedz.
Foi criado o campo "Tipo P&M/Feedz" para definir o tipo de desligamento que será enviado a Feedz na integração de funcionários:
Foi criado o campo "Agrupador P&M/Feedz" para definir o agrupador de contrato que será enviado a Feedz na integração de grupos de contrato e de funcionários:
Se o cadastro de cargos estiver com modo de acesso Exclusivo, será necessário cadastrar um De x Para através da rotina GPEA944B:
Em Outras Ações, foi disponibilizado a opção "Vincular cargos", onde será possível marcar quais grupos serão vinculados ao cadastro:
Com o cadastro de De x Para, ao efetuar a integração com a Feedz serão enviados o código e descrição cadastrados nesse cadastro. |
Se o cadastro de departamentos estiver com modo de acesso Exclusivo, será necessário cadastrar um De x Para através da rotina GPEA944C:
Em Outras Ações, foi disponibilizado a opção "Vincular departamentos", onde será possível marcar quais grupos serão vinculados ao cadastro:
Com o cadastro de De x Para, ao efetuar a integração com a Feedz serão enviados o código e descrição cadastrados nesse cadastro. |
Foi efetuado a criação da rotina GPEM939 para efetuar a integração com a Feedz dos itens abaixo:
A rotina é do tipo Wizard e possui cinco passos:
|
|
Tela antiga:
Foi efetuado a criação da rotina GPEM939B para permitir a visualização das informações dos lotes de integração com a Feedz, bem como consultar manualmente o status de integração.
A rotina é do tipo MarkBrowse e irá exibir os registros da tabela REF:
Ao efetuar um duplo clique no registro ou ao clicar na coluna de cabeçalho, todos os registros serão selecionados. Ao clicar no botão "Consultar Status", será efetuado consulta do status na Feedz, e ao fim será retornado um log de ocorrências com os status dos lotes, bem como eventuais erros de validação retornados pela Feedz.
Ao posicionar em um registro e clicar no botão "Visualizar" será aberto as informações detalhadas do lote. Ao clicar no botão "Consultar Inconsistências", será gerado um log com os erros retornados pela Feedz em um formato mais amigável caso o status do lote seja igual a 3.
Tela nova em PO UI, com a porta Multiprotocolo habilitada:
Poderá ser realizado filtros de Status e Tipo da API, bem como a data de integração, ao aplicar o filtro, os registros contidos na REF serão listados
É possível visualizar o registro mais detalhadamente e salvar esses detalhes, ao salvar, será criado um arquivo em PDF.
Para registro com erro, existe a opção de inconsistência para mostrar os erros detalhados
A opção de consulta, irá consultar os registros com status 'Não iniciados' ou 'Executando', ao término da consulta, o status será atualizado na tela
Também foi disponibilizada a rotina GPEM939D para ser possível agendar no Schedule a realização da integração.
A rotina pode ser cadastrada no Schedule do módulo SIGACFG - Configurador para efetuar a integração automaticamente, conforme exemplo abaixo:
Ao realizar a integração dos cadastros através do schedule, será possível selecionar qual cadastro deseja integrar pela opção de "Parâmetros", conforme imagem acima, porém não será possível filtrar o registro de determinado cadastro para envio. Para realizar esse filtro sugerimos enviar o cadastro utilizando o Wizard de integração, rotina GPEM939 conforme descrito no item 6 dessa documentação. Para evitar impacto na performance, recomenda-se que o agendamento seja programado para, no máximo, duas vezes ao dia. |
Para saber mais como realizar o cadastro do schedule, como o agendamento e configuração da recorrência, acesse a documentação do Framework: Schedule - Como agendar a execução de rotinas |
Exemplo de retorno gerado no console do appserver:
Também foi disponibilizada a rotina GPEM939C para ser possível agendar no Schedule a consulta automática dos lotes de integração.
A rotina pode ser cadastrada no Schedule do módulo SIGACFG - Configurador para efetuar a consulta automática de todos os lotes que ainda não tiveram o status retornado pela Feedz, conforme exemplo abaixo:
Exemplo de retorno gerado no console do appserver:
Alguns erros podem acontecer durante o processamento do lote enviado ou durante a validação dos itens do lote enviado, sendo eles:
Código | Mensagem | Detalhes |
4998 | Id do processo não encontrado | Significa que o processId informado na requisição de consulta de lotes está incorreto. |
4999 | Ocorreu um erro inesperado! | Representa erros genéricos ou inesperados que podem acontecer no servidor ou que podem ser gerados por algum aspecto incorreto não previsto do lote enviado. |
5000 | Token inválido ou expirado! / Bearer token não informado. | Isso indica que o token não foi informado na requisição ou informado não é válido. É necessário conferir se o token informado é igual à chave API na plataforma Feedz. Em caso afirmativo, é necessário gerar outra chave. |
5000 | Body vazio | Significa que foi enviada uma requisição para gravar um lote, mas sem nenhum dado. |
5001 | O total de itens enviados no corpo da requisição excede o limite de 100 registros. Todos os registros foram ignorados no processamento. | Ocorre ao enviar um lote com mais de 100 registros. |
5003 | A pessoa NPE (IntegrationId = IDN) está referenciando um gestor que não existe. Essa pessoa não será importada. | Esse erro ocorre ao tentar cadastrar um colaborador, vinculando a um gestor que ainda não foi cadastrado. |
5004 | A pessoa NPE (IntegrationId = IDN) está referenciando ela mesmo como chefe. Essa pessoa não será importada. | Esse erro ocorre ao tentar cadastrar um colaborador, vinculando ela mesma como gestora (integrationId = managerIntegrationId). |
5005 | A pessoa NPE (IntegrationId = IDN) está referenciando um departamento que não existe. Essa pessoa não será importada. | Esse erro ocorre ao tentar cadastrar um colaborador, vinculando a um departamento que ainda não foi cadastrado. |
5006 | A pessoa NPE (IntegrationId = IDN) está referenciando uma unidade que não existe. Essa pessoa não será importada. | Esse erro ocorre ao tentar cadastrar um colaborador, vinculando a uma unidade que ainda não foi cadastrada. |
5008 | A pessoa NPE (IntegrationId = IDN) está referenciando um cargo que não existe. Essa pessoa não será importada. | Esse erro ocorre ao tentar cadastrar um colaborador, vinculando a um cargo que ainda não foi cadastrado. |
5009 | O ID de integração (IntegrationId) é obrigatório e não foi informado para a Pessoa NPE. Essa pessoa não será importada. | Ocorre ao enviar uma pessoa e não informar se id de integração. |
5011 | O nome (Name) é obrigatório e não foi informado para a Pessoa (IntegrationId = IDN). Essa pessoa não será importada. | Ocorre ao enviar uma pessoa e não informar seu nome. |
512 | O e-mail (Email) é obrigatório e não foi informado para a Pessoa 'NPE' (IntegrationId = IDN). Essa pessoa não será importada. | Ocorre ao enviar uma pessoa e não informar seu e-mail. |
5013 | A pessoa 'NPE' (IntegrationId = IDN) possui o mesmo e-mail de outra pessoa da lista de pessoas enviadas ou da base. Essa pessoa não será importada. | Essa validação existe para evitar cadastrar pessoas duplicadas na base. Assim não é possível cadastrar dois e-mails iguais para integrationIds diferentes e vice versa. |
5014 | A pessoa 'NPE' (IntegrationId = IDN) deve ter o nome digitado somente com caracteres com nome, sobrenome e apenas 1(um) espaço entre eles. | Esse erro ocorre ao informar um nome inválido. |
5015 | A pessoa 'NPE' (IntegrationId = IDN) não pode ter o apelido igual ao nome. | Ocorre quando o name é igual ao socialName. |
5016 | O email fornecido 'EML' para a pessoa 'NPE' (IntegrationId = IDN) não está em um formato válido. | Ocorre ao enviar uma pessoa com o e-mail em formato inválido. |
5017 | O registro com o nome 'NRA' não foi salvo durante o processamento porque o campo 'IntegrationId' não foi informado." | Ocorre ao enviar qualquer registro auxiliar e não informar o integrationId. |
5018 | O registro com o código 'IDN' não foi salvo durante o processamento porque o campo 'Name' não foi informado. | Ocorre ao enviar qualquer registro auxiliar e não informar o nome. |
5030 | Quando informado a data de demissão deve ser também informado o motivo (dismissalType). | Ocorre ao enviar data de demissão e não informar o motivo. |
5031 | Deve ser informado o motivo da demissão (dismissalType) apenas quando for informado a data de demissão. | Ocorre ao enviar motivo da demissão e não informar a data de demissão. |
5032 | A data de admissão não pode ser maior que a data de demissão. | Ocorre ao enviar uma data de admissão posterior à data de demissão. |
5048 | O ID de integração do líder (managerIntegrationId = MII) informado para a pessoa (personIntegrationId = IDN) não existe. | Ocorre ao tentar vincular pessoa e líder pela rota persons-bind e não ter esse líder cadastrado previamente na plataforma. |
5049 | O ID de integração da pessoa (personIntegrationId = IDN) informada não existe. | Ocorre ao tentar vincular pessoa e líder pela rota persons-bind e não ter esse colaborador cadastrado previamente na plataforma. |
5050 | Uma pessoa (personIntegrationId = IDN) não pode ser líder de sí próprio | Ocorre ao tentar vincular uma pessoa a ela mesma como líder (personIntegrationId = managerIntegrationId) através da rota persons-bind. |
A tabela abaixo apresenta os dois parâmetros utilizados para a integração com a Feedz, nos quais são informados a URL base do ambiente e o token de autenticação.
Por padrão, esses parâmetros são compartilhados entre filiais.
| X6_VAR | X6_TIPO | X6_DESCRIC | Exemplo de preenchimento |
|---|---|---|---|
| MV_APIFEE1 | C | URL base do ambiente de integração com a Feedz | Ambiente Produção: https://integrations.feedz.com.br/protheus-feedz-etl/ Ambiente Homologação: https://integrations.feedz.dev/protheus-feedz-etl/ |
| MV_APIFEE2 | C | Token de autenticação para integração com a Feedz |
Importante: Caso possua restrição em seu firewall, verifique se os endereços acima possuem liberação para conexão externa
Caso existam múltiplas bases da Feedz para diferentes filiais no Protheus, será necessário criar esses dois parâmetros de forma exclusiva para a filial adicional.
Exemplo:
No grupo 01, existem as filiais 01 e 02, sendo que a filial 02 utiliza uma segunda base na Feedz.
Nesse cenário, é preciso criar os dois parâmetros da tabela acima especificamente para a filial 02, garantindo a correta integração com a base correspondente.
No configurador, SIGACFG > Ambiente > Cadastros > Parâmetros
Veja que possuo os dois parâmetros compartilhados, nesses dois não vou mexer, pois eles continuarão sendo usados para as demais filiais:
Clico em incluir, e incluo os parâmetros exclusivos para a filial 02.
Com os dois parâmetros criados, será necessário informar a URL e token para os novos parâmetros exclusivos para a filial.
Veja que no campo filial, informo a filial 02, portanto, esse parâmetro é usado quando você estiver logado na filial 02.
Como as filiais estão dentro do mesmo grupo no Protheus, para que a integração funcione corretamente e os dados de uma filial sejam enviados para a segunda base configurada na Feedz, é necessário estar logado na filial correspondente. No nosso exemplo, para integrar os dados na outra base da Feedz, é preciso estar logado na filial 02. Ao acessar a rotina de integração (GPEM939), o ideal é filtrar apenas os dados da filial 02. Caso contrário, se houver filtros que incluam registros da filial 01, esses dados também serão integrados, utilizando a URL e o token configurados para a filial 02. Da mesma forma, ao realizar a integração logado na filial 01, não devem ser filtrados dados da filial 02, pois esses registros são utilizados em outra base da Feedz. |
Schedule - Como agendar a execução de rotinas
Vídeos How To:
How To | MP - SIGAGPE integração com a Feedz Parte 1
How To | MP - SIGAGPE integração com a Feedz Parte 2
How To | MP - SIGAGPE integração com a Feedz Parte 3
How To | MP - SIGAGPE integração com a Feedz Parte 4
How To | MP - SIGAGPE integração com a Feedz Parte 5
