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 os recupera, efetivando-os no banco de dados. Por fim, sinaliza para o Identity que a operação foi replicada com sucesso, 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

Em caso de erro no processamento das operações, o serviço de busca será interrompido pela classe OperationProcessor, que efetuará uma chamada ao método stopPull() da classe FluigPuller. Os erros também serão repassados à classe FluigPuller, os quais poderão ser recuperados pelo método getErrors().

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.

Os erros exibidos pelo Fluig Configurator também serão gravados em um arquivo a parte, juntamente com outros eventos relacionados à integração entre o ERP e o Identity. Este arquivo será chamado fluig-integration.log e o mesmo poderá ser baixado através de link disponibilizado na aba Gerenciamento. Sua geração dependerá de configuração específica no arquivo jboss-log4j.xml (localizado em <dir_inst_datasul>\jboss-4.2.3.GA\server\<instancia>\conf) que deverá ser alterado conforme sugerido a seguir:

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">

	(...)

    <!-- A size based file rolling appender -->
   <appender name="FLUIG" class="org.jboss.logging.appender.RollingFileAppender">
     <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
     <param name="File" value="${jboss.server.log.dir}/fluig-integration.log"/>
     <param name="Append" value="false"/>
     <param name="MaxFileSize" value="100MB"/>
     <param name="MaxBackupIndex" value="5"/>

     <layout class="org.apache.log4j.PatternLayout">       
       <param name="ConversionPattern" value="%d %-5r %-5p (%t:%x) [%c{1}] %m%n"/>
     </layout>        
   </appender>

	(...)
   
   <logger name="com.totvs.fluig">
     <level value="INFO" />
     <appender-ref ref="FLUIG"/>
   </logger>   

	(...)

</log4j:configuration>

O serviço de busca das operações também emitirá e-mail de notificação caso ocorra erro ao iniciar o serviço ou durante o processamento das operações em fila. O e-mail será enviado para o usuário informado na configuração do aplicativo do Identity, no campo "Nome do Usuário do Administrador do Domínio" da aba "Provisionar".

O e-mail enviado terá o seguinte formato:

Para habilitar o envio de e-mail no servidor de aplicação do Datasul, deve-se editar o arquivo mail-service.xml, localizado em <dir_inst_datasul>\jboss-4.2.3.GA\server\<instancia>\deploy. Os parâmetros que devem editados neste arquivo são:

• <attribute name="User">, informando um usuário válido no servidor de e-mail.

• <attribute name="Password">, informando a senha deste usuário.
• <property name="mail.smtp.host" value="{nome_servidor}"/>, informando o nome do servidor SMTP usado para enviar o e-mail.
• <property name="mail.smtp.port" value="{porta_servidor}"/>, informando a porta do servidor SMTP.
• <property name="mail.from" value="{e-mail_valido}"/>, informando um endereço de e-mail válido quando a autenticação for necessária no servidor.
• <property name="mail.smtp.auth" value="{true/false}"/>, informando true quando a autenticação for requerida para enviar e-mails.

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.