Problema/Escopo

Precisamos resolver o problema de escalabilidade do GAIA para pesquisas de grande volume no FRONT e via API

Para resolver isso precisaremo:

Entrega 1 - Implementação ElasticSearch e Dynamo

Replicar o Banco/Dados no Dynamo

Processo inicial de atualização: Atualiza no Mongo, Replica no Dynamo (https://dtxlab.atlassian.net/browse/GAIAV3-98 ) e atualiza o ElasticSearch (https://dtxlab.atlassian.net/browse/GAIAV3-97 como um cache) durante a madrugada.

Processo de consulta macro: Bate a Consulta no Elasticsearch (listagem)

Implementar o ElasticSearch para aguentar pesquisas com volume grande

Atenção - a resposta que a API devolve ao front e como será tratado isso?

Levantar quais ainda estão na V3

Comunicações com SAP
Comunicação com STEP
De/Para’s
@Marcio Whitaker (Unlicensed) e @Lucas Giusti Pereira (Unlicensed) validar se ainda usamos a tabela “Materials” para embalagens?

Por exemplo: Consulta por COR, SKU, EAN

as consultas necessitam ser mapeadas para estruturar as novas no elasticSearch

Migrar para o Elasticsearch/DynamoDB as consultas simples - do jeito que esta implementado hoje - e sem implementar novas funcionalidades
Paralelizar com as migrações do que tem em V2 para a V3
O Elasticsearch deve possuir somente os campos/atributos chaves e não todos os campos/atributos
O Elasticsearch será atualizado 1 vez por dia somente
O DynamoDB performa melhor com consultas específicas, por exemplo já com o SKU, que viria do Elasticsearch
Podemos parar de dar manutenção na V2 Hydra (não é usado)
Não é necessário o “desligamento” da Materiais.

@Alessandro Holanda (Deactivated) irá validar os custos, mas a princípio usaríamos o serviço da própria AWS?
@Marcio Whitaker (Unlicensed) validar se quando recebemos os dados de embalagens é gravado e usado na com dados da V2? Talvez criar uma nova Collection
- Em embalagens olhamos para a Materials para verificar qual produto tem qual embalagem
- Qual Funcionalidade precisa da Materials
@Lucas Giusti Pereira (Unlicensed) verificar o que precisa ser migrado do Node-RED e quais os Workers? Criar 1 card para cada item a ser migrado dentro do Épico https://dtxlab.atlassian.net/browse/GAIAV3-86
@Rennan Figueiredo Raszl (Unlicensed) quais as lógicas e “de/para” serão necessário com a substituição de iDoc/BUS/DataStage?
- “GD GAIA <> GD SAP”?
@Rennan Figueiredo Raszl (Unlicensed) revisitar as atributos Hydra para a próxima fase do projeto
- precisaremos deixar a estrutura pronta, independente dos dados.
- Levantar quais dados, criar Característica somente para Hydra, validar com área de negócios,
- Será necessário criar um DePara entre Golden Record e repositório dos dados - no caso da Hydra é o SAP?
- De onde virão as imagens da Hydra na V3?
@Lucas Giusti Pereira (Unlicensed) e @Rennan Figueiredo Raszl (Unlicensed) testar se conseguimos fazer consulta de ZEMB com e somente a Digibee?

Retrabalho caso migre da V2 para a V3 agora e refazer em 2021 para entregar junto com S4 Deca
Necessário alteração referente a mudança nos Links nos Assets (FRONT ainda usa API apontando para V2, asset da Materials)

Se tudo migrado para Zeebe e Digibee será mais fácil migrar para SAP Hana devido aos fluxos

Nada que TENHA IMPACTO NO ROADMAP DO GAIA ativo na V2.

O texto em vermelho foi adicionado em comum senso entre os membros do time, pois são funcionalidades que já estão em pleno funcionamento e nos dará mais flexibilidade para focar em itens que agregam valor na escalabilidade e busca.
O foco principal e acabar com a dependência da Materials. Por exemplo API de Assets e Embalagens

DynamoDB e ElasticSearch implementados para: