Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

01. DADOS GERAIS

Produto:

TOTVS Agro API Hub


Linha de Produto:

Linha PIMS

Segmento:

Agroindústria

Módulo:

Framework

Função:Todas
País:Brasil
Ticket:
Requisito/Story/Issue (informe o requisito relacionado) :DAGROFRAME-4835

...

https://arquitetura.totvs.io/architectural-records/ADRs/Framework/ADR010001/#contexto

Melhorias na estruturaEspecíficos:

    • Revisitar nomenclaturas e rotas no API-Hub para não usar "/smartview/" e sim "/business-objects" (deixar agnóstico no API-Hub, sem vínculo) 
    • Implementar segurança (header Authorization) no API-Hub para "/business-objects/" para dois níveis de autenticação:
      • 1. via credenciais padrão do API-Hub (assim como já acontece nas demais APIs do Bioenergia) e, caso dê 401 (ou token expirado, enfim), seguir para o modelo
      • 2. via T-Provider & Keycloak (únido modelo que seria chamado pelo Smart View)
    • Trocar "isEnableSmartView" para "isBusinessObject" (no modelo de dados) - revisar colunas (banco de dados) para não usar palavra "smart_view", por exemplo, "enable_smart_view"
    • Incrementar APIs de Objetos de Negócio (ON) para que, além do modelo de Entidades (Entity), também se permita usar o conceito de ON para o modelo Consulta (Query);
    • Revisitar abordagem de "v1" e/ou "versão de API de release" para permitir uma recuperação mais dinâmica e inteligente das APIs e suas versões;
    • Concatenar, no nome do objeto de negócio, a versão, por exemplo "Fazenda (v1)", "Fazenda (v2)" ...
    • Quando for utilizar/implementar modelo Query, avaliar uso de nova tabela "query_filters" ou evoluir "query_fields" - objetivo: melhor controlar/catalogar os possíveis filters de APIs GET do tipo Query, para serem utilizadas como filters ou parameters (objetos de negócio)
    • Implementar POST na camada de abstração para chamar GET (da API Padrão, seja Entity ou Query, e depois EntryPoint), para properties =[], filters = [] e parametros = [] ou com filtros utilizados no GET da API Padrão (por exemplo, ?codigoTurma=123)

...

Foi desenvolvido a partir da documentação ADR010001 as três APIs que são necessárias para criarmos os Objetos de Negócios no produto TOTVS Agro API Hub.

  • Listagem de Objetos de Negócios

Foi desenvolvida a partir da recuperação de informações e listagem de Entidades e Queries no TOTVS Agro API Hub, com ela, conseguimos listar todos os Objetos de Negócios que forem habilitados por padrão. Com as tabelas de Entidades e Queries, foi necessário criar soluções especificas para recuperar e converter corretamente esses dados e responder as requisições seguindo a ADR010001.

      • Path: /business-objects/v1/searchobjects
      • Método: GET
      • Autenticação: Token JWT padrão do TOTVS API Hub ou Token JWT padrão do TOTVS Agro Provider
      • Tabelas: entity_api, entity_de, entity_he, query_he, query_de e query_fields
      • Resposta: name, displayName, description, areas, schemaUrl, dataUrl, properties e parameters
  • Schemas de Objetos de Negócios

Foi desenvolvida a partir da recuperação de informações e listagem de Entidades e Queries no TOTVS Agro API Hub, com ela, conseguimos listar todos os Objetos de Negócios que forem habilitados por padrão. Com as tabelas de Entidades e Queries, foi necessário criar soluções especificas para recuperar e converter corretamente esses dados e responder as requisições seguindo a ADR010001.

      • Path: /business-objects/v1/searchobjects
      • Método: GET
      • Autenticação: Token JWT padrão do TOTVS API Hub ou Token JWT padrão do TOTVS Agro Provider
      • Tabelas: entity_api, entity_de, entity_he, query_he, query_de e query_fields
      • EstruturaResposta: name, displayName, description, areas, schemaUrl, dataUrl, properties e parameters


Soluções especificas:

  • Trocar rotas de "/smartview/" por "/business-objects"
    • Solução: URLs padronizadas para /business-objects/v1 (base), com caminhos de schema e data usando esse prefixo.
  • Implementar segurança (header Authorization) em dois níveis: 1) credenciais API-Hub; 2) fallback T-Provider & Keycloak
    • Solução: Fluxo de autenticação em duas camadas implementado — primeiro tenta credenciais do API-Hub; em caso de 401/expiração faz fallback para T-Provider/Keycloak.
  • Trocar isEnableSmartView para isBusinessObject e revisar colunas do BD
    • Solução: Mudanças a nível de banco (migrations/colunas antigas contendo "smart_view").

...