Quando o upload de objetos digitais no AtoM encontra limites: navegador, CLI, CSV e processamento em segundo plano
Quando o upload de objetos digitais no AtoM encontra limites: navegador, CLI, CSV e processamento em segundo plano
Ao trabalhar com o AtoM, é relativamente comum imaginar que o envio de objetos digitais pela interface web seja apenas uma questão de selecionar vários arquivos e aguardar o término da operação. Em muitos cenários isso funciona perfeitamente. Entretanto, à medida que aumentam a quantidade, o tamanho ou a complexidade dos arquivos, podem surgir situações em que o upload pela interface do navegador não consegue concluir a operação.
Esse tipo de situação merece ser compreendido não apenas como um eventual problema de configuração do servidor, mas também como uma consequência da própria arquitetura do processo de upload.
A documentação do AtoM 2.10 apresenta diferentes caminhos para trabalhar com grandes volumes de dados, incluindo importações CSV, processamento assíncrono por meio do sistema de jobs e tarefas específicas executadas diretamente pela linha de comando.
A questão central, portanto, é:
quando o navegador deixa de ser o melhor caminho para transportar e processar objetos digitais, como podemos utilizar os recursos administrativos e de linha de comando do AtoM para realizar a operação de maneira mais controlada?
1. Um cenário hipotético
Imagine uma instituição arquivística que possui uma descrição arquivística no AtoM e precisa associar a ela um conjunto de imagens digitais.
Os arquivos podem ser relativamente pequenos. Por exemplo, imagine algumas dezenas de imagens JPEG, cada uma com algumas centenas de kilobytes.
À primeira vista, parece uma operação trivial.
O usuário acessa a descrição, seleciona os arquivos, inicia o upload e espera que o AtoM processe os objetos.
Agora imagine que:
os arquivos estejam armazenados em uma rede com alguma latência;
a conexão do usuário não seja muito rápida;
o servidor esteja processando simultaneamente outras tarefas;
sejam necessários derivados digitais, como miniaturas e cópias de referência;
o conjunto de arquivos seja suficientemente grande para que a operação demore;
ou simplesmente o navegador encerre a requisição antes que todo o processamento seja concluído.
Nesse cenário, pode aparecer uma mensagem de falha no navegador, mesmo que não exista necessariamente um erro correspondente no error.log do Nginx ou no log do PHP-FPM.
Isso é importante.
Nem todo problema percebido pelo usuário na interface web significa que o problema tenha sido produzido pelo Nginx, pelo PHP ou pelo próprio AtoM.
Existe uma cadeia de comunicação entre navegador, servidor web, PHP-FPM, aplicação AtoM, sistema de arquivos e, em determinadas operações, mecanismos de processamento assíncrono.
Se uma requisição for encerrada no lado do cliente antes de chegar ao final, podemos ter uma situação em que a interface informa que a operação falhou, enquanto os logs do servidor não apresentam um erro correspondente.
2. Upload pela interface não é a mesma coisa que processamento assíncrono
Aqui está uma distinção fundamental para compreender o comportamento do AtoM.
A documentação do AtoM 2.10 explica que os processos de importação e exportação por CSV realizados pela interface do usuário são executados como jobs, utilizando o sistema de processamento assíncrono, justamente para evitar que operações demoradas fiquem presas à duração de uma requisição do navegador.
Isso não significa, entretanto, que toda operação realizada pela interface web do AtoM seja automaticamente transformada em um job assíncrono.
Essa diferença é particularmente importante quando falamos de objetos digitais.
Podemos simplificar a situação assim:
UPLOAD DIRETO PELA INTERFACE
Navegador
↓
Requisição HTTP
↓
AtoM
↓
Processamento
↓
Resposta ao navegador
Enquanto uma operação baseada em job pode seguir outro fluxo:
IMPORTAÇÃO ASSÍNCRONA
Navegador
↓
AtoM
↓
Criação do Job
↓
Fila
↓
atom-worker / Gearman
↓
Processamento
↓
Resultado
No segundo modelo, o navegador não precisa permanecer responsável por toda a duração do processamento.
É justamente essa diferença arquitetural que explica por que determinadas operações de importação CSV podem suportar volumes maiores sem depender da permanência de uma requisição HTTP aberta.
3. O navegador possui seus próprios limites
Quando pensamos em um upload pela web, normalmente concentramos nossa atenção no servidor:
“Será que o PHP está configurado corretamente?”
“Será que o Nginx está permitindo o tamanho do arquivo?”
“Será que o PHP-FPM está encerrando o processo?”
Essas perguntas são importantes, mas não são as únicas.
A documentação do AtoM 2.10 chama atenção para diversos limites de execução do PHP, incluindo max_execution_time, memory_limit e upload_max_filesize. Esses parâmetros podem interromper processos ou limitar o tamanho dos arquivos tratados pelo PHP.
Porém, uma operação também pode ser interrompida antes que um erro de aplicação ou de servidor seja registrado.
Isso ocorre porque uma requisição web possui vários componentes envolvidos:
[Usuário]
│
▼
[Navegador]
│
▼
[HTTP/HTTPS]
│
▼
[Nginx]
│
▼
[PHP-FPM]
│
▼
[AtoM]
│
▼
[Sistema de arquivos]
Se a comunicação for interrompida em uma dessas etapas, o diagnóstico precisa considerar onde a interrupção aconteceu.
Por isso, diante de um problema de upload, não é recomendável concluir imediatamente:
“É um problema do Nginx.”
Pode ser.
Mas também pode ser uma limitação do PHP, uma condição do sistema de arquivos, uma falha de processamento, uma questão de rede ou simplesmente a duração da requisição mantida pelo navegador.
4. A primeira solução simples: reduzir o tamanho dos lotes
Antes de recorrer ao CLI, existe uma solução extremamente simples:
reduzir a quantidade de arquivos enviados em cada operação.
Por exemplo, em vez de:
100 arquivos
↓
1 único upload
podemos trabalhar com:
20 arquivos
↓
upload
20 arquivos
↓
upload
20 arquivos
↓
upload
...
Essa estratégia não modifica a arquitetura do AtoM, mas reduz a duração individual de cada operação.
Em determinados ambientes, isso pode ser suficiente.
É uma solução particularmente interessante quando:
o volume total não é muito grande;
os arquivos são pequenos;
o processo é eventual;
não existe acesso administrativo ao servidor;
ou a instituição precisa que o procedimento seja realizado por usuários sem acesso ao terminal.
Mas existe uma questão importante:
essa estratégia trata o sintoma operacional, não necessariamente a questão arquitetural.
Se a instituição possui milhares ou milhões de objetos digitais, dividir manualmente os arquivos em pequenos lotes dificilmente será uma estratégia sustentável.
Nesse momento, precisamos mudar a abordagem.
5. O CLI do AtoM muda completamente o cenário
Uma das características importantes do AtoM é que ele não depende exclusivamente da interface web.
O sistema disponibiliza diversas tarefas administrativas executadas diretamente pela linha de comando.
A documentação oficial do AtoM 2.10 inclui uma tarefa específica denominada Digital object load task, destinada justamente à associação em massa de objetos digitais a descrições arquivísticas existentes.
O comando básico é:
php symfony digitalobject:load /path/to/your/loadfile.csv
A grande diferença é que o processamento deixa de depender da manutenção de uma requisição do navegador aberta durante toda a operação.
O administrador trabalha diretamente no servidor.
Isso transforma o problema:
Navegador
↓
Upload
↓
Timeout
em:
Servidor
↓
Arquivos disponíveis localmente
↓
CSV de relacionamento
↓
AtoM CLI
↓
Processamento
A própria documentação do AtoM 2.10 destaca que a tarefa de carregamento de objetos digitais está disponível via linha de comando.
6. Como funciona o digitalobject:load
O processo é conceitualmente simples.
Precisamos preparar:
um diretório contendo os objetos digitais;
um arquivo CSV;
uma forma de identificar a descrição arquivística à qual cada objeto deverá ser associado.
O CSV possui duas colunas:
filename,slug
ou:
filename,identifier
ou ainda:
filename,information_object_id
A documentação do AtoM 2.10 permite essas três formas de identificação. Entretanto, somente uma delas deve ser utilizada no CSV.
Um exemplo hipotético:
filename,slug
/usr/share/nginx/atom/import-images/documento-001.jpg,descricao-documento-001
/usr/share/nginx/atom/import-images/documento-002.jpg,descricao-documento-002
/usr/share/nginx/atom/import-images/documento-003.jpg,descricao-documento-003
Depois:
php symfony digitalobject:load /usr/share/nginx/atom/import-images/import.csv
Se todos os arquivos estiverem em um mesmo diretório, podemos simplificar ainda mais o CSV utilizando a opção --path.
Por exemplo:
filename,slug
documento-001.jpg,descricao-documento-001
documento-002.jpg,descricao-documento-002
documento-003.jpg,descricao-documento-003
E:
php symfony digitalobject:load \
--path="/usr/share/nginx/atom/import-images/" \
/usr/share/nginx/atom/import.csv
A opção --path existe justamente para evitar a repetição do caminho completo de cada arquivo.
7. Um detalhe importante: validar antes de importar
Em uma operação de preservação digital ou de gestão documental, simplesmente executar o comando não deveria ser a primeira etapa.
Antes é recomendável validar a correspondência entre:
os arquivos existentes;
os caminhos indicados no CSV;
os arquivos que realmente serão importados;
possíveis arquivos não referenciados;
caminhos incorretos;
duplicidades.
O AtoM 2.10 possui uma tarefa específica para essa conferência:
php symfony csv:digital-object-path-check \
/usr/share/nginx/atom/import-images/ \
/usr/share/nginx/atom/digital-object-load.csv
A documentação explica que essa tarefa pode verificar, entre outras coisas, se os arquivos indicados no CSV existem no diretório informado e se existem arquivos no diretório que não estão referenciados pelo CSV.
Essa etapa é extremamente importante.
Em um ambiente institucional, devemos preferir:
PREPARAR
↓
VALIDAR
↓
IMPORTAR
↓
VERIFICAR
↓
INDEXAR
e não simplesmente:
COPIAR
↓
EXECUTAR
↓
TORCER PARA DAR CERTO
8. E existe outra alternativa: digitalObjectPath
O AtoM também permite trabalhar com objetos digitais durante a importação de descrições por CSV.
Para isso, existem as colunas:
digitalObjectPath
digitalObjectURI
A coluna digitalObjectPath pode ser utilizada para indicar o caminho local de um objeto digital que será associado à descrição durante a importação.
Isso abre uma possibilidade bastante interessante.
Imagine que uma instituição esteja realizando simultaneamente:
criação de descrições;
organização hierárquica;
associação dos objetos digitais.
Em vez de criar todas as descrições pela interface e posteriormente anexar manualmente os arquivos, pode-se estruturar um CSV que contenha os dados descritivos e os caminhos dos objetos.
Conceitualmente:
CSV
│
├── descrição
├── título
├── código de referência
├── nível de descrição
├── relações hierárquicas
└── digitalObjectPath
Esse modelo pode ser particularmente útil em projetos de digitalização ou migração de acervos.
9. E aqui aparece uma diferença importante do AtoM
Existe uma situação que pode parecer contraditória à primeira vista:
o upload direto de um objeto digital pela interface e a importação de dados por CSV não necessariamente percorrem o mesmo caminho arquitetural.
O AtoM 2.10 utiliza o sistema de jobs para determinadas operações de importação/exportação realizadas pela interface. A documentação explica que, desde o AtoM 2.4, as importações CSV pela interface passaram a utilizar o job scheduler para permitir o processamento de arquivos grandes sem depender do tempo de uma requisição do navegador.
Assim, podemos ter:
Upload direto
↓
requisição web
↓
processamento associado à requisição
enquanto:
Importação CSV
↓
Job
↓
fila
↓
worker
↓
processamento
Essa diferença explica por que uma instituição pode conseguir importar um CSV relativamente grande pela interface, enquanto encontra dificuldades ao enviar diretamente um conjunto de objetos digitais.
Não é necessariamente uma contradição.
São operações diferentes.
10. O atom-worker não resolve automaticamente todos os uploads
O AtoM possui infraestrutura para processamento assíncrono baseada em jobs, utilizando Gearman e o atom-worker. Os jobs podem ser acompanhados na área de gerenciamento de tarefas do AtoM.
Entretanto, isso não significa que basta instalar ou reiniciar o atom-worker para transformar qualquer operação da interface em uma operação assíncrona.
É necessário que a própria operação tenha sido projetada para utilizar o mecanismo de jobs.
Esse é um ponto arquitetural muito importante.
Não devemos confundir:
“O AtoM possui processamento assíncrono”
com:
“Todas as operações do AtoM são assíncronas”.
São afirmações completamente diferentes.
11. Por que simplesmente aumentar os timeouts não é necessariamente a solução?
Quando aparece um problema de upload, uma reação bastante comum é aumentar os limites:
max_execution_time
upload_max_filesize
memory_limit
Essas configurações realmente podem ser importantes.
A documentação do AtoM 2.10 possui uma seção específica sobre os limites de execução do PHP e explica que esses parâmetros podem provocar interrupções prematuras, especialmente durante o tratamento de arquivos grandes.
Mas existe uma diferença entre:
aumentar o limite
e
mudar o modelo de processamento.
Imagine uma operação que demora dois minutos.
Podemos tentar transformá-la em:
timeout de 30 segundos
↓
timeout de 5 minutos
Talvez funcione.
Mas ainda teremos:
navegador
↓
requisição aberta por vários minutos
↓
servidor processando
↓
resposta
Agora imagine uma operação que demora 20 minutos.
Ou uma hora.
Ou várias horas.
A solução não deveria ser indefinidamente aumentar o timeout.
Em determinado momento, a questão deixa de ser:
“Qual timeout devemos configurar?”
e passa a ser:
“Por que essa operação ainda depende de uma requisição web permanecer aberta durante todo o processamento?”
Essa é uma pergunta de arquitetura de software.
12. O que seria necessário para tornar o upload verdadeiramente assíncrono?
É aqui que precisamos ter cuidado ao falar sobre desenvolvimento.
À primeira vista, alguém poderia pensar:
“Basta colocar o upload em uma fila.”
Na prática, uma implementação robusta é muito mais complexa.
Um sistema de upload assíncrono precisaria considerar, entre outras coisas:
1. Recepção dos arquivos
Como o navegador envia os arquivos?
Um por vez?
Em lote?
Em partes (chunks)?
2. Persistência temporária
Onde os arquivos ficam antes de serem processados?
Como impedir que arquivos incompletos sejam tratados como arquivos válidos?
3. Criação do job
Como a aplicação registra:
Job #12345
e associa a ele:
arquivo 1
arquivo 2
arquivo 3
...
4. Processamento pelo worker
O worker precisa saber:
receber
→ validar
→ armazenar
→ gerar derivados
→ registrar relação
→ atualizar estado
5. Recuperação de falhas
Se o arquivo 37 falhar, o que acontece?
Todos os outros 36 são perdidos?
O sistema tenta novamente?
O usuário precisa reiniciar tudo?
6. Progresso
O usuário precisa saber:
37 / 500 arquivos processados
e não simplesmente ficar olhando uma página aparentemente congelada.
7. Cancelamento
O usuário pode cancelar o job?
O que acontece com arquivos parcialmente processados?
8. Retomada
Se a conexão do usuário cair, o processo pode continuar?
9. Integridade
Como garantir que o objeto recebido é exatamente aquele que deveria ser processado?
10. Segurança
Como impedir que um usuário envie arquivos para caminhos indevidos ou tente explorar o sistema de arquivos?
11. Derivados
Como tratar:
master;
thumbnail;
reference display copy;
eventuais erros de geração?
12. Estado transacional
O sistema precisa distinguir:
recebido
de:
processado
e:
associado
e:
derivados gerados
e:
erro
Portanto, desenvolver um mecanismo realmente assíncrono de upload de objetos digitais não é apenas adicionar uma chamada ao job scheduler.
É uma alteração que envolve diferentes componentes da aplicação.
13. É por isso que desenvolvimento de software exige dedicação
Essa discussão também nos ajuda a compreender uma questão frequentemente esquecida nas comunidades de software livre.
Quando alguém pergunta:
“Por que ainda não existe determinada funcionalidade?”
A resposta raramente é simplesmente:
“Porque ninguém pensou nisso.”
Em sistemas complexos como o AtoM, uma funcionalidade aparentemente simples pode envolver:
arquitetura;
banco de dados;
interface;
JavaScript;
PHP;
filas;
workers;
armazenamento;
tratamento de erros;
segurança;
testes;
compatibilidade;
documentação;
migração;
manutenção futura.
E existe ainda um princípio fundamental:
desenvolver uma funcionalidade é apenas uma parte do trabalho; mantê-la funcionando em diferentes versões, ambientes e situações de uso é outra parte igualmente importante.
Por isso, projetos maduros precisam estabelecer prioridades.
Uma funcionalidade nova pode ser tecnicamente desejável e, ainda assim, competir com:
correções de segurança;
atualizações de dependências;
compatibilidade com novas versões do Ubuntu;
PHP;
Elasticsearch;
correções de banco de dados;
manutenção do código;
melhorias de desempenho;
correções de bugs;
requisitos de segurança.
Isso não significa que uma funcionalidade não seja importante.
Significa que software é um processo contínuo de escolhas técnicas e alocação de esforço de desenvolvimento.
14. A alternativa prática hoje: separar transferência e processamento
Para instituições que trabalham com grandes volumes, uma estratégia bastante interessante é separar duas operações que frequentemente são confundidas:
Transferência dos arquivos
Os objetos digitais podem ser colocados no servidor por mecanismos apropriados ao ambiente institucional.
Por exemplo:
servidor de arquivos
↓
diretório de importação
↓
AtoM
Processamento pelo AtoM
Depois:
diretório de importação
↓
CSV
↓
validação
↓
digitalobject:load
↓
AtoM
Isso é muito diferente de pedir ao navegador:
me envie 5.000 arquivos
e esperar que a mesma requisição HTTP permaneça aberta até que tudo esteja terminado.
O servidor já possui os arquivos.
O CLI simplesmente processa o conjunto.
15. Uma arquitetura operacional mais madura
Para um projeto institucional de maior escala, podemos imaginar um fluxo como este:
ACERVO DIGITAL
│
▼
Área controlada de ingestão
│
▼
Validação dos arquivos
│
▼
CSV / METADADOS
│
▼
Validação do CSV
│
▼
Conferência dos caminhos
│
▼
digitalobject:load
│
▼
Processamento
│
┌────────┴────────┐
▼ ▼
Derivados Relações
│ │
└────────┬────────┘
▼
Indexação AtoM
│
▼
DISPONIBILIZAÇÃO
Esse modelo começa a se aproximar muito mais de uma perspectiva de gestão técnica de objetos digitais do que simplesmente de uma perspectiva de “fazer upload”.
E essa diferença é fundamental.
16. E se o digitalobject:load apresentar problemas?
O CLI também exige cuidados.
A documentação do AtoM informa, por exemplo, que o processo normalmente não indexa a coleção durante a execução, para permitir maior velocidade. Depois da importação, pode ser necessário executar:
php symfony search:populate
para atualizar o índice de pesquisa.
Também existem opções como:
--index
para indexar durante o processo.
E:
--skip-nested-set-build
quando se deseja evitar determinadas atualizações da estrutura hierárquica durante a execução e reconstruí-la posteriormente.
Existe ainda:
php symfony digitalobject:regen-derivatives
para regenerar miniaturas e cópias de referência quando necessário. Entretanto, a própria documentação traz um alerta importante: essa tarefa elimina os derivados atuais e os recria a partir do master digital. Portanto, não é um comando para executar indiscriminadamente em produção.
17. Uma observação especialmente importante sobre múltiplos objetos
Existe ainda uma característica do modelo do AtoM que precisa ser compreendida antes de montar um CSV.
O AtoM mantém uma relação de um objeto digital por descrição arquivística, ressalvadas as situações relacionadas aos derivados. Quando se pretende associar vários objetos a uma mesma descrição, é possível utilizar estratégias como a criação de descrições-filhas.
A própria tarefa digitalobject:load possui a opção:
--attach-only
que pode ser utilizada para criar descrições-filhas stub e associar os objetos digitais a elas. A documentação apresenta justamente o exemplo de múltiplas imagens, como páginas individuais de um livro.
Isso é particularmente interessante para projetos de digitalização.
Por exemplo:
Livro
│
├── Página 001 → imagem001.tif
├── Página 002 → imagem002.tif
├── Página 003 → imagem003.tif
├── Página 004 → imagem004.tif
└── Página 005 → imagem005.tif
Nesse caso, não estamos simplesmente “colocando cinco imagens dentro de uma descrição”.
Estamos modelando arquivisticamente os objetos digitais dentro da estrutura descritiva do AtoM.
18. Não confunda o problema de upload com o problema de preservação digital
Há ainda uma questão conceitual importante.
Conseguir colocar um arquivo dentro do AtoM não significa que o problema de preservação digital foi resolvido.
O AtoM é fundamentalmente um sistema de descrição, acesso e disponibilização de objetos digitais associados às descrições.
Em uma arquitetura de preservação digital sistêmica, devemos perguntar:
Onde está o master?
Quem controla o master?
Como ele chegou ao sistema?
Qual é sua fixidade?
Como são gerados os derivados?
Como são registrados os eventos?
Como é feita a preservação?
Como ocorre a cadeia de custódia digital?
Como o objeto preservado chega ao ambiente de acesso?
Por isso, em uma arquitetura que envolva, por exemplo, Archivematica + AtoM, o problema do upload no AtoM deve ser analisado dentro do fluxo maior e não isoladamente.
O AtoM pode atuar como ambiente de descrição e acesso, enquanto o ambiente de preservação possui responsabilidades diferentes.
Essa separação é fundamental para não transformar o AtoM em uma espécie de “depósito universal” de arquivos digitais sem uma arquitetura de preservação subjacente.
19. O que fazer, então?
Diante de uma situação hipotética de falha ou interrupção de uploads, podemos estabelecer uma sequência bastante objetiva:
Cenário 1 — poucos arquivos
Tentar novamente em lotes menores.
reduzir lote
↓
testar
↓
confirmar
Cenário 2 — muitos arquivos
Considerar a utilização do CLI:
php symfony digitalobject:load /path/to/loadfile.csv
Cenário 3 — descrição + objeto digital
Avaliar a utilização de:
digitalObjectPath
no CSV de importação.
Cenário 4 — grande projeto de migração
Estruturar:
arquivos
+
metadados
+
CSV
+
validação
+
CLI
+
indexação
Cenário 5 — necessidade institucional recorrente
Nesse caso, talvez seja necessário pensar além de uma solução pontual.
É o momento de discutir:
automação;
scripts;
pipelines;
integração;
API;
jobs;
armazenamento;
preservação digital;
monitoramento;
logs;
controle de integridade.
20. CLI não é um “atalho”: é parte da administração do AtoM
Talvez essa seja a principal conclusão.
Em projetos pequenos, é possível utilizar o AtoM predominantemente pela interface web.
Em projetos maiores, porém, conhecer a linha de comando deixa de ser uma habilidade opcional e passa a ser uma competência importante para a administração do sistema.
O próprio AtoM 2.10 possui uma ampla coleção de tarefas CLI para:
importação;
exportação;
validação;
indexação;
manutenção;
gerenciamento de objetos digitais;
reconstrução de estruturas;
manutenção do sistema.
A documentação oficial inclusive apresenta o CLI como uma alternativa especialmente útil para determinadas operações de maior escala.
Portanto, diante de um problema de upload, a pergunta não deveria ser simplesmente:
“Como faço o navegador aceitar mais arquivos?”
Uma pergunta tecnicamente mais interessante seria:
“Essa operação realmente deveria depender do navegador?”
Em muitos casos, essa mudança de perspectiva é justamente o que permite encontrar uma solução mais robusta.
Conclusão
O cenário hipotético analisado aqui revela uma questão maior sobre a administração de sistemas arquivísticos digitais.
O navegador é excelente para operações interativas.
Mas operações de grande volume podem exigir outro modelo.
No AtoM, temos diferentes caminhos:
INTERFACE WEB
│
└── adequada para operações interativas e volumes controlados
CSV + JOB SCHEDULER
│
└── adequado para determinadas importações assíncronas
CLI
│
└── adequado para operações administrativas e cargas em maior escala
ARQUITETURA DE PRESERVAÇÃO
│
└── responsável por uma camada mais ampla de preservação e custódia digital
O mais importante é compreender que essas alternativas não são concorrentes.
Elas fazem parte de uma arquitetura.
Quando o volume cresce, a pergunta deixa de ser apenas “como fazer upload?” e passa a ser “qual é o mecanismo adequado para ingestão, processamento, associação, preservação e disponibilização desses objetos digitais?”
E é justamente nesse ponto que o conhecimento do AtoM deixa de ser apenas conhecimento de interface e passa a envolver administração de sistemas, linha de comando, automação, arquitetura de informação e preservação digital.
Documentação oficial consultada
A análise foi baseada na documentação oficial do AtoM 2.10, especialmente nas seções relativas a:
importação e exportação pela linha de comando;
digitalobject:load;validação de caminhos de objetos digitais;
importação CSV;
processamento assíncrono e jobs;
limites de execução do PHP;
geração e regeneração de derivados.
A documentação oficial do AtoM 2.10 está disponível em:
Documentação oficial do AtoM 2.10
Comentários
Postar um comentário
Comente aqui, por favor .....