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.

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 em atualizações
• 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. Gerando mais custo de velocidade.
• Por a operação não estar inclusa na transaction um rollback da operação não exclui o arquivo já postado ou marcado como excluído. Gerando deixando versões e arquivos lixo dentro do Bucket.

Lógica de Funcionamento

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.

Claro que essa operação deixará muitos arquivos "órfãos" dentro do bucket. Para realizar a limpeza o sistema tem tarefas de manutenção que excluem as versões dos arquivos que são mais antigas que o backup mais antigo e que não sejam a versão atual do arquivo. Por exemplo, se realizamos o backup do banco de dados de no máximo 6 meses, podemos excluir tranquilamente as versões anteriores dos arquivos que são mais antigas que 6 meses. Assim podemos de tempos em tempos eliminar o lixo do S3 sem prejuízo do backup.

Aliado à essa limpeza, devemos trabalhar as regras de passar o conteúdo do bucket para o glacier. Garantindo assim um custo mais barato para armazenar esses arquivos.

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

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 contraint o ON DELETE RESTRICT.