...

...

Objetivo

O objetivo deste guia é habilitar e configurar o console EAI para a utilização nas integrações com TOTVS Vitae e TOTVS Educacional.

Visão Geral

A TOTVS estabeleceu um conjunto de técnicas e padrões para a integração dos seus produtos que ficou conhecido como “Mensagem Única TOTVS”. Este conjunto de definições estabelece como os produtos TOTVS devem se comunicar e engloba questões como:

• Como definir uma mensagem de integração
• Como as mensagens são identificadas
• Como é feita a troca de mensagens
• Como as mensagens são rastreadas

Objetivo

O objetivo deste guia é habilitar e configurar o console EAI para a utilização nas integrações com TOTVS Vitae, TOTVS Educacional e TOTVS RH (Linha Datasul).

Visão Geral

Existe um conjunto de técnicas e padrões para a integração de ERPs TOTVS, conhecida como “Mensagem Única TOTVS”. Este conjunto de definições estabelece como os produtos TOTVS devem se comunicar e engloba questões como:

• Como definir uma mensagem de integração;
• Como as mensagens são identificadas;
• Como é feita a troca de mensagens;
• Como as mensagens são rastreadas.

O componente EAI 2.0 (Java), do produto Datasul encapsula estas definições e permite que os produtos possam se integrar no novo modelo com um esforço menor para O componente EAI 2.0 (Java), fornecido pela equipe de Framework do Produto Datasul encapsula estas definições e permite que os produtos possam se integrar no novo modelo com um esforço menor para a sua incorporação. Ele define um conjunto de interfaces que devem ser implementadas pelo produto hospedeiro (host application) que tratam, basicamente, da persistência das informações que circulam pelo EAI em banco de dados. Além disso, o EAI também espera que o aplicativo hospedeiro disponibilize um web service que será a porta de entrada para as mensagens enviadas pelos outros aplicativos.

Em contrapartida, o EAI 2.0 fornece toda a lógica de identificação, processamento e rastreabilidade de mensagens além de uma interface web para o gerenciamento da instância.

EAI vs Arquitetura Multi-Tenant

Um ponto relevante para a incorporação do EAI 2.0 no fluig é a sua característica de Multi-Tenant. Esta arquitetura permite que várias tenants utilizem a mesma instalação do produto de forma independente e transparente, gerando a percepção de que cada um possui uma instância própria do produto.

Isto significa que, do ponto de vista de integração, cada Empresa também deve ser independente e possuir um conjunto próprio de integrações, mensagens, etc. Do ponto de vista lógico, cada empresa teria a sua “instância” do EAI para integração mas, do ponto de vista físico, uma única instância do (componente EAI) deverá gerenciar as integrações de cada uma das empresas individualmente.

Sempre que uma mensagem é recebida no fluig, ela deve vir com a autenticação de um usuário da empresa e a partir dessa autenticação o fluig realiza o login do usuário e sabe a qual empresa a mensagem foi direcionada.

EAI Console

O EAI Console é a ferramenta, fornecida pelo EAI 2.0, que permite gerenciar todos os aspectos relativos à gestão da integração, desde a configuração da instância do EAI, a ativação de mensagens, o cadastro de aplicativos externos e a consulta de mensagens enviadas/recebidas.

O acesso ao EAI Console é restrito ao administrador da empresa e pode ser feito através da aba Aprendizado no Painel de Controle.

Recebimento de mensagem

Quando um aplicativo externo envia uma mensagem a um aplicativo hospedeiro do EAI ele deverá informar um usuário e senha que deverá ser validado contra os usuários cadastrados no fluig. Para que o e-Learning permita que este usuário receba esta mensagem ele deverá ter um papel específico configurado no produto (Recurso "LMSEAI - Aprendizado - EAI" permissão "Receber"). Isto torna flexível o modelo de autenticação uma vez que o cliente poderá utilizar o usuário administrador (que possui todas as roles, inclusive para recebimento de mensagens), criar um usuário específico para integrações (usuário eai, por exemplo) ou, ainda, criar usuários específicos para cada produto integrado.

Vale lembrar que além do papel específico para o recebimento de mensagens, o usuário utilizado também deverá ter papéis que o habilitam a efetuar a transação que a mensagem pretende fazer. Por exemplo, para que a mensagem de inclusão de usuário seja processada com sucesso, o usuário utilizado deverá ter o papel de recebimento de mensagens (EAI_RECEIVE_MESSAGES) e para salvar usuários (ADMINISTRATIVE_USER_SAVE).

NTLM

O NTLM é um protocolo de autenticação utilizado em uma rede Windows. Como veremos nos tópicos a seguir, existem uma série de configurações que devemos realizar nos browsers para que eles utilizem este protocolo, e também no script de autenticação remota para que utilize a chamada Autenticação Windows.

Além disso, é importante lembrar que existem limitações com relação a sistemas operacionais não Windows. Linux e Mac não podem utilizar o protocolo NTLM. O efeito nestes sistemas operacionais é que se tentarem o acesso via autenticação integrada, uma caixa de diálogo proveniente do browser pedirá para que o usuário informe suas credenciais.

Configuração da Autenticação Integrada

Para usufruir da autenticação integrada com o Windows, é necessário habilitar este recurso no Fluig e realizar algumas configurações, como a criação do serviço de autenticação remota. As configurações necessárias para o correto funcionamento da autenticação integrada são apresentadas nos tópicos abaixo.

Habilitando e Configurando no Fluig

O primeiro passo para a configuração da autenticação integrada é habilitá-la no Fluig:

...

...

• Insira a URL do servidor IIS onde será executado o script de autenticação remota no campo URL script de autenticação. A URL deve apontar por padrão para http(s)://<endereço-iis>/remote_auth.asp (A configuração do servidor IIS e da URL para acesso será descrito no tópico Configuração IIS).

Image Removed

Configuração IIS

Para disponibilizar o serviço de autenticação remota é necessário ter um servidor Windows com o Internet Information Services (IIS) habilitado. Siga o passo-a-passo abaixo para habilitar o IIS:

Configuração e Disponibilização do Serviço

Após possuir o IIS instalado e com as funções de serviços necessárias é possível configurar o serviço de autenticação remota. Lembrando que o apoio da equipe de infraestrutura é fundamental, siga o passo-a-passo abaixo para configurar e disponibilizar o serviço de autenticação remota:

...

<!DOCTYPE html>
<html> 
  <head>           
    <meta http-equiv="refresh" content="0;URL='http://{FLUIG-HOST}/portal/home?dssoError=invalidUser'" />    
  </head>
</html>

...

• Outro ponto a ser configurado é autenticação deste site. Realizamos isto através do item Autenticação.

Image Removed

...

• Existe um detalhe que deve ser tratado na autenticação, que são os provedores utilizados pela Autenticação do Windows. Clique com o botão direito na opção Autenticação do Windows e em seguida clicar na opção Provedores.

Image Removed

...

• Devemos deixar apenas a opção NTLM. Todas as outras devem ser excluídas. Se isso não for feito, pode ser exigido do usuário a entrada de credenciais via caixa de diálogo do navegador. Não esquecer que existe outra configuração a ser feita diretamente no navegador (que veremos em tópicos posteriores) para evitar este problema.

Image Removed

Configuração do Browser

É necessário configurar o browser do usuário para que ele utilize autenticação Windows (NTLM) com o script de autenticação remota (remote_auth.asp).

Mesmo que o serviço de autenticação remota tenha sido configurado para utilizar autenticação Windows no IIS, o browser do cliente precisa enviar as credenciais para que o script possa fazer as validações necessárias no Active Directory.

Internet Explorer e Google Chrome

No caso dos navegadores Internet Explorer e Google Chrome, as configurações de segurança e autenticação devem ser realizadas através das Opções da Internet do Internet Explorer, pois os dois navegadores irão assumir estas configurações realizadas.

...

Definição de mensagem única TotvsMessage

Durante o processo de consolidação de marcas, iniciado pela TOTVS, várias empresas diferentes foram adquiridas e com elas vários produtos passaram a compor o portfólio de ofertas disponível aos clientes. Esta expansão de ofertas permitiu que clientes de uma marca, antes limitados pelas opções com aquela “etiqueta”, pudesse agora compor o seu ambiente de TI utilizando produtos de origens diferentes (Ex.: TOTVS Educacional + TOTVS Fluig Plataforma, TOTVS RH (Linha Datasul) + TOTVS Fluig Plataforma).

Esta mesma iniciativa já era uma prática comum nos clientes, porém todo o custo envolvido na integração entre estes aplicativos era visto pelo cliente como parte da escolha de utilizar-se de produtos de diferentes fornecedores. Uma vez que estes produtos passam a fazer parte de uma mesma oferta, os clientes TOTVS passam a demandar que estes produtos sejam naturalmente integrados. Isto significa que se antes o cliente arcava com o custo e o risco envolvido em uma integração, ele agora entende que a TOTVS deve prover soluções já integradas, independente da origem dos produtos oferecidos.

Com o objetivo de padronizar a integrações com os produtos TOTVS, foi definida uma nova diretriz para os projetos de integração: A de que todos os produtos TOTVS devam trabalhar com uma mensagem XML únicos evitando, desta forma, o processo de transformação de mensagens. Neste cenário, teríamos o seguinte quadro:

Image Added

Neste cenário, qualquer produto TOTVS trabalhará com o mesmo XML para uma mesma entidade, ou seja, supondo que tenhamos um XML correspondente à mensagem de CLIENTES, ela poderá ser enviada para qualquer um dos produtos que suporte o recebimento desta entidade.

Uma vez que os vários produtos TOTVS terão um “idioma” comum (o XML Único), as integrações entre estes produtos não exigirão mais que as mensagens sejam transformadas de um formato para outro. Com isto, será possível conectar diretamente dois produtos, como no diagrama abaixo:

Image Added

Além de questões referentes ao formato das mensagens, a mensagem única também torna uniforme o tratamento destas mensagens XML pelos aplicativos, principalmente no que diz respeito à capacidade de rastreamento.

Todos os processos devem respeitar o fluxo normal de troca de mensagens no padrão de Mensagem Única TOTVS. O fluxo de mensagens poderá ocorrer nos seguintes sentidos:

• TOTVS Fluig Plataforma à Educacional: a plataforma TOTVS Fluig irá consumir o webservice da linha RM para recebimento de mensagens únicas. O mesmo também será responsável por encaminhar as mensagens para o EAI RM, que processará a mesma (englobando todas as especificidades requeridas) e encaminhará o retorno de acordo com o tipo de comunicação definida (síncrona ou assíncrona).
  
  
• Educacional à TOTVS Fluig Plataforma: os dados serão trafegados pelo fluxo normal até a fila de Integração TBC, onde o mesmo irá consumir o webservice do EAI da plataforma TOTVS Fluig para envio da(s) mensagem(s). Após a resposta da plataforma, o RM atualizará o registro com o status de processamento e demais dados, no Monitor da Fila de Mensagem Única.
  
  
• TOTVS Fluig Plataforma à TOTVS RH (Linha Datasul): a plataforma TOTVS Fluig irá consumir o webservice do TOTVS RH (Linha Datasul) para recebimento de mensagens únicas. Ele também será responsável por encaminhar as mensagens para o EAI TOTVS RH (Linha Datasul), que as processará (englobando todas as especificidades requeridas) e encaminhará o retorno de acordo com o tipo de comunicação definida (síncrona ou assíncrona).
  
  

Assim como definido no protocolo de comunicação de mensagens únicas, a comunicação pode ser efetuada de duas formas:

• Síncrona: O sistema de origem gera uma mensagem de integração na sua fila e envia ao webservice de destino. O processo na origem aguarda o processamento da mensagem no destino e ao receber o retorno atualiza o status do processamento na fila de integração. (Mensagens síncronas não podem ser processadas/reprocessadas no monitor da fila de integração.)

• Assíncrona: O sistema de origem gera uma mensagem de integração na sua fila, envia ao webservice de destino e aguarda somente a confirmação de recebimento da mensagem. O processo na origem não fica parado aguardando o processamento da mensagem no destino.
  
  

Ao término do processamento da mensagem por parte do sistema de destino o mesmo envia outra mensagem de retorno ao sistema de origem com o status do processamento.

As mensagens assíncronas podem ser processadas (status pendente) ou reprocessadas (status erro) manualmente através do monitor da fila de integração.

Nota: Cada linha irá programar a fila de integração a sua maneira, respeitando o protocolo definido para mensagem padrão e guardando o log de processamento de todas as mensagens recebidas ou enviadas.

EAI vs Arquitetura multi-empresa

Um ponto relevante para a incorporação do EAI 2.0 na plataforma TOTVS Fluig é a sua característica de multi-empresa. Esta arquitetura permite que várias empresas utilizem a mesma instalação do produto de forma independente e transparente, gerando a percepção de que cada um possui uma instância própria do produto.

Isto significa que, do ponto de vista de integração, cada Empresa também deve ser independente e possuir um conjunto próprio de integrações, mensagens, etc. Do ponto de vista lógico, cada empresa teria a sua “instância” do EAI para integração mas, do ponto de vista físico, uma única instância do (componente EAI) deverá gerenciar as integrações de cada uma das empresas individualmente.

Sempre que uma mensagem é recebida na plataforma TOTVS Fluig, ela deve vir com a autenticação de um usuário da empresa e, a partir dessa autenticação, a plataforma realiza o login do usuário e sabe a qual empresa a mensagem foi direcionada.

EAI Console

O EAI Console é a ferramenta, fornecida pelo EAI 2.0, que permite gerenciar todos os aspectos relativos à gestão da integração, desde a configuração da instância do EAI, a ativação de mensagens, o cadastro de aplicativos externos e a consulta de mensagens enviadas/recebidas.

O acesso ao EAI Console é restrito ao administrador da empresa e pode ser feito a partir de Aprendizado → Administrar → Console EAI.

Recebimento de mensagem

Quando um aplicativo externo envia uma mensagem a um aplicativo hospedeiro do EAI ele deverá informar um usuário e senha que deverá ser validado contra os usuários cadastrados na plataforma TOTVS Fluig. Para que o e-learning permita que este usuário receba esta mensagem ele deverá ter um papel específico configurado no produto (Recurso "LMSEAI - Aprendizado - EAI" permissão "Acessar"). Isto torna flexível o modelo de autenticação uma vez que o cliente poderá utilizar o usuário administrador (que possui todas as roles, inclusive para recebimento de mensagens), criar um usuário específico para integrações (usuário eai, por exemplo) ou, ainda, criar usuários específicos para cada produto integrado.

Vale lembrar que além da permissão específica para o recebimento de mensagens, o usuário utilizado também deverá ter permissões que o habilitam a efetuar a transação que a mensagem pretende fazer. Por exemplo, para que a mensagem de criação de matrícula na turma seja processada com sucesso, o usuário utilizado deverá ter permissão para realizar matrícula na turma, ou seja, permissão de execução na turma.

Configuração do Console EAI

Carga inicial de treinamentos do TOTVS Fluig Plataforma ao TOTVS RH (Linha Datasul)

Integração na inclusão de dados

Todos os registros da plataforma TOTVS Fluig criados através da integração com sistemas externos ficam ligados aos registros externos.

Exemplo:

• Quando o RM Vitae envia um usuário para o TOTVS Fluig Plataforma através da integração, esse usuário fica ligado ao registro no RM Vitae. Quando houver uma alteração nesse usuário no RM Vitae, essa alteração será replicada no TOTVS Fluig Plataforma.
  Se o usuário é inativado no RM Vitae ele será inativado no TOTVS Fluig Plataforma também.
  
  
• Quando o RM Educacional envia uma turma para a plataforma TOTVS Fluig através da integração, essa turma fica ligada ao registro no RM Educacional. Quando houver uma alteração nessa turma no RM Educacional, essa alteração será replicada na plataforma TOTVS Fluig.
  Se a turma se chamava "Matemática" e passa a se chamar "Matemática - Noturno" no RM Educacional esta alteração também ocorrerá na plataforma.
  
  
• Quando o RM Educacional envia uma matrícula em uma turma para a plataforma TOTVS Fluig através da integração, essa matrícula fica vinculada ao registro no RM Educacional. A matrícula só poderá ser finalizada no RM Educacional e quando isso acontecer, uma nova mensagem é enviada para a plataforma para que a matrícula seja finalizada nela também.
  Da mesma forma, se a matrícula for cancelada ou bloqueada no RM Educacional a matrícula da plataforma também será cancelada/bloqueada.
  
  
• Quando o RM Vitae envia uma matrícula em uma trilha/treinamento para plataforma TOTVS Fluig através da integração, essa matrícula fica vinculada ao registro no RM Vitae. A matrícula só poderá ser finalizada no RM Vitae e quando isso acontecer, uma nova mensagem é enviada para a plataforma para que a matrícula seja finalizada nela também. Da mesma forma, se a matrícula for cancelada ou bloqueada no RM Vitae a matrícula da plataforma também será cancelada/bloqueada.
  
  
• As requisições de matrículas nos treinamentos podem ser solicitadas pelos usuários na plataforma TOTVS Fluig desde que eles possuam permissão de Matricular em Treinamentos/Trilhas e de Executar no item trilha ou treinamento). Ao solicitar a matrícula de um treinamento na plataforma, a matrícula não é feita automaticamente, e sim enviada para o TOTVS RH (Linha Datasul) e então a plataforma aguarda uma mensagem de matrícula do usuário no TOTVS RH (Linha Datasul). A matrícula só poderá ser finalizada no TOTVS RH (Linha Datasul) e, quando isso acontecer, uma nova mensagem é enviada para a plataforma para que a matrícula seja finalizada nela também. Da mesma forma, se a matrícula for cancelada ou bloqueada no TOTVS RH (Linha Datasul), a matrícula da plataforma também será cancelada/bloqueada.
  
  
• Quando o TOTVS Fluig Plataforma envia um treinamento para o TOTVS RH (Linha Datasul) através da integração, esse treinamento fica ligado ao registro TOTVS RH (Linha Datasul). Quando houver uma alteração nesse treinamento na plataforma, a alteração será replicada no TOTVS RH (Linha Datasul). Os treinamentos não podem ser cadastrados nem editados no TOTVS RH (Linha Datasul). As trilhas não são integradas.
  
  

Essa condição acontece com todos os registros integrados.

Exemplo: Usuários, Disciplinas, Turmas, Complementos de Disciplina, Treinamentos, Requisição de Matrículas, Matrículas em Turmas, Matrículas em Treinamentos, etc.

Na mensagem de integração de usuários é permitido o envio de uma lista de papéis e outra lista de grupos. Quando o usuário estiver sendo criado na plataforma TOTVS Fluig, esses papéis e grupos são listados e os papéis/grupos que não existem na plataforma são criados e associados ao usuário. Os papéis e grupos já existentes na plataforma serão apenas associados ao usuário não havendo nenhum tipo de atualização dos mesmo.

Caso seja uma atualização de usuários e na mensagem conste papéis ou grupos não existentes na plataforma TOTVS Fluig, os mesmos serão ignorados, sendo associados ao usuário apenas os existentes na plataforma. O processo de atualização não cria nem grupos e nem papéis.

...

...

Image Removed

...

...

Image Removed

...

• Para adicionar o endereço do servidor de autenticação remota precisamos clicar no botão Avançadas:

Image Removed

• Informamos a URL do servidor de autenticação remota no campo Adicionar este site à zona e então clicamos no botão Adicionar. Podemos fechar a tela clicando no botão Fechar:

Image Removed

...

...

Image Removed

Mozilla Firefox

O Firefox deve ser configurado de uma maneira um pouco diferente:

...

...

• Em primeiro lugar, precisamos digitar about:config na barra de endereços, para poder acessar as configurações do Firefox:

Image Removed

• Uma mensagem de alerta normalmente é exibida. Para continuar, basta clicar no botão de confirmação. No nosso exemplo, o botão Serei cuidadoso, prometo!
  

Group Policies

Configurar o browser de alguns poucos usuários é uma tarefa simples, porém, o cliente terá um problemas quando tem milhares de usuários a serem configurados.

Para estes casos, podemos utilizar a estratégia de distribuição das configurações, baseadas na utilização de Group Policies (GPO). Durante o procedimento de autenticação no domínio, pode ser executada uma série de tarefas automáticas, como por exemplo, configurar o navegador do usuário.

Internet Explorer e Google Chrome

O administrador deverá definir a seguinte configuração de GPO:

Configuração do Computador ► Modelos Administrativos ► Componentes do Windows ► Internet Explorer ► Painel de Controle da Internet ► Página Segurança:

Image Removed

Após habilitar a Lista de Atribuições de Sites a Zonas, o cliente deverá definir a URL do servidor de autenticação remota como membro da Zona da Intranet.

Image Removed

Desta forma, toda vez que um usuário membro do domínio efetuar o login, as configurações necessárias serão realizadas. Se executada todos os dias, a GPO também deve evitar que um usuário mais avançado desfaça as configurações necessárias para a autenticação remota.

Mozilla Firefox

No caso do navegador Mozilla Firefox, não existe maneira direta de configurar o navegador a partir da GPO, porém, existem scripts que realizam esta configuração, e estes scripts podem ser executados a partir de uma GPO.

Existe um script que foi criado para definir estas configurações do Firefox. Ele pode ser obtido com a equipe de serviços do Fluig.

Para executar o script devemos configurar a GPO conforme apresentado abaixo:

Configuração do Usuário ► Configurações do Windows ► Scripts (Logon/Logoff) ► Logon

Image Removed

Opções de arquitetura para Alta Disponibilidade

A autenticação remota pode utilizar uma arquitetura baseada em um único servidor. O problema é que neste cenário, se o script estiver off-line, o usuário não conseguirá autenticar no Fluig. O administrador deverá desabilitar a autenticação integrada no Fluig ou corrigir o que for necessário para que o script fique online.

Existe uma opção onde podemos criar dois servidores de autenticação remota, o que fornece uma boa redundância do componente. Se um servidor estiver fora do ar, ou se uma aplicação estiver fora, o outro servidor assume a responsabilidade de manter online o serviço de autenticação remota.

Para isso é necessário disponibilizar um Load Balancer que terá a responsabilidade de fazer o redirecionamento, caso um dos dois servidores de autenticação remota esteja off-line.

...