Histórico da Página

Informações Gerais

Objetivo

Esse documento tem como objetivo propor algumas mudanças no EAI

Objetivo

Essa melhoria no EAI será criada com o intuito de viabilizar a transferência dos códigos fontes c# (extensions) das integrações atuais (localizados na tabela GsourceCode) para projetos localizados nas solutions dos produtos RM.Com  Com essa mudança esses fontes passarão a ser controlados pelo TFS, alcançando ganhos de segurança, controle de históricos, controle de concorrência, etc.

Esse modelo permitirá também que o usuário final (cliente da integração) implemente diversas customizações após execução dos métodos de adapters.

Definição da Regra de Negócio

1) - Modelo atual

Características:

• O EAI comunica diretamente com extensions (códigos fontes c# responsáveis pela manipulação da mensagem);
  
  
• Diferentes extensions podem ser ligados a uma única mensagem no processo de configuração de integração. Para isso, basta criar um mapeamento entre a integração x mensagem, conforme figura 1;
  
  
• Extensions são desenvolvidos e mantidos pelas equipes dos produtos (segmentos).
  
  
• Extensions podem ser modificados nos clientes em ambiente de teste e produção, visto que os mesmos são abertos para alteração.
  
  
• É utilizado um editor de código fonte c# para escrita e compilação conforme a figura 2. 
  
  
• Esses fontes são armazenados no banco de dados na tabela "GSourceCode".
  
  

Vantagens:

a) - Flexibilidade no processo de customização;

Desvantagens:

a) - Possibilita a duplicação de fontes para manipulação de uma mesma mensagem;

b) - Modificações realizadas no fonte para uma determinada integração podem não ser replicadas para outras integrações;

c)- No recebimento de uma determinada mensagem, se existir mais de uma integração cadastrada, o EAI seleciona a primeira integração e executa o código fonte correspondente a essa "integração / mensagem".

d) - Ao executar novamente o configurador em ambiente do cliente, os extensions alterados serão substituídos pela versão atual;

e) - Dificuldade na detecção e análise de erros desses códigos visto que o Editor c# do EAI não oferece suporte para debugger.

2) - Modelo proposto

a) Adapters Adapter (Segmentos Totvs)

• Estrutura a ser utilizada para implementação de regras específicas para manipulação de uma mensagem de integração.
  
  
• O EAI comunicará diretamente com os adapters (de responsabilidade das equipes de segmentos);
  
  
• Uma "mensagem / versão" estará ligada a um único adapter;
  
  
• Regras específicas da mensagem em uma determinada integração devem ser tratadas diretamente no adapter.
  
  
• Devem ser mantidos pelas equipes dos produtos (segmentos).
  
  
• Não poderão ser modificados pelos clientes pois o código será compilado dentro de dlls nativas dos produtos;
  
  
• Estarão localizados na mesma estrutura das solutions dos segmentos no TFS;
  
  
  

b) - Extensions (customizações)

• Estrutura utilizada para implementação de regras customizadas para um cliente em específico;
  
  
• O Editor de código do EAI deve ser usado pelos clientes para implementação de customizações nos adapters dos produtos;
  
  

• Esses códigos (extensions) devem ser implementados no contexto da integração em questão. 
  Sendo assim, o cadastro de "Mapa de integração - HCMapaIntegracao" será usado para gravação das regras customizadas a serem implementadas no cliente (customização de integração).
  
  
• Os entryPoints das customizações serão disparados imediatamente após a execução do método (de mesmo nome e interface) do adapter;
  
  
• Esses recurso permitirá que alterações possam ser feitas nos objetos logo após a execução do código do adapter;

Detalhamento técnico

1) - Localização atual dos códigos fontes

Atualmente, os códigos fontes das integrações estão localizados no projeto "RM.Con.ConfiguraIntegracao.TotvsMessage" da solution "Con-EAI" da framework.

Nas pastas "Oracle" e "SQL" (localizadas nesse projeto) foram criados arquivos contendo scripts para vinculação e inclusão desse códigos nas tabelas "GSourceCode", "HCTransformacao" e "HCMapaIntegracao".

Esses scripts são executados automaticamente durante o processo de configuração da integração.

2) - Transferência dos fontes

                  a) Os scripts abaixo que incluem dados na tabela "GSourceCode"devem ser removidos desses arquivos e transferidos para os projetos nas solutions dos nas solutions dos produtos.

                   Scripts utilizados:

                    Oracle:

• • 04.1_SOURCECODE.sql, 
  • 04.2_SOURCECODE_FinancialNature.sql, 
  • 0401_SOURCECODE_ORDER.sq               

                    Sql:

• • 04.1_SOURCECODE.sql, 
  • 04.2_SOURCECODE_FinancialNature.sql, 
  • 0401_SOURCECODE_ORDER.sql;

                b) - Os scripts abaixo que vinculam esses fontes nas tabelas "HCTransformação e HCMapaIntegracao" através dos respectivos campos "IDSRCCUSTOMHANDLE" e "EXTENSION" devem ser alterados. 

                        Nesse caso, deve ser gravada uma string vazia nesses campos.

                  Scripts utilizados:

                    Oracle:

• • 02_HCTRANSFORMACAO.sql;              

                    Sql:

• • 02_HCTRANSFORMACAO.sql;
    
    
    

Em versões futuras, esses arquivos serão removidos do projeto "RM.Con.ConfiguraIntegracao.TotvsMessage".

3) - Criação dos projetos

As equipes dos produtos deverão criar projetos nas suas solutions contendo classes a serem executadas automaticamente durante o processamento da mensagem.

Passo a passo para criação desses projetos:

a) - No visual Studio, abra a solution correspondente ao determinado segmento. ex. Financeiro.sln.

b) - Crie um novo projeto na solution do tipo "Class Library";

c) - No arquivo AssemblyInfo.cs, utilize o atributo conforme exemplo: [assembly: AssemblyLayerSide(LayerSideKind.Server)];   

d) - Adicione referências para as dll's  "RM.Con.TotvsMessage.Extension", "RM.Con.TotvsMessage.IServices", "RM.Con.TotvsMessage.Services";

e) - O projeto recém criado deverá seguir o seguinte padrão de nomenclatura:

       RM.{Segmento}.TotvsMessage.Adapter.dll,        onde:  Segmento = Sigla do segmento
               ex:  RM.Fin.TotvsMessage.Adapter.dll.     

4) - Criação das classes

Os códigos localizados na tabela GSourceCode deverão ser transferidos para classes localizadas no projeto recém criado. A criação dessas classes deverá seguir um modelo conforme abaixo:

Códigos que estendem as rotinas de processamento (Extensão de códigos):

       a) - Criar uma classe com um nome qualquer (o ideal seria colocar o nome da mensagem seguido pela versão da mensagem);

               ex: public class CostCenter_1_000 : ....

       b) -  Herdar da classe "AdapterBase" sobrescrevendo os métodos necessários a serem utilizados;

          ex: public class CostCenter_1_000: AdapterBase

        c) - Usar o atributo de classe "AdapterAttr":

          Esse atributo irá "carimbar" a classe com informações de metadados do adapter. 

          No exemplo abaixo, o adapter somente será carregado no recebimento de uma mensagem COSTCENTER 2.000.

          ex: 

               [AdapterAttr(TransactionType.ttMensageriaUnica, AdapterType.atReceive, "COSTCENTER", "2.000")] 
               public class CostCenter_2_000: AdapterBase

        d) - Após a criação dessa classe, basta copiar e colar o código fonte (c#) localizado nos scripts, substituindo os nomes dos métodos e usando a palavra "override" no início do mesmo:

   a) - Criar uma classe com um nome qualquer (o ideal seria colocar o nome da mensagem seguido pela versão da mensagem);

               ex: public class Whois_1_000: ....

       b) -  Herdar da classe "ReceiveMessageHandle"

          ex: public class Whois_1_000: ReceiveMessageHandle

        c) - Usar o atributo de classe "AdapterAttr":

          ex: 

               [AdapterAttr(TransactionType.ttMensageriaUnica, AdapterType.atReceive, "Whois", "1.000")] 
               public class Whois_1_000: ReceiveMessageHandle

        d) - Após a criação dessa classe, basta copiar e colar o código fonte (c#) localizado nos scripts, conforme fig abaixo:

       Modelagem de classes.

               a) - CustomBase - classe ancestral usada para definir métodos e propriedades genérico para as classes concretas para manipulação das mensagens;

                b) - AdapterBase - classe ancestral usada para definir regras comuns para todos os adapters;

                c) - ExtensionBase - classe ancestral usada para definir regras comuns para todos os extensions (estruturas a serem usadas para inclusão de códigos customizados pelos clientes).

Protótipos de Tela

Figura1 - Mapeamento mensagem x integração

figura2: Editor de  código fonte do EAI

figura 3: Adapter de recebimento