Bom dia! Estou usando o Rest em tl++ e percebi que, diferente do rest advpl, o ambiente não é aberto conforme o preparein (alias nem tem essa chave no rest tl++). Mesmo quando eu mando tenantId, o ambiente não abre automaticamente. Eu consigo pegar o tenantId e abrir o ambiente manualmente (rpcsetenv), porém eu queria que o ambiente já viesse aberto pra facilitar os futuros desenvolvimentos e inclusive deixando mais rápido, pois se a cada requisição eu abrir o ambiente creio que terei um certo delay. Pensando nisso, estou utilizando o pe OnStart (https://tdn.totvs.com/display/tec/onStart) para isso. O problema que eu tenho é que ele executa em TUDO, até mesmo execuções internas do appserver que exigem abertura de thread, o OnStart está executando. Desta forma, eu queria saber se há uma forma de eu separar execuções internas do appserver das chamadas "reais" feitas pelos clients e assim eu possa abrir o ambiente. Desde já obrigado!
REST TL++ OnStart
- Você vai ver essas setas em qualquer página de pergunta. Com elas, você pode dizer se uma pergunta ou uma resposta foram relevantes ou não.
- Edite sua pergunta ou resposta caso queira alterar ou adicionar detalhes.
- Caso haja alguma dúvida sobre a pergunta, adicione um comentário. O espaço de respostas deve ser utilizado apenas para responder a pergunta.
- Se o autor da pergunta marcar uma resposta como solucionada, esta marca aparecerá.
- Clique aqui para mais detalhes sobre o funcionamento do TOTVS DevForum!
0 resposta
-
Ivan,
O recomendado é utilizar o REST 2.0, ele vai ler a chave preparein e abrir o ambiente.
O REST TLPP é o motor utilizado no REST 2.0, logo ao utilizar o REST 2.0 você também está utilizando o REST TLPP com todas as questões que envolvem o Protheus já prontas, como ambiente, autenticação, pontos de entrada, idioma etc. O REST 2.0 utiliza exatamente a mesma configuração do REST antigo, tudo foi feito para ficar o mais simples e transparente para os clientes.
Obs: O REST TLPP não executa APIs feitas em ADVPL, somente o REST 2.0 faz isso.
-
Oi Daniel, obrigado pelo retorno. O motivo de eu ter "migrado", foi devido ao OnError. Preciso desse userexit para que em caso de error.log na api, venha uma mensagem mais friendly e o bacana é que é um tratamento centralizado, não preciso ficar utilizando try/catch ou errorblock em cada fonte. Talvez tenha uma forma também no REST 2.0, mas eu não achei documentação. Sabe me dizer se consigo utilizar essa funcionalidade do OnError (https://tdn.totvs.com/display/tec/onError) no REST 2.0?
— Ivan Martins Caproni 12 de May de 2023 -
O onError do REST 2.0 não fica acessível. Mas como eu citei, você precisará criar toda a stack que hoje o REST 2.0 possui e também, inúmeras APIs não funcionaram. A questão de tratamento de erro, é padrão, o REST responde conforme uma exceção, normalmente quem fica responsável por gerar uma mensagem mais amigável, é a interface e não o backend. Você vai ter trabalho para construir isso, não funcionará corretamente e sua manutenção pode ser complexa, visto que você será o total responsável por isso, além disso o REST MPP continuará no mesmo padrão de erro, pois não é possível efetuar tratamento
— Daniel Mendes 12 de May de 2023 -
Entendi. Bom ponto! De qualquer forma, eu preciso disso por vários motivo de controle. Não dá pra eu citar todos os motivos, mas como exemplo, essa api está em um cliente que eu monitoro, então eu preciso enviar um email pra suporte em caso de error.log. Desta forma, o OnError me serveria para em caso de erro (codhttp 500 por exemplo), já envia email com o erro, entende ... e no REST 2.0 pelo que eu entendi, a única forma de fazer isso seria via try/catch ou errorblock mesmo, correto? Se sim, funciona, o único problema que cada desenvolvimento é necessário fazer esse tratamento.
— Ivan Martins Caproni 12 de May de 2023 -
Você teria que tratar pontualmente, API a API.
— Daniel Mendes 12 de May de 2023
-