FileVO

O FileVO é o objeto oferecido pelo Kernel do BIS10 para simplificar a persistência de arquivos no BIS10.

Associando o FileVO

O FileVO deve ser usado sempre com o relacionamento do tipo ASSOCIATION. Para evitar que o FileVO seja persistido diretamente como uma composição do objeto que tem o arquivo. Para persistir o FileVO utilize o método persistFile(...) disponível no KernelCrud. Este método não é publicado na fachada, deve sempre fazer parte da lógica de outros métodos de negócio.

Exemplo de Utilização do FileVO @BISMetaRelationshipField(caption = "Arquivo do Objeto", relationship = RelationshipTypes.ASSOCIATION, required = true, column = "idk_file") private FileVO fileVO = null;

Efeitos Colaterais Uma vez que o FileVO deve ser do tipo Association, ao persistir o objeto que tem o FileVO, e o FileVO seja um objeto novo (sem ID), o BISValidation falhará reclamando que o objeto não pode ter uma associação de objeto sem ID, bem como o BISDAO falhará pelo mesmo problema. A solução é que antes de validar e persistir o objeto principal, todos os FileVOs devem ser persistidos (atualizados/inseridos) antes de se iniciar o processo de validação do objeto principal. Mesmo em casos de falhas posterior, o FileVO sofrerá RollBack e as alterações serão desfeitas.

FK com ON DELETE RESTRICT Ao montar o relacionamento do banco de dados, sempre utilizar o ON DELETE RESTRICT. Isso evita que o sistema de manutenção exclua o arquivo que está em uso. O sistema de manutenção procura arquivos que estão na base de dados e não estão mais em uso (arquivos eqsuecidos) e os exclui. Manter a FK restringindo a exclusão é a maneira que o sistema tem de perceber que o arquivo está em uso.

Modos de Persistência

Atualmente o BIS suporta dois métodos de persistência do arquivo:

Banco de Dados (DB)

O modo de persistência DB persiste o arquivo como um Blob dentro do próprio banco de dados. Fazendo com que o conteúdo do arquivo sofra rollback ou commit junto com o resto da transação.

Vantagens deste Método

• Não deixa arquivos "lixo" para trás durante as atualizações dos objetos.
• Tem um acesso rápido sendo recuperado na mesma transação que o FileVO (se solicitado, uma vez que fica em um objeto composto FileContentVO).

Desvantagens deste Método

• Sobrecarrega os arquivos da base de dados, podendo deixar o banco lento e atingindo a capacidade de tamanho da tabela cedo.
• Deixa os arquivos do banco maiores, e cada snapshot inclui o conteúdo completo do arquivo, mesmo que ele seja igual ao seu anterior.

Amazon S3 (S3)

Este método faz o post do arquivo em um bucket próprio da aplicação na Amazon. O FileVO continua sendo salvo no banco de dados mas apenas com as informações de meta-dados do arquivo, seu conteúdo é enviado para o S3.

Vantagens deste Método

• Mantém a base de dados apenas com as informações de meta-dados, não sobrecarregando os arquivos do banco.
• Os arquivos na S3 são salvos todos separados, novos arquivos não forçam um backup contendo novamente o conteúdo de outros arquivos que não foram alterados
• Passando versões antigas para o Glacier, o custo do aramazenamento e de backups se torna muito menor do que o gasto com espaço no banco de dados.

Desvantagens deste método

• O arquivo quando salvo/recuperado precisa abrir uma nova conexão HTTPS com o servidor da S3 para realizar a operação. Tirando a performance da ação.
• Uma vez que a operação não está inclusa na transaction, um rollback da operação não exclui o arquivo já postado ou marcado como excluído. Gerando versões e deixando lixo dentro do Bucket.

Lógica de Funcionamento

Versionamento do Arquivo no S3 Quando o método de persistência é DB o conteúdo será persistido no banco diretamente, uma vez que um conteúdo substituí o outro e "a vida segue". No entanto, não queremos que a cada atualização do objeto um novo arquivo seja postado. Tanto pelo overhead de conexão, quando pelo excesso de versões "lixo" sendo criado dentro do Bucket gerando orçamentos maiores. Assim, para saber que o arquivo precisa ser versionado o usuário deve excluir o valor do atributo VersionID. Somente quando o FileVO não apresenta um VersionID é que o Crud fará o post para obter um VersionID do S3. Caso o arquivo já exista no S3 ele ganhará uma nova versão, do contrário será sua primeira versão.

Configuração do Bucket do S3 O bucket do S3 deve ter as seguintes características definidas: Ter a regra de versionamento ativa.

Por não estar na transação do Container, o sistema de persistência do S3 nunca excluí de fato um arquivo. O Bucket utilizado deve ter o sistema de versionamento funcionando inclusive para arquivos excluídos.

O BIS saberá qual é o arquivo correto de acordo com o VersionID fornecido pelo S3. Assim, mesmo que o Banco de dados sofra uma restauração anterior, o banco trará o versionID adequado à época do banco de dados que foi restaurado, permitindo que o S3 continue devolvendo o arquivo correto quando necessário. Dito isso, o bucket não deve ter nenhuma regra de exclusão automática. Em um cenário em que um arquivo foi atualizado, no bucket teremos uma versão antiga e uma nova. Caso o banco de dados seja restaurado, fazendo com que a versão antiga volte a ser a vigente, o bucket não é notificado e uma regra de exclusão de versões antigas pode acabar excluindo o que é na verdade a versão vigente no banco de dados.

Como escolher o método de persistência adequado?

Dada as vantagens e desvantagens de cada modelo de persistência, eles devem ser escolhidos conforme os seguintes critérios:

• Utilizar o S3 quando:
  • Sempre que tivermos um grande volume de arquivos para serem salvos
  • Os arquivos tendem a ser mais "estocados" do que "utilizados"
  • O overhead da conexão adicional é aceitável para a operação.

  Exemplos: Arquivos XML de Notas Fiscais, Arquivos do SAT, Digitalizações de comprovantes e outros documentos.

• Utilizar o DB quando:
  • Há uma quantidade pequena de arquivos que serão utilizadas
  • Os arquivos são utilizados com frequência pelo tempo que existirem na base de dados.

    Quando os arquivos são utilizados com frequência por um pequeno período de tempo, e depois ficam estocados, deve-se utilizar o S3. Sempre pensando a relação uso/estoque em relação ao tempo que o arquivo ficará na base de dados.

  • O overhead da conexão adicional não é aceitável

    Neste caso devemos ainda pensar se a quantidade de arquivos no Banco não será grande de mais. Se for o caso trabalhar uma ideia de um cache de arquivos temporários.

  • Utilizar quando precisamos persistir arquivos que são temporários (como relatórios que demoram a ficar pronto e devem ficar disponíveis por um período) e não podemos perde-los em arquivos temporários do sistema. Quando puder, utilizar o sistema de arquivos temporários de qualquer forma.

Limpeza e Manutenção - FileMaintenanceTask

O BIS tem uma rotina de manutenção que temporariamente tenta excluir os FileVOs que não estão em uso. A maneira de saber se o FileVO está em uso é tentando excluí-lo e descobrir se o banco impede por restrição de alguma FK com ON DELETE RESTRICT, por isso torna-se obrigatório que qualquer objeto que utilize o FileVO coloque na sua constraint o ON DELETE RESTRICT. Essa manutenção é obrigatória porque, uma vez que o FileVO não é um objeto de composição de outros objetos, durante a alteração ou exclusão do FileVO dos outros objetos, o velho fica abandonado no banco de dados.

Limpeza e Manutenção do S3

Após a limpeza dos FileVOs da base de dados, o sistema deve recuperar uma lista de todos os arquivos, incluindo suas versões, no S3. Com base nessa lista conseguimos comprar com os FileVOs da base de dados e descobrir quais arquivos/versões estão órfãos no S3.

Assim, temos as seguintes regras de exclusão de arquivos do S3:

Regra 1:

• Arquivos no S3 que não tenham correspondência com nenhum FileVO da base de dados, e;
• Não forem a versão atual do arquivo, e;
• O arquivo deixou de ser a versão atual à mais de X meses, onde X Meses é o mesmo tempo de retenção dos backups.

Regra 2: É necessário um jeito de excluir os arquivos que são a versão atual de um objeto no S3. Porém não basta excluir o objeto que não tem correspondência no FileVO atualmente pois ele pode ter correspondência com um objeto do Backup. Se for possível realizar algum tipo de marca/tag/attributo no arquivo. A tarefa de manutenção pode marcar o arquivo com a data em que pela primeira vez percebeu que o arquivo estava órfão, e excluir em uma próxima execução da tarefa ao perceber que a data ficou velha em pelo menos X meses.