Determinação de Dados em Formulários Fiori

1. Objetivo

Esta funcionalidade permite implementar uma lógica de "Determinação de Dados" em formulários SAP Fiori desenvolvidos na plataforma Tachyonix.io. O objetivo é preencher automaticamente campos de um formulário com base no valor de outro campo, executando uma lógica ABAP no backend em tempo real, sem a necessidade de um refresh completo da tela.

2. Pré-requisitos

• Aplicação de Formulário Tachyonix: É necessário possuir uma aplicação de formulário criada na aula 010, com campos configurados para entrada de dados.
• INCLUDE ABAP: Um INCLUDE ABAP customizado, como Y0DETERMINACAO_PO, deve ser criado no ambiente ABAP para conter a lógica de determinação.
• Autorizações SAP: Acesso à transação SE38 para criação e edição de INCLUDEs ABAP.

3. Passo a Passo Detalhado

3.1. Configuração da Determinação na Plataforma Tachyonix

Acessar Aplicação e Campo: Abra a aplicação de formulário desejada (ex: "Criar Pedidos de Compra - PO - aula010") no editor da plataforma Tachyonix.io.

Selecionar Campo Gatilho: Na estrutura da aplicação, navegue até a tabela de itens e selecione o campo que atuará como gatilho para a determinação (ex: EKPO-WERKS, "Centro").

Ativar Comportamento de Determinação: Nas propriedades do campo selecionado, acesse a aba "Comportamentos".

Habilitar "Determinável": Marque a opção "Determinável". Esta ação configura a plataforma para invocar uma lógica de backend quando o valor deste campo for alterado pelo usuário.

Associar INCLUDE ABAP: Na seção "Atividades" -> "Chamada", selecione o tipo "Include" e informe o nome do INCLUDE ABAP que conterá a lógica customizada (ex: Y0DETERMINACAO_PO).

3.2. Implementação da Lógica de Determinação em ABAP

Acessar o INCLUDE ABAP: No ambiente de desenvolvimento ABAP (transação SE38), abra o INCLUDE especificado na etapa anterior (ex: Y0DETERMINACAO_PO).

Implementar a Lógica: Dentro do INCLUDE, insira o código ABAP que definirá a regra de determinação. Este INCLUDE é chamado por um método padrão da plataforma (PROCESS_VALIDATE_DETERMINATE) que fornece os dados da tela através de parâmetros.

Verificar Campo Gatilho: A lógica deve verificar se o campo que disparou a ação (field_name) corresponde ao campo configurado como gatilho (ex: 'WERKS').

Acessar e Modificar Dados da Linha: Os dados da linha atual da tabela são acessíveis e modificáveis através de um field symbol (ex: cfs_det2).

Exemplo de Regra de Negócio

Implemente a lógica específica. Por exemplo, se o valor do centro (cfs_det2-werks) for '1720', atribua o valor '172A' ao campo de depósito (cfs_det2-lgort).

IF field_name = 'WERKS' AND cfs_det2-matnr IS NOT INITIAL AND cfs_det2-werks IS NOT INITIAL.
  IF cfs_det2-werks = '1720'.
    cfs_det2-lgort = '172A'.
  ENDIF.
ENDIF.

3.3. Demonstração e Debug

Construir e Executar: Construa a aplicação Fiori na plataforma Tachyonix e abra-a no navegador.

Testar a Determinação: No formulário, adicione um item ao pedido. Preencha o campo "Material" e, em seguida, selecione o centro '1720' no campo configurado como gatilho.

Resultado Esperado: Ao sair do campo "Centro", o campo "Depósito" deve ser automaticamente preenchido com o valor '172A', conforme a lógica implementada.

Utilizar o Debugger ABAP: Para depurar a lógica, defina um breakpoint no INCLUDE Y0DETERMINACAO_PO ou no método IF_TCH_PROCESS_VALID_DETERM~PROCESS_VALIDATE_DETERMINATE da classe ABAP gerada pela plataforma (ex: ZCLDT0488443005).

Inspeção de Variáveis: No debugger, inspecione a estrutura ACTION_DATA para visualizar todos os dados da tela e o field symbol cfs_det2 para confirmar que a atribuição de valor está ocorrendo corretamente no backend antes de ser refletida na UI.

4. Verificação e Teste

Para verificar a implementação, execute a aplicação Fiori no navegador. Crie um novo registro ou edite um existente. Ao preencher o campo gatilho (ex: "Centro" com o valor '1720'), observe se o campo dependente (ex: "Depósito") é automaticamente preenchido com o valor determinado ('172A') sem a necessidade de uma ação explícita de salvar ou um refresh da tela.

5. Considerações Técnicas Adicionais

Determinação vs. Lógica de PBO

Determinação (Tachyonix): O conceito de "Determinação" na plataforma Tachyonix refere-se a uma lógica server-side ABAP, executada de forma reativa on-change de um campo específico na interface do usuário. Seu propósito é derivar ou preencher outros campos dinamicamente. Esta abordagem oferece feedback imediato ao usuário, pois a lógica é processada no backend e o resultado é refletido na UI sem um roundtrip completo da tela, otimizando a experiência do usuário e minimizando a latência.

Lógica de PBO (Dynpro ABAP): Em contraste, a lógica implementada no evento PROCESS BEFORE OUTPUT (PBO) de uma tela Dynpro tradicional é executada antes da exibição da tela ao usuário. O desenvolvedor codifica a lógica para pré-preencher campos ou ajustar o estado da UI antes que ela seja renderizada. A cada interação que exige um novo estado da tela, um roundtrip completo para o servidor ABAP é necessário para reexecutar o PBO e redesenhar a Dynpro. A Determinação da Tachyonix é mais interativa por reagir a uma mudança específica do usuário, proporcionando feedback imediato sem um refresh completo da tela.

Field Symbol de Alteração (cfs_det2)

O cfs_det2 (Changing Field Symbol) é o mecanismo central que permite a modificação direta do estado da UI a partir do backend ABAP. Ele atua como um ponteiro direto para a estrutura de dados que representa a linha atual (ou o registro principal, dependendo do contexto) na interface do usuário.

Qualquer alteração realizada neste field symbol (ex: cfs_det2-lgort = '172A') é automaticamente refletida de volta na tela do usuário após a execução da lógica de determinação no backend.

Para um desenvolvedor ABAP, isso é análogo a modificar um campo dentro de uma estrutura em um TABLE CONTROL ou manipular campos através de um LOOP AT SCREEN na lógica de PBO/PAI de uma Dynpro, onde as alterações no programa ABAP são propagadas para a interface gráfica.

Desacoplamento da Lógica com INCLUDE

A prática de encapsular a lógica de determinação em um INCLUDE ABAP customizado (ex: Y0DETERMINACAO_PO) é fundamental para promover a modularidade e a reusabilidade do código.

Reutilização

A mesma lógica contida no INCLUDE pode ser reutilizada em diferentes aplicações Tachyonix ou associada a diferentes campos, evitando duplicação de código.

Modularidade

Mantém a classe principal gerada automaticamente pela plataforma Tachyonix limpa e focada nas funcionalidades de framework. O código customizado de negócio reside no INCLUDE, separando claramente as responsabilidades.

Comparação ABAP

Esta abordagem é conceitualmente similar ao uso de USER-EXITS, BAdIs ou à criação de Function Modules reutilizáveis em ABAP. Em vez de embutir a lógica diretamente em programas principais ou classes geradas, ela é encapsulada em uma unidade de código separada que é invocada em pontos de extensão definidos, garantindo a manutenibilidade e a capacidade de extensão do sistema.