Histórico da Página

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

Objetivo

Fornecer uma alternativa de sincronização das alterações realizadas no Identity com o Datasul quando estes estiverem integrados.

Atualmente, após ativar a integração entre Identity e Datasul, as operações de provisionamento como habilitar um usuário para utilizar o Datasul, inclui-lo em um grupo de segurança ou atribuir um item de menu ao mesmo são executadas exclusivamente no Identity, sendo necessário replicar estas alterações no Datasul para manter a consistência dos dados.

Esta replicação se dá com o Identity "empurrando" as alterações para o Datasul através de requisições HTTP usando o padrão REST (o que denominaremos como "modo push"). Como o Identity localiza-se na "nuvem", torna-se imprescindível que o Datasul esteja acessível a partir da internet, o que obriga aos clientes exporem o servidor de aplicação do Datasul.

Obviamente, esta exposição exige um cuidado maior com segurança de acesso (ajustes das políticas de acesso com liberação de portas especificas no firewall, por exemplo), o que nem sempre é possível ou aceitável pelos clientes. Neste cenário, a alternativa proposta é fazer com que o Datasul consulte o Identity, "puxando" as alterações realizadas e efetivando-as do seu lado (modo pull).

Definição da Regra de Negócio

Visão Geral

O novo modelo de sincronização, em oposição à atual técnica de pushing (empurrar, em português), utiliza a técnica de pulling (puxar), que consiste em requisições periódicas do Datasul ao Identity, com o objetivo de consumir uma fila de operações pendentes. Havendo itens nesta fila, o Datasul as os recupera, efetivando-as os no banco de dados. Por fim, sinaliza para o Identity que a operação foi replicada com sucesso, e este o qual remove a operação pendente da fila.

As operações realizadas no Identity serão encaminhadas para duas filas: de aplicativo e de usuários. A fila de aplicativo conterá operações como:

• Criação de papel (grupo de segurança) no aplicativo;
• Alteração de dados do papel;
• Eliminação do papel;
• Habilitar consulta rápida ou item de menu no papel do aplicativo;
• Desabilitar consulta rápida ou item de menu no papel do aplicativo.

A fila de usuários conterá operações como:

• Associar (provisionar) um usuário ao aplicativo;
• Desassociar (desprovisionar) um usuário do aplicativo;
• Provisionar um usuário a um papel do aplicativo;
• Desprovisionar um usuário de um papel do aplicativo;
• Provisionar uma empresa do aplicativo a um usuário;
• Desprovisionar uma empresa do aplicativo de um usuário.

Em relação a fila de usuários, será possível consultar previamente a lista de usuários que possuem operações pendentes no Identity. Com esta lista, o Datasul poderá buscar apenas as operações de um usuário específico, quando necessário.

A recuperação das operações pendentes nas filas ocorrerá de duas formas:

• Periodicamente, em intervalos de 15 segundos para a fila do aplicativo, e intervalos de 30 segundos, para a fila de usuários;
• Quando o usuário acessar o Datasul;.

Arquitetura

• Fluig Configurator: é o responsável por fornecer a interface de gerenciamento do serviço de busca de operações, permitindo parar ou iniciar o mesmo, bem como verificar o status. É também pelo Fluig Configurator que se ativa e desativa o modo "pull".
• FluigPullControllerResource: fornece as APIs REST para iniciar, parar e verificar o status do serviço de busca das operações. Por estar desacoplado do Fluig Configurator, pode ser acionado por qualquer outro recurso que implemente o padrão REST.
• FluigPullApplicationListener: é o responsável por iniciar o serviço de busca das operações quando o servidor de aplicação do Datasul é iniciado, desde que o modo "pull" esteja ativado.
• FluigPuller: implementa o serviço de busca das operações. É responsável por consultar as filas do Identity, buscar as operações para processamento e avisar ao Identity quando a operação foi processada com sucesso.
• OperationProcessor: é o responsável por processar as operações obtidas, encaminhando-as para as rotinas correspondentes do Datasul.

Implementação

A limpeza das filas no Identity ocorrerá após a classe OperationProcessor receber o retorno positivo do método responsável pelo processamento da operação. Será efetuada a chamada aos métodos clearAppQueue e clearUserQueue da classe FluigPuller, passando a lista das operações processadas e o usuário, no caso do segundo método.

b) Monitoramento e controle

Para controle do serviço de busca (parada e inicio), o Fluig Configurator disponibilizará uma nova aba, chamada Gerenciamento, (ver Figura 2) na qual constará:

• Botão para parar/iniciar o serviço.
• Campo para mostrar o status atual do serviço.
• Campo para mostrar os erros ocorridos na execução do serviço de busca.
  

O botão só estará habilitado se o modo "pull" estiver habilitado. O botão alterará o seu label conforme o status atual do serviço. Se o serviço estiver parado, será exibido o texto "Iniciar". Se estiver executando, será exibido o texto "Parar". Ao lado do botão será exibido o texto do status atual (Executando/Parado). A determinação do status atual será feita consultando o serviço REST Status (/fluig-pull/service/status), conforme comentado no item a) Fluxo básico. 

O campo para mostrar os erros ocorridos será alimentado com as informações provenientes do serviço REST Errors (/fluig-pull/service/errors). O retorno do serviço terá formato semelhante ao mostrado abaixo:

[
 { "origin" : "setup", "message" : "Texto da mensagem de erro" },
 { "origin" : "startPull", "message" : "Texto da mensagem de erro" },
 { "origin" : "9843ld0d-29302s-akj20ld0" : "Texto da mensagem de erro" }
]

Onde:

• origin: indica a origem do erro, que pode ser o ID da operação em processamento, ou uma das partes do processo de busca das operações que antecede o processamento;
• message: texto da mensagem de erro.

Protótipo de Tela

Fluig Configurator

Figura 1 - Novo campo na tela de configurações para o modo Pull.

Figura 2 - Esboço da tela de gerenciamento do serviço de busca de operações do modo Pull.

Fluxo do Processo 

Figura 3 - Ações do administrador, relacionadas ao modo pull, executadas tanto no Identity quanto no ERP.

Figura 4 - Arquitetura básica da solução.

Figura 5 - Fluxo da busca periódica de operações no Identity.

Figura 6 - Fluxo da busca sob demanda.