01. DADOS GERAIS
| Produto: |
TOTVS Varejo Franquias e Redes |
|---|
| Linha de Produto: | |
|---|
| Segmento: | |
|---|
| Módulo: | PDVSync.Core.Controle - Hangfire |
|---|
| Função: |
|
|---|
| País: | Brasil |
|---|
| Ticket: |
|
|---|
| Requisito/Story/Issue (informe o requisito relacionado) : | |
|---|
02. SITUAÇÃO/REQUISITO
Permitir no frontend do CommerceHub a consulta rápida do conteúdo original expurgado da tabela Fila (payload “tal como a retaguarda enviou”), armazenado no bucket (histórico), sem exigir que o usuário baixe/abra arquivos gigantes para localizar Hash ou LoteOrigem.
03. SOLUÇÃO
- Alteração do Job responsável pelo Backup/Expurgo dos dados de Fila para que o mesmo consiga gerar um arquivo de index que irá armazenar a relação entre hashConteudo e o caminho do arquivo que contem os dados;
- Isso foi feito para melhorar a performance na busca dos dados, uma vez que arquivo do index é bem menor que o arquivo original, o que facilita a leitura e identificação do local onde o dado desejado se encontra.
- Criação de métodos no CloudStorageService para ler o arquivo de index, baixar o arquivo que contem o dado orignal e deserializar esse dado como os objetos do tipo Fila;
- Criação do controller que retornaria os dados para o frontend;
- Criação de uma tela "Histórico de Fila"no Frontend para buscar e exibir os dados.

A tela acima retorna uma lista de itens do tipo Fila, de acordo com os filtros utilizados. Sobre os filtros:
- Todos são obrigatórios;
- O Filtro de data não permite selecionar datas futuras, ou seja, maior que a data atual;
- O botão de "Buscar" ficará disponível para clique apenas quando todos os filtros estiverem preenchidos.
O tempo de buscar pode variar em decorrência do tamanho do arquivo. Um arquivo por volta de 50MB leva por volta de 2s, um de 240MB por valta de 10s e de 1GB por volta 45s. Como 1GB é o tamanho máximo de arquivo suportado, é provavel que todas as buscas fiquem abaixo de 1min.
Sobre a data de cadastro, vale ressalvar que os dados são salvos de acordo com a data de cadastro que o dado possuia no banco de dados. A busca por esse campo deve consider que o Job obtem os dados do dia anterior a sua execução, logo, deve-se considerar isso na busca.
Obs.:
- Os dados são apresentados em um textarea para facilitar a visualização, mas nenhuma alteração no conteúdo exibido será executada no arquivo original. Se o conteúdo for apagado do textarea, o campo será "escondido", sendo necessário uma nova busa para a exibição do dado;
- Dado o fato de que o GCP realiza suas cobranças por operação, não é recomando a execução de diversas operações de busca, uma vez que isso pode elevar o custo da ferramenta. Recomenda-se buscar o dado, copiar seu conteudo e apenas se necessário, fazer uma nova busca com parâmetros diferentes.