Linha Microsiga Protheus

Árvore de páginas


CONTEÚDO

  1. Configurações gerais do REST
  2. Controle de threads
  3. MVC
  4. MVC com REST
  5. Modelos publicados
  6. APIs específicas
  7. Integração Offline
  8. Integração Online
  9. 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.
    • 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.

07. INTEGRAÇÃO OFFLINE


08. INTEGRAÇÃO ONLINE



09. LINKS ÚTEIS