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.

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.

Limpeza e Manutenção do S3

Ainda não implementado. Detalhes da ideia inicial descrita na sessão do S3.