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!
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 (onError - TOTVSTEC - TDN) no REST 2.0?
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
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.
Você teria que tratar pontualmente, API a API.