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

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

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

Figura X - Novo campo - Modo Pull

Opcional

Fluxo do Processo 

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

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

(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>.