Ir para o conteúdo principal

Arquitetura

Atualizado em 05/12/2016 Link permanente Índice

Conforme mencionado no escopo, o eDok Ingest é composto de duas partes distintas: admissão e integração. Estas áreas têm implementações arquitetônicas distintas, apesar de compartilharem a mesma arquitetura comum do eDok Core.

A seguir são apresentados os detalhes da arquitetura de cada uma das partes que compõem o eDok Ingest.

Arquitetura da Admissão

A camada de automação da admissão de documentos do eDok Ingest é composta por um complexo arranjo de tecnologias. Apesar da complexidade inerente à solução, quase tudo é transparente para o usuário final e apenas uma pequena e essencial parte é exposta à equipe técnica do cliente que cuidará da configuração e operação interna do serviço.

Essa implementação é apresentada abaixo, primeiro graficamente e em seguida cada elemento é descrito em detalhes.

Arquitetura do eDok Ingest.

Arquitetura do eDok Ingest.

A utilização da camada de admissão do eDok Ingest começa na geração do identificador. É ele que fornecerá os metadados primários para a indexação de cada documento admitido.

O identificador é um dado lógico que pode se materializar de várias formas. Diferentes materializações podem inclusive coexistirem em um mesmo departamento do cliente.

O eDok suporta as seguintes materializações do identificador:

  • Nome do arquivo: documento nomeado com o padrão de identificação.
  • Reconhecimento ótico: etiquetas ou capas impressas previamente.
  • Manual: o usuário digita o identificador ao enviar o documento.
AVISO: a implementação manual não é recomendada para ambientes onde a admissão de documentos em grandes volume é necessária.

O eDok possui um gerador que pode ser utilizado para produzir os lotes pré-impressos de etiquetas ou capas. Se o cliente não deseja efetuar uma integração de dados com um sistema de terceiros, ou se o sistema de terceiros não possuir identificadores prévios e pode ser alimentado através do eDok, o gerador de etiquetas próprio é suficiente.

Sistemas de terceiros podem também ser utilizados para gerar as etiquetas ou capas. Esta implementação é a mais indicada no caso dos identificadores já estarem disponíveis em outros sistemas.

Com o identificador materializado e anexado ao documento, o scanner digitaliza o documento e o envia para o eDok automaticamente, no mesmo passo.

O recurso de envio de arquivos via rede deve ser suportado pelo scanner para funcionar com o eDok. Os protocolos suportados são FTP (não seguro) e FTPS (seguro e recomendado).

Se o cliente possui diversos pontos de digitalização ou requisitos especiais quanto a integridade de documentos em trânsito, poderá optar por implementar um concentrador para os scanners desejados. Mesmo utilizando-se um concentrador, poderão haver outros scanners que não passam por ele e se comunicam diretamente com o eDok.

AVISO: a implementação do concentrador não faz parte dos serviços eDok.

Os scanners ou concentradores se comunicam com a nuvem privada do eDok (VPC) primariamente via internet.

DICA: outros métodos de comunicação com o VPC eDok estão disponíveis mediante contratação específica. Os métodos adicionais disponíveis são, especificamente, Hardware VPN e Direct Connect (50Mbps a 10Gbps).

No VPC eDok entram em cena os recursos que implementam a admissão com alta disponibilidade.

Primeiro, as conexões passam por servidores de DNS espalhados por todo o planeta. Esses servidores de DNS são especificamente configurados para prover altíssima disponibilidade do serviço de resolução de nomes aos balanceadores de carga, que por sua vez distribuem as conexões mediante condições específicas aos servidores de FTP/FTPS (FS1 e FS2).

Cada um desses servidores FTP/FTPS operam em regiões geograficamente distantes e independentes. Em condições normais de operação, é o servidor FS1 que atende as requisições FTP/FTPS dos scanners e concentradores do cliente.

Caso ocorra qualquer problema com o FS1 que torne a sua disponibilidade pior do que ótima, os balanceadores de carga detectam essa circunstância imediatamente e alteram a resposta do DNS para redirecionar todo o tráfego para o FS2.

Esta medida garante que caso ocorra a indisponibilidade completa de uma região geográfica que leve até mesmo a parada momentânea do serviço eDok (interface web) para o cliente, a produção de digitalização possa ocorrer de modo ininterrupto.

DICA: todos os eventos operacionais que levam a indisponibilidade de qualquer componente do serviço eDok são monitoradas 24 horas por dia, sete dias por semana, 365 dias por ano. A equipe operacional possui treinamento e reciclagem periódicos sobre como agir em cada caso para a mais breve ação, resolução, registro e melhoria contínua dos eventos que causam indisponibilidade.

Os servidores FS estão disponíveis direta e internamente, de modo seguro, para as instâncias do cliente que executam o eDok Core, que por sua vez executa os processos eDok Ingest.

Periodicamente, o processo eDok Ingest verifica se existem novas imagens nos servidores FS. Em caso positivo e para cada uma das novas imagens são executadas as seguintes tarefas:

  1. Controle de Qualidade: uma extensa e detalhada verificação de conformidade verifica se parâmetros como resolução, amostragem, profundidade de cores e outras características estritamente técnicas permitem que a imagem possa ser considerada útil para o reconhecimento dos identificadores. Caso os identificadores estejam no nome do arquivo, outras verificações pertinentes são executadas.
  2. Separação de lotes: caso o processo do cliente inclua o envio de múltiplos documentos em um mesmo lote de digitalização (por exemplo, 100 documentos digitalizados juntos, no mesmo arquivo), ocorre a separação dos lotes de documentos distintos.
  3. Extração dos Identificadores: reconhecimento ótico das etiquetas ou separação dos identificadores em nomes de arquivos.
  4. Marcação de Problemas: reconhecimentos que não foram bem sucedidos (múltiplas etiquetas na mesma página, ausência de etiquetas e outras não conformidades) são separados para tratamento posterior.
  5. Admissão Final: com os identificadores definidos e os arquivos separados e tratados, os documentos são finalmente admitidos e indexados no eDok.
  6. Registro: todas as operações, sucesso ou falha, são registradas em um log próprio. Os documentos admitidos com sucesso também são devidamente registrados no log central.

O processo de admissão do eDok Ingest é implementado de modo a ser tão sensível à falhas quanto seja conveniente para o cliente. Os parâmetros de controle de qualidade são passíveis de alteração a qualquer tempo para se adequarem aos equipamentos e processos do cliente (ver Implementação > Ambiente para mais detalhes).

Sendo sensível às falhas detectadas, o eDok Ingest informa ao administrador do sistema e aos usuários com os devidos privilégios sobre todas as não conformidades encontradas. Deste modo as medidas apropriadas podem ser estudadas e implementadas para a melhoria contínua do processo, e também para que os documentos com falhas possam ser admitidos manualmente.

Arquitetura das APIs

A camada de integração (API) do eDok Ingest é composta por um conjunto diferente de tecnologias se comparada à de admissão. Nesta camada os focos são a integridade e a segurança dos metadados, bem como a interoperabilidade com outros sistemas que fornecem metadados secundários aos documentos.

Como não é possível prever ou se adequar a todos os métodos disponibilizados pelas aplicações existentes no mercado, o eDok Core implementa uma interface de identificação de recursos baseada em JSON sobre uma API RESTful segura. Isto torna a integração com aplicações de terceiros um esforço trivial e reaproveitável por se tratar de um método uniforme, universal e tecnologicamente agnóstico.

Essa implementação é apresentada abaixo, primeiro graficamente e em seguida cada elemento é descrito em detalhes.

Arquitetura da API do eDok.

Arquitetura da API do eDok.

A utilização da camada de integração do eDok Ingest tem início na camada de admissão. Após os documentos passarem pelo processo de admissão já descrito anteriormente, a integração pode entrar em cena. Só é possível integrar as fontes de metadados secundários com documentos existentes no eDok Core. Não existem APIs para envio de documentos para o eDok.

As fontes de metadados secundários podem ser quaisquer sistemas de terceiros: bases de dados relacionais ou não relacionais, sistemas de faturamento, contabilidade ou administração, de controle de estoques ou compras, de gestão de processos ou pessoas, ERP, BPM, BI etc.

Múltiplos sistemas podem ser integrados simultaneamente para prover todos os metadados necessários.

Os metadados primários, aqueles contidos no identificador da camada de admissão, são a ponte entre o documento gerenciado pelo eDok e os demais sistemas integrados. A partir dos metadados primários de cada documento, ele pode ser fácil e rapidamente integrado a um sistema de terceiro qualquer. Por esta razão, metadados primários nunca são alterados via API.

DICA: metadados primários podem ser alterados através da interface web.

Vamos ilustrar um caso de uso da integração através de um exemplo: suponha um processo de admissão de documentos que necessite de metadados secundários de uma base de funcionários. O metadado primário de um funcionário pode ser o seu CPF, que é um bom método para identificar uma pessoa física de modo exclusivo. O CPF do funcionário fará parte do identificador como metadado primário, mas o identificador não conterá o nome, a data de nascimento, o número da carteira do plano de saúde e o número do PIS de nenhum funcionário. Esses metadados secundários estão espalhados em um ou mais sistemas de terceiros.

Para ocorrer a integração, os sistemas de terceiros consumirão a API RESTful do eDok para submeter os metadados secundários destinados a um número de CPF. Tanto o eDok quanto os sistemas de terceiros conhecem e compartilham o identificador CPF e podem trocar informações com base nele.

Deste modo, o nome e a data de nascimento do documento identificado no eDok pelo metadado primário CPF de número 123.456.789-91 serão enviados pelo sistema de gestão de pessoal. Seguindo com o exemplo, o sistema de gestão de benefícios enviará o metadado secundário número da carteira do plano de saúde e o sistema de gestão financeira enviará o metadado número do PIS. Ao final, o documento gerenciado pelo eDok conterá todos os metadados necessários, primários e secundários.

As fontes de metadados se comunicam com a nuvem privada do eDok (VPC) primariamente via internet.

DICA: outros métodos de comunicação com o VPC eDok estão disponíveis mediante contratação específica. Os métodos adicionais disponíveis são, especificamente, Hardware VPN e Direct Connect (50Mbps a 10Gbps).

No VPC eDok entram em cena os recursos que implementam a camada de integração do eDok Core: o DNS global e os balanceadores de carga, conforme descritos anteriormente, e a API RESTful.

AVISO: o eDok Core possui alta disponibilidade mediante contratação específica.

O transporte de dados da integração utiliza exclusivamente o protocolo HTTPS (seguro). Diferente da admissão, aqui não há alternativa de comunicação não segura. Isto ocorre em função da necessidade de troca de chave de acesso criptográfica entre as fontes de metadados e o eDok Core para estabelecer uma requisição na API, e pela natureza dos dados compartilhados entre os sistemas serem, em geral, confidenciais.

PERIGO!!! Caso a chave de acesso seja comprometida, um agente malicioso poderá alterar metadados de documentos livremente. A comunicação não segura facilita isso e por isto é vetada. A guarda da chave de acesso é uma responsabilidade compartilhada entre o cliente e eDok. O cliente deve entrar em contato com o eDok para informar o comprometimento da chave de acesso e solicitar uma nova.

Uma vez composta a requisição e enviada via HTTPS para a API RESTful, caso o documento exista, há apenas duas respostas esperadas: sucesso ou falha.

Se a requisição ocorreu com sucesso, os dados da requisição são registrados no log central do eDok Core. Isso cria trilhas de auditoria para todo o acervo documental.

Caso a requisição falhe, o tipo do erro encontrado é informado na resposta para que o responsável pela integração possa atuar apropriadamente para corrigir o problema.

O erro da requisição também é registrado no log central para facilitar as auditorias de segurança, exceto se a requisição foi feita para um documento que não existe. Neste caso não será registrada nenhuma mensagem no log.