FUNCIONALIDADE DO OPENDATA MANAGER

As funcionalidades desenvolvidas no OpenData Manager foram pensadas em dar suporte todos os processos de elaboração de um PDA, desde a identificação dos responsáveis pelo documento a até a conclusão do PDA, onde é fechada uma versão do documento para a publicação nas plataformas de dados aberto, e é monitorado cada item, base e atividades que foram descritos neste documento. A aplicação foi desenvolvida utilizando a linguagem de programação Python e o framework web Django, além do banco de dados PostgreSQL (POSTGRESQL..., 2019). Ela contará com duas áreas de acessos.

5.1.1 Área de Acesso Público

Nesta área pode acessar uma interface que disponibilizará o PDA construído pela instituição. Este PDA estará disponível nos formatos HTML, estruturado na própria página, e outra versão em PDF, com um link disponível para download do documento.

A área de acesso pública muda a sua interface de acordo com o estado do processo de construção do PDA. Um exemplo é o fato de a interface disponibilizar uma enquete com as bases de dados que foram selecionadas a serem abertas. Essa enquete está relacionada com um dos processos de construção do PDA, onde um dos critérios de prioriza o das bases Grau de relevância para o cidadão (Resolução Nº 3, Art. 1º, I, § 1º) . Desta forma, o pr prio cidad o poderá participar na prioriza o das bases, atribuindo valor de relevância a elas. A enquete ficará disponível apenas no período de priorização das bases, dando espaço a outras informações do andamento da construção do PDA.

5.1.2 Área de Acesso Restrito

Esta área destina-se aos usuários do sistema, que deverão ser cadastrados previamente, sendo-lhes atribuídos um login de acesso e uma senha. É nesta área onde o

PDA será construído e todos os cadastros que irão dar suporte a esta construção são disponibilizados.

Ao realizar o login no sistema, o usuário é direcionando para a administração do ODM (Figura 11), acessando inicialmente ao dashboard do sistema que irá mostrar ao usuário um panorama geral do sistema, tanto em relação a evolução do PDA, como em relação as integrações existentes com outros sistemas.

Figura 11 - Dashboard do OpenData Manager

Fonte: Elaborada pelo autor

Como podemos observar na Figura 11 - Dashboard do OpenData Manager, temos integração com o Broker, CKAN e SIG Service off-line, ou seja, esses serviços estão inalcançáveis por alguns motivos, como o serviço não está ativo, a configuração de conexão não está cadastra ou está cadastrada, mas com parâmetros incorretos. Também podemos observar os passos de construção do PDA, aonde vai desde o cadastro do Grupo de Trabalho a at Registrar o PDA . Em cada um desses passos existem tarefas que precisam ser executadas e que, ao ser concluídas, são taxadas e marcadas no campo

checkbox. A cada tarefa realizada de cada passo da construção do PDA, um gráfico aponta

a porcentagem de evolução da construção do documento. Entende-se que o PDA está concluído quando todas as tarefas forem realizadas e o status do PDA for marcado para

Conclu do .

Para cada passo mostrado no dashboard, foi necessário implementar as funcionalidades que dão suporte às ações. Elas serão descritas nas subseções seguintes.

5.1.2.1 Grupo de Trabalho

Como vimos nos manuais citados anteriormente neste trabalho (ENAP e CGU), o primeiro passo para iniciar os trabalhos é realizar reuniões com as áreas finalísticas do órgão a fim de esclarecer pontos relativos à Política de Dados Abertos e traçar estratégias para a elaboração do PDA. É orientado nos manuais a criação do um Grupo de Trabalho (GT) para melhor conduzir o trabalho de construção do documento.

Para dar suporte a esta orientação, criamos o cadastro do GT, onde é possível identificar os responsáveis pela elaboração do PDA, assim com as áreas (setores) de cada um.

Para iniciar o segundo passo de elaboração do PDA, é necessário que exista pelo menos um Grupo de Trabalho cadastrado com pelo menos um responsável de uma área. Com esse registro realizado, é possível realizar os cadastros das atividades realizadas pelo GT e, assim que concluídos, podemos finalizar as atividades do GT clicando na opção finalizar atividades, como mostra a imagem abaixo.

Figura 12 - Listagem de grupo de trabalho com destaque para a opção de Finalizar Atividades.

Fonte: Elaborada pelo autor

Ao finalizar as atividades do GT, o OpenData Manager entende que a próxima etapa está habilitada, podendo então o usuário seguinte para o próximo passo de elaboração do PDA.

5.1.2.2 Definição do inventário de dados

O próximo passo é definido como o levantamento geral das fontes de dados, onde as bases de dados do órgão, por secretaria/departamento, serão ser exposta e discutidas a fim de definir algumas ações: (i) quem será o responsável por gerenciar as informações de determinadas bases; (ii) período de atualização dessas bases, e; (iii) verificar se essas bases contêm dados sigilosos.

Segundo o Artigo 4º, III, a, b, c e d da Resolução nº 3/2017 do CGINDA, essa relação das bases de dados de órgãos e entidades devem identificar os seguintes pontos:

a) as bases de dados já abertas e catalogadas no Portal Brasileiro de Dados Abertos;

b) as bases de dados já abertas e não catalogadas no Portal Brasileiro de Dados Abertos;

c) as bases de dados ainda não disponibilizadas em formato aberto na data de publicação do PDA; e

d) as políticas públicas às quais as bases estão relacionadas, quando aplicável;

O manual da CGU (CGU, 2020), que foi desenvolvido segundo as resoluções da CGINDA, disponibiliza um modelo (Tabela 16) que pode ser adotado para o levantamento do inventário das bases.

Tabela 16 - Tabela para levantamento de inventário das bases de dados.

Fonte: Tabela retirada do manual da CGU

Com base nessa tabela, elaboramos o cadastro de inventário dentro do OpenData Manager que dará suporte na relação desse inventário.

A partir deste momento, precisamos ter o cadastro dos sistemas que irão prover os dados. A primeira configuração que precisamos cadastrar são as informações dos provedores de dados, ou seja, os sistemas que irão nos prover as informações do órgão. Após o cadastro, as informações ficaram disponíveis na tela representada na Figura 13:

Figura 13 - Informações cadastradas do SUAP.

Fonte: Elaborada pelo autor.

Observando a Figura 13 - Informações cadastradas do SUAP. do cadastro do SUAP, percebemos que ele dispõe de dois tipos de configuração de acesso, uma via serviço, e outra via banco de dados. Tamb m podemos observar na coluna Status que a conexão via serviço está apresentando um erro de conexão. Isso se deve ao fato de o SUAP não estar com uma instância rodando na porta especificada na url do serviço. Já a conexão com o banco de dados está funcionando perfeitamente.

As configurações de acesso são importantes para que o OpenData Manager seja capaz de popular informações da instituição no cadastro de inventário. Ao acessarmos a listagem de inventários cadastrados no ODM, podemos observar uma coluna com uma a o chamada Seleciona Dados .

Figura 14 - Listagem de inventário de dados com ênfase na ação "Selecionar Dados"

Ao clicar nessa ação (selecionar dados), o usuário será direcionado para um formulário onde poderá listar os provedores de dados e selecionar qual tipo de configuração de dados irá utilizar para acessar as informações.

Outro ponto que vale destacar neste momento, é o cadastro de dados sigilosos. Para ter um registro mais genérico de informações sigilosas, foi criado no ODM um cadastro dessas informações atrelado ao provedor de dados. Por exemplo, o SUAP terá um cadastro onde será indicado os campos de sua base de dados que não podem ser extraídos.

Figura 15 - Lista de campos que são considerados sigilosos pelo SUAP.

Fonte: Elaborada pelo autor

Na implementação desta funcionalidade, pensamos em dois tipos de níveis de dados sigilosos, onde podemos simplesmente omitir o campo quando ele for consultado, ou mascará-lo, quando o campo pode ser informado, mas não a sua informação completa. Com o tratamento desses dados, o OpenData Manager atende parcialmente a LGPD. 5.1.2.3 Consulta pública

Todos os inventários cadastrados serão disponibilizados na área pública do ODM em forma de enquete, para possibilitar a participação social na escolha dos dados. O manual da CGU sugere que a votação dos inventários tenha uma duração de 15 dias. 5.1.2.4 Elaborar a matriz de priorização

Com o intuito de direcionar os esforços de abertura de cada base da instituição, foi criado o formulário de matriz de priorização, seguindo o modelo disponível no manual da CGU (CGU, 2020). A Figura 16 - Matriz de priorização das bases de dados da CGU. mostra como é a matriz de priorização elaborada e exposta no manual da GCU.

Figura 16 - Matriz de priorização das bases de dados da CGU.

Fonte: Imagem retirada do manual da CGU

O formulário criado (Figura 17) permite ao grupo de trabalho analisar cada base de dados de acordo com os critérios definidos na Resolução nº 3/2017 do CGINDA.

Figura 17 - Formulário da matriz de priorização.

As pontua es 0, 1, 2 e 3 foram substitu das pelas descri es N o se aplica , Baixo , M dio e Alto , respectivamente. Ao finalizar os registros das notas de cada base em cada crit rio, poss vel executar a a o Finalizar Avalia o . Ao executá-la, será criada uma média das notas (score) para aquela base que servirá de referência para os esforços de abertura.

5.1.2.5 Definir relação final das bases

Para abarcar este passo do processo de elaboração do PDA, utilizamos a lista de inventários já existente, adicionando a a o Relaciona Base para PDA , onde marcamos as bases que ficarão disponíveis para compor o PDA. Apenas as bases relacionadas poderão ser selecionadas na confecção do Plano de Dados Abertos.

5.1.2.6 Cronograma de abertura

Este passo para definição de cronogramas de abertura das bases deverá levar em consideração o score atingido na matriz de priorização. Toda a parte de cronograma ainda está em fase de desenvolvimento.

5.1.2.7 Registro do Plano de Dados Abertos

Chegando ao passo final, esta é a etapa onde serão descritas todas as ações e estratégias definidas de todos os passos anteriores (CGU, 2020). É onde o documento de Plano de Dados Abertos será realmente criado, seguindo a estrutura definida nos manuais da CGU. Para que todas as ações fossem registradas de uma forma simples, criamos um formulário (Figura 18) dividido em abas, que contempla todos os tópicos sugeridos para a estrutura do documento.

Figura 18 - Exemplo do formulário de escrita do PDA.

Fonte: Elaborada pelo autor.

Com componentes que nos auxiliam na escrita de textos como se estivéssemos em um software próprio para edição de texto, conseguimos reescrever todo o PDA do IFRN. O PDA reescrito está disponibilizado na seção de anexos a este trabalho.

5.2 INTEGRAÇÃO

Com o intuito de expandir as ações com relação ao ambiente opendata, o Opendata Manager possui um módulo integrador (Figura 19) que fornece uma interface que interage com o serviço de mensageria. O objetivo principal é a comunicação com algum software externo que realize as operações de extração e publicação de dados. Como explicado na seção 3.3, vamos utilizar o Opendata Processor (ODP) para realizar essas tarefas.

Figura 19 - Integração ODM com ODP

O Opendata Processor precisará implementar a interface de comunicação com o serviço de mensageria (RabbitMQ) e, ao iniciar uma instância da aplicação, será necessário também chamar o método que inicia a escuta desse serviço. Sendo assim, as duas aplicações conseguirão se conectar ao broker e trocar mensagens através dele. Também é importante que as duas aplicações conheçam as chaves de submissão e consumo de mensagem. Com tudo configurado, a troca de mensagem acontecerá como mostrado no diagrama de sequência da Figura 20.

Figura 20 - Sequência de troca de mensagens entre as duas aplicações

Fonte: Elaboração do autor

Com essa troca de mensagem, conseguimos executar ações dentro do ODP, inclusive solicitar a extração dos dados e a publicação deste na plataforma de dados abertos que estiver configura nele.