CONTEÚDO
- Configurações gerais do REST
- Controle de threads
- MVC
- MVC com REST
- Modelos publicados
- APIs específicas
- Integração Offline
- Integração Online
- Links úteis
01. CONFIGURAÇÕES GERAIS DO REST
Para que o funcionamento da integração com o LegalDesk tenha uma boa performance, recomendamos:
- Ter um serviço do AppServer Protheus REST separado do AppServer da aplicação.
- Nas configurações do REST no ini do Server:
- Seção HTTPREST
- Remover o item MaxQueue (Limita a quantidade máxima de requisições que ficam na fila para serem processadas)
- SECURITY=1 (Habilita o fator de autenticação nas requisições REST)
- Seção General do AppServer REST
- MaxStringSize=10 (Define o tamanho máximo de uma requisição, neste exemplo uma requisição pode ter um tamanho de até 10 MB)
- Seção do ambiente (environment)
- FWTRACELOG=0 (Manter o log desativado)
02. CONTROLE DE THREADS
Para a integração com o LegalDesk é recomendável ter no mínimo 8 threads exclusivas. O volume de threads pode variar de acordo com o volume de usuários x requisições, por isso é necessário fazer a análise ambiente a ambiente.
Além disso, atentar para as seguintes configurações no controle de threads:
- Seção HTTP (HTTPURI)
- Instances: Define a quantidade de threads internas que podem ser disponibilizadas para estabelecer conexões simultâneas e atender as requisições via HTTP.
- As threads de REST têm um tempo de útil de vida, e fazem cache de uma série de informações (inclusive o modelo utilizado) para ganho de performance. Portanto, este dimensionamento deve ser avaliado para cada cliente. O ideal é avaliar a quantidade de threads e requisições simultâneas que o servidor recebe, sendo que quanto mais threads abertas o sistema possuir, maior a chance da requisição cair em uma thread que não possua o cache e também vai aumentar a memória em uso do servidor. Porém, uma quantidade menor de threads pode impactar se existirem muitas chamadas simultâneas. O tempo de vida da thread também pode ser alterado, visando aumentar o tempo de duração dos caches, mas em consequência, pode aumentar o uso de memória.
- Documentações auxiliares:
- Aumento do tempo de vida da thread - https://tdn.totvs.com/pages/viewpage.action?pageId=697263324
- Documentações auxiliares:
- Exemplo de preenchimento: Instances = 20,40,8,1
Sendo que:
- Primeira posição: Indica a quantidade de threads que serão iniciadas na inicialização do AppServer REST.
- Segunda posição: São as threads que ficarão ativas.
- Terceira posição: Threads que ficarão de stand by para novas requisições.
- Quarta posição: Quantidade de novas threads que serão disponibilizadas quando o número de threads livres estiver abaixo do valor previamente definido (Incremento).
Outro ponto importante para garantir a performance da integração via REST é o teste do MALLOCIO (MallocIO), que permite avaliar pontos como o tempo de busca da função de numeração automática, que é um forte indício de que a máquina onde o License Server está hospedado tem problemas de memória ou ainda, que existe um problema de comunicação de rede. Esta avaliação ajuda a garantir que o ambiente está OK para uma melhor performance.
03. MVC
04. MVC COM REST
O que é uma API?
- É um conjunto de regras, definições e padrões de como outros softwares podem se relacionar.
API embarcada no MVC: FWRESTModel
- Permite acessar via REST os modelos de dados das rotinas MVC.
- Principais vantagens:
- É necessária apenas a publicação do modelo para o uso via integração, com diversos recursos padrões de filtros e parâmetros de chamada.
- As validações e regras de cada modelo serão respeitadas em cada chamada sem a necessidade de desenvolvimento, tais como ativação, desativação, pré-validação e pós-validação do modelo, validações e gatilhos dos campos.
- Aceita os formatos XML e JSON nas requisições.
MVC com REST - Exemplo:
Funções executadas durante a alteração de um timesheet via REST
A alteração ocorreu em apenas 2 campos (UT Lançada e Cobrar = Sim)
- Ativação do modelo: Sugere os tempos revisados do lançamento
- Pré-validação do modelo: Verifica a existência de fatura adicional para o mesmo período do lançamento
- Pós-validação do modelo:
- Verifica os direitos do usuário em relação à data de corte do timesheet;
- Valida se o cliente/loja permite lançamento com data futura;
- Verifica se o cliente é E-billing para avaliar a obrigatoriedade dos campos de Fase, Tarefa e Atividade.
- Validações dos campos alterados: UT Lançada e do campo Cobrar
- Gatilhos para outros campos afetados: UT Revisada, UT Produtiva, Hora-minuto Lançado
- Validação geral do modelo:
- Antes da gravação no banco de dados: Verifica se houve alteração no caso para ajustar ou excluir a pré-fatura
- Após a gravação no banco de dados: Verifica se o TS precisa ser revalorizado
- Na desativação do modelo: Faz a desativação do modelo e limpa o conteúdo dos campos de ACAOLD
Quais validações são executadas durante uma requisição via FwRestModel:
- Ativação do modelo (SetActivate)
- Pré-validação do modelo
- Pós-validação do modelo
- Validações dos campos
- Gatilhos dos campos
- Validação geral do modelo.
- Antes da gravação no banco de dados (BeforeTTS).
- Após a gravação no banco de dados (InTTS).
- Na desativação do modelo.
05. MODELOS PUBLICADOS
06. APIs ESPECÍFICAS
JurRESTCP - Integração Contas a Pagar - PAGPFS
- Possibilita a manipulação (inclusão, alteração e exclusão) ou consulta de títulos a pagar. Normalmente é usado devido às movimentações no Controle Orçamentário do Legal Desk.
WSPfsApi - Anexos
- Permite o Upload / Download de arquivos em requisições XML ou JSON.
JurRESTFun (WO em Lote dos timesheets)
- Realiza a inclusão ou cancelamento de WO dos timesheets em lote, solicitados pelo Legal Desk.
- Possibilita a inclusão ou cancelamento de WO de TSs em lote em requisições XML ou JSON.