01. DADOS GERAIS
| Produto: | |
|---|
| Linha de Produto: | |
|---|
| Segmento: | |
|---|
| Módulo: | |
|---|
| Função: | Todas |
|---|
| País: | Brasil |
|---|
| Ticket: |
|
|---|
| Requisito/Story/Issue (informe o requisito relacionado) : | DAGROFRAME-4860 |
|---|
02. SITUAÇÃO/REQUISITO
Adequar o sistema para suportar múltiplas bases de dados externas, permitindo que os serviços da API trabalhem com diferentes produtos (ex: Bioenergia, Indústria-MI, Indústria-PI) de forma dinâmica, conforme o contexto da requisição.
03. SOLUÇÃO
- 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:
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 produto 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.
04. DEMAIS INFORMAÇÕES
Não se aplica.
05. ASSUNTOS RELACIONADOS
Arquitetura e Tecnologia - TOTVS Agro API Hub