Histórico da Página

01. DADOS GERAIS

02. SITUAÇÃO/REQUISITO

Cliente utiliza, via integração junto à Lexos, nas vendas da Shopee, a importação de pedidos via 'winthor-pedido-venda' com a utilização do parâmetro "4672-Aceita validar CEP online nas APIs do WinThor" marcado como Sim, na rotina 132, a validação do CEP para o endereço de entrega informado na venda (e vindo da Shopee através da Lexos) através do WebService do ViaCEP. 

Deve-se inverter a prioridade da busca para quando o parâmetro estiver marcado como "Sim".
A intenção é fazer com que mesmo com o parâmetro marcado como "Sim", só se consulte o WebService caso o endereço não seja encontrado internamente, com o dado digitado do usuário, ou seja:
– Parâmetro 4672 = S:
1) Consultar o endereço informado pelo cliente.
2) Caso retorne a exceção "CLIENTE_CIDADECOMERCIAL_NAO_EXISTE" ou de outro dado de endereço não localizado, realizar consulta ViaCEP.
3) Se der exceção do ViaCEP, realizar protocolo normal de exceção e rejeição do pedido.
— Parâmetro 4672 = N:
1) Seguir trâmite normal.

03. SOLUÇÃO

• Ajuste na API de clientes para verificar se os dados do logradouro já existem antes de consultar a API ViaCep, evitando chamadas desnecessárias.

Link documentação: https://developer.ifood.com.br/pt-BR/docs/references/#authentication

O Ifood possui duas formas de autenticar (Centralizado e Distribuído)

O tipo Centralizado é uma maneira mais simples, onde nós como TOTVS temos um acesso único que vale para todos os nossos clientes, e é recomendado para quando temos controle sobre o ambiente do cliente (Clientes Cloud)

O tipo Distribuído é recomendado em casos onde não temos acesso ao banco do cliente, no caso de clientes On Premise. Basicamente é uma autenticação com dois fatores. 

No nosso caso, como temos clientes On Premise e Cloud, foi recomendado pelo time do Ifood que usemos o token distribuído.

Na primeira chamada passando os dados do cliente, é obtido pela API um link URL para que o cliente acesse, e após o envio de um código por email, o cliente entra no portal do Ifood. Dentro do Portal, aparece uma mensagem indicando que nós estamos querendo acessar o seu ambiente, e após a autorização do cliente, é gerado um código que deve ser configurado também no WSH. Com esse código em mãos, voltamos na API de autenticação, passando esse código e os demais parâmetros, e obtemos o token.

A primeira chamada é feita no endpoint /oauth/userCode, conforme abaixo:

Image Added

Retornar os dados da consulta como userCode, que é necessário para a verificação do usuário e obter o código de autorização, que deverirá, juntamente com os dados de conexão utilizados na primeira requisição

O parâmetro grantType deve ser passado como "authorization_code)

Os parâmetros clientId e clientSecret são fornecidos pelo cliente, e deve ser possível configurá-los no WSH, opção de parâmetros

A API retorna uma URL e um código de verificação, destacado acima.

Devemos abrir no navegador do cliente essa URL para que ele siga com o login, e armazenar o código de verificação destacado acima.

Depois que o cliente acessar o portal do Ifood, será apresentada uma mensagem de autorização, e após confirmação, será gerado um código para ele, conforme abaixo:

Deve ser possível também configurar esse código no WSH.

Com o código em mãos, fazemos a requisição no endpoint /oauth/token, da seguinte forma:

Image Added

Image Added

Será retornado o accessToken e o refreshToken

Que também será obtidos em tempo de execução do WSH após configurado na rotina 2670

No log serã apresentados os log de tentativa e conexão bem sucedida de refreshToken

Image Added

Após a configuração do token, o WSH está pronto para ser utilizado nas requisições

03. SOLUÇÃO

• Criado o Fluxo de autenticação via WSH

04. DEMAIS INFORMAÇÕES

05. ASSUNTOS RELACIONADOS

• Como atualizar as rotinas do WinThor?

...