4 PROPOSTA DE GERENCIAMENTO DO PROCESSO DE CRIAÇÃO E MONITORAMENTO DO PLANO DE DADOS
4.4 IMPLEMENTAÇÃO DA PROPOSTA DE ELABORAÇÃO E MONITORAMENTO DO PLANO DE DADOS ABERTOS
Durante as pesquisas e análise das informações coletadas, foi identificada a necessidade da aplicação de acessar informações de um sistema interno dos órgãos afim de identificar informações que irão compor o Plano de Dados Abertos. Além disso, a aplicação deverá atender a outros critérios definidos pela CGINDA para que o PDA atenda os requisitos de qualidade exigidos. A princípio, a aplicação não irá dispor da funcionalidade de extração e publicação de dados, sendo necessária a integração com uma ferramenta externa que execute esta ação, o que não impede que essa funcionalidade seja desenvolvida futuramente, tornando a aplicação proposta independente de terceiros. Na Figura 7 conseguimos visualizar como o Opendata Manager atua no ambiente opendata, se comunicando com plataformas de dados abertos e ferramentas ELT.
Figura 7 Visão macro do ODM no ambiente opendata
Fonte: Elaborada pelo autor
Na Figura 7 observamos que o Opendata Manager se comunica com o serviço de mensageria, enviando e recebendo mensagens em um padrão específico. Tanto para o envio quanto para o retorno das mensagens, são utilizadas filas específicas dentro do servi o de mensageria, definidas pelo nome de in para filas de entrada e out para filas de saída. Para que as aplicações externas consigam ler e enviar mensagens, o ODM disponibiliza uma interface com os métodos a serem implementados, explicando como deve ser o formato de retorno das mensagens. Sendo assim, se estabeleci um padrão de comunicação e a troca de mensagem passa a ser possível. Atualmente, o Opendata Manager está se comunicando apenas com a ferramenta ETL Opendata Processor, que é responsável por extrair, tratar e publicar informações de um órgão. O Opendata Manager
envia quais os dados que serão extraídos e a periodicidade de atualização e o Opendata Processor realiza essa operação. Futuramente, novos módulos podem ser implementados dentro do ODM para que se possa extrair e publicar informações diretamente nas plataformas de dados abertos sem a necessidade de uma ferramenta de terceiro.
Para especificar detalhes do Opendata Manager, explicando como cada requisito funcional foi atendimento no desenvolvimento da aplicação, elaboramos na Figura 8 a comunicação entre os componentes que compõe a ferramenta.
Figura 8 - Destaque dos componentes internos do Opendata Manager
Fonte: Elaborada pelo autor
Como explicado anteriormente, o Opendata Manager é uma ferramenta baseada no framework django, logo, este framework já nos entrega algumas funcionalidades, como o gerenciamento de usuários, gerenciamento de grupos de usuários do sistema e gerenciamento de permissões. Além disso, o próprio django já oferece mecanismos de rotas de urls, onde conseguimos facilmente implementar regras de rewrite para acesso às nossas views. Por padrão, o django fornece implementações de middlewares voltados para segurança da aplicação como o CorsMiddleware e SessionMiddleware, mas é perfeitamente possível implementar seu próprio middlewares e integrá-los ao projeto. Em nossa aplicação, foi implementado um middleware que analisa o http request passado pelo navegador e, dependendo do subdomínio encontrado, conseguimos identificar qual o inquilino está acessando o sistema, configurando a interface com os arquivos estáticos adequados.
Sobre o framework, desenvolvemos módulos para suprir o restante dos requisitos. Um exemplo é o módulo PDA, responsável por gerenciar todos os cadastros relacionados a este documento. As entidades que compõem o módulo podem ser vistas na Figura 9.
Figura 9 - Diagrama de classe resumindo do módulo PDA
Fonte: Elaborado pelo autor
No diagrama de classes da Figura 9 podemos observar as seguintes entidades: 1) PDA onde compilamos as informações de todo o processo de desenvolvimento do documento, além de controlar as etapas destes de desenvolvimento; 2) TarefasPDA onde são cadastradas as tarefas que necessitam ser realizadas para avançar nas etapas de desenvolvimento; 3) ProvedorDados: cadastro do sistema do órgão que servirá as informações para que a nossa aplicação possa consumi-la; 4) ConsultaPublica uma das etapas de desenvolvimento do PDA é realizar uma consulta pública acerca dos inventários de dados levantados até o momento. O resultado da votação desta consulta é armazenado nesta entidade para ajudar na priorização das bases; 5) GrupoTrabalho é um agrupamento de usuários que ficarão responsáveis pelo desenvolvimento do PDA; 6) ConjuntoDados dentro de um inventário de dados, precisamos definir quais os dados que serão abertos, realizando uma triagem das informações a fim de não expor dados sensíveis; 7) DadoSigiloso podemos definir por padrão alguns dados que, recorrentemente, s o marcados como dados sens veis. Ao cadastrar o dado password , por exemplo, quando consultarmos um conjunto de dados, este será ignorado e não fará parte dos dados que serão abertos; 8) ConfiguracaoAcesso tela onde realizamos os
cadastros de parâmetros de acesso a serviços de mensageria, API ou banco de dados; 9) ResponsavelPDA detalhamento de cada membro do grupo de trabalho.
Outro módulo importante da aplicação é o Tasks Manager, responsável por gerenciar as tarefas que serão armazenadas no sistema. É ele que gerencia os prazos e cria alertas para avisar aos usuários do sistema sobre o término de uma ação. Neste módulo utilizamos a biblioteca APScheduler para agendar todas as tarefas de todos os módulos desenvolvidos. Na Figura 10 - Código exemplificando o agendamento de tarefas podemos observar que o método checa_prazos da classe TarefasPDA será invocado todos os dias a zero horas. Este método verifica a situação de todas as tarefas cadastradas e emite os alertas quando necessário.
Figura 10 - Código exemplificando o agendamento de tarefas
Fonte: Elaborada pelo autor
O módulo Dashboard é responsável por compilar as informações de outros módulos a fim de criar gráficos e estatísticas que serão apresentadas tanto na tela dashboard da área restrita, quanto na área pública, ficando disponível também para a população.
Com relação ao módulo integrador, este é responsável por configurar o serviço de mensageria que será utilizado na integração com outros sistemas. Nesta configuração é possível definir o nome da queue de entrada e saída de mensagens, definir o exchange utilizado na comunicação, a porta e host onde o serviço está rodando. De acordo com o que foi concluído na discussão sobre os serviços de mensageria, levando em consideração a capacidade de envio de mensagens por segundo, persistência de dados e a capacidade de consumo dos três brokers analisados, ficou definido que vamos utilizar o RabbitMQ para ser o nosso intermediador entre as aplicações.
Além destes, foi necessário implementar uma camada se serviço para implementar consultas a sistemas que não consegue integração com serviços de mensageria. Essa camada criada pode ser implementada com consultas REST ou SOAP, dependendo da necessidade.