TOTVS Agro Bioenergia

Árvore de páginas

Versões comparadas

Versão antiga 19

changes.mady.by.user Gabriel Giovani de Souza Machado

Gravado em

comparado com

Nova versão 20

changes.mady.by.user Gabriel Giovani de Souza Machado

Gravado em

Chave

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

...

  • Alteração do application.yml para utilizar a propriedade ta-api-hub.products, possibilitando configuração de múltiplos produtos e seus respectivos datasources: 

    • Como ficou:

      Bloco de código
      languageyml
      titlePropriedade ta-api-hub:
      ta-api-hub:
  default-instance:
  default-company:
  products:
    bioenergia:
      enabled:
      name:
      datasource:
        driver-class-name:
        url:
        username:
        password:
        test-connection:
    industria-mi:
      enabled:
      name:
      datasource:
        driver-class-name:
        url:
        username:
        password:
        test-connection:
    industria-pi:
      enabled:
      name:
      datasource:
        driver-class-name:
        url:
        username:
        password:
        test-connection:
    • As propriedades default-instance e default-company pertencem ao escopo de instância do produto ta-api-hub;
    • É obrigatório preencher pelo menos as propriedades do Bioenergia.
  • Criação das classes ExternalProductContext, ProductDataSourceConfig, ExternalProductFilter e da anotação ExternalProductAware para controle dinâmico do contexto de produto externo por requisição;
  • Modificação da DataSourceUtil para gerenciar múltiplos datasources, templates e named templates conforme o produto ativo;
  • Foi necessário revisar e atualizar todos os pontos do código que utilizavam @Value para injeção de propriedades, especialmente nas classes BO, devido à nova estrutura do application.yml. Isso garantiu que as configurações fossem corretamente lidas conforme o novo padrão de organização do arquivo de propriedades.
  • Adição da chave de cabeçalho X-Product para utilizar os endpoints dos controladores anotados com @ExternalProductAware (atualmente, MigrationsController e FunctionsController, ou seja, /admin/migrations e /functions). Nesses casos, o cabeçalho é obrigatório para identificar explicitamente o produto externo da requisição, garantindo o isolamento e a seleção correta da base de dados. Para os demais controladores, o produto é resolvido automaticamente pelo contexto interno da API, por meio do método getProduct presente em classes como EntityHe, QueryHe e MobileServices, não sendo necessário informar o cabeçalho.

...