Histórico da Página
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|
Informações Gerais
Especificação | |||
Produto | RM | Módulo: Integração (EAI) |
|
Segmento Executor | Framework | ||
Projeto1 | R_FRW004 | IRM1 : PCREC-9634 |
|
Requisito1 | PCREC-9644 | Subtarefa1: PDR_FRW_FRW002-22 |
|
Chamado2 |
| ||
País | ( ) Brasil ( ) Argentina ( ) Mexico ( ) Chile ( ) Paraguai ( ) Equador ( ) USA ( ) Colombia ( ) Outro _____________. | ||
Outros | <Caso necessário informe outras referências que sejam pertinentes a esta especificação. Exemplo: links de outros documentos ou subtarefas relacionadas>. |
Objetivo
Permitir que o usuário final (cliente da integração) customize um adapter e não a mensagem.
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);
- Uma única mensagem pode ser ligada a diferentes extensions no processo de configuração de integrações. 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) - Permite 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
Adapters: estrutura 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;
- Estarão localizados na mesma estrutura das solutions dos segmentos no TFS;
- As extensions das integrações atuais devem ser migradas para essas classes de adapter de acordo com o documento localizado em:
http://tdn.totvs.com/display/LRM/DT_CENTRALIZAR_OS_CODIGOS_DE_INTEGRACAO
b) - Extensions: estrutura utilizada para implementação das regras customizadas em um determinado cliente
- 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" 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;
2.1) - Exemplos de implementação do novo modelo.
Manipulação da mensagem COSTCENTER.
a) Criação do adapter.
- As regras de negócio escritas atualmente no extension para manipulação da mensagem COSTCENTER devem ser repassadas para classes que herdam de AdapterBase.
- O EAI, no processo de execução da mensagem de COSTCENTER, chamará esse adapter em vários momentos.
- Conforme exemplo abaixo, o método DoAfterTransformDataSet será chamado no momento da transformação da mensagem única para o formato nativo do centro de custo.
a) Criação do extension.
- O recurso de extension pode ser usado para inclusão de códigos customizados no ambiente do cliente;
- Após execução do método DoAfterTransformDataSet" localizado no adapter acima, o método "AfterTransformDataSet" localizado abaixo no extension será chamado.
- Esse mecanismo possibilitará a implementação de códigos customizados a serem disparados imediatamente após a execução do adapter.
2.2) - 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).
Opcional
Protótipo de Tela
Figura1 - Mapeamento mensagem x integração
figura2: Editor de código fonte do EAI
(Opcional)
Grupo de Perguntas
<Informações utilizadas na linha Protheus>.
Nome: FINSRF2
X1_ORDEM | 01 |
X1_PERGUNT | Emissão De |
X1_TIPO | D |
X1_TAMANHO | 8 |
X1_GSC | G |
X1_VAR01 | MV_PAR01 |
X1_DEF01 | Comum |
X1_CNT01 | '01/01/08' |
X1_HELP | Data inicial do intervalo de emissões das guias de DARF a serem consideradas na seleção dos dados para o relatório |
(Opcional)
Consulta Padrão
<Informações utilizadas na linha Protheus>
Consulta: AMB
Descrição | Configurações de Planejamento |
Tipo | Consulta Padrão |
Tabela | “AMB” |
Índice | “Código” |
Campo | “Código”; ”Descrição” |
Retorno | AMB->AMB_CODIGO |
Este documento é material de especificação dos requisitos de inovação, trata-se de conteúdo extremamente técnico. |
---|