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

• Start (GET /fluig-pull/service/start): inicia o serviço. Retorna "true" quando o modo "pull" está ativado e o serviço foi iniciado com sucesso; e "disabled" quando o modo "pull" estiver desabilitado.
• Stop (GET /fluig-pull/service/stop): interrompe o serviço. Retorna "true" quando encerrado com sucesso e "false" caso não seja possível encerrar o serviço.
• Status (GET /fluig-pull/service/status): retorna o status do serviço. Valores possíveis de retorno são "alive", quando o serviço estiver em execução; "stopped", quando estiver parado; e "disabled" quando o modo "pull" estiver desabilitado.

A classe FluigPuller, que implementa o serviço de busca de operações, utilizará o REST client, versão 1.5.0, disponibilizado pela equipe do Identity, para consumir os serviços REST necessários para verificação e consumo das filas de operação.

A classe que implementa o REST client é com.totvslabs.idm.rest.client.FluigIdentityRestClient. Os métodos que serão utilizados estão listados abaixo:

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

Opcional

Protótipo de Tela

Fluig Configurator

Image Removed

Figura X - Novo campo - Modo Pull

Opcional

Fluxo do Processo 

Image Removed

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

Image Removed

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

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

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

Image Added

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

Image Added

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

Fluxo do Processo 

Image Added

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

Image Added

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

Image Added

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

Image Added

Figura 6 - Fluxo da busca sob demanda.

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.