Utilização de Side Effects

Utilização de Side Effects no ABAP RAP: Conceito, Exemplos e Aplicação

O ABAP RESTful Application Programming (RAP) é um modelo de programação moderno introduzido pela SAP para o desenvolvimento de aplicações baseadas em serviços OData no ambiente ABAP. Ele é amplamente utilizado para criar soluções robustas e escaláveis, especialmente no contexto do SAP S/4HANA.

Um dos recursos poderosos do RAP é o conceito de Side Effects (Efeitos Colaterais), que desempenha um papel crucial na construção de interfaces de usuário dinâmicas e responsivas. Neste artigo, exploraremos o que são Side Effects, por que e quando utilizá-los, e apresentaremos exemplos práticos de sua aplicação.

O que são Side Effects no ABAP RAP?

Side Effects no RAP referem-se a uma funcionalidade que permite ao desenvolvedor definir como as mudanças em uma entidade (como a atualização de um campo) afetam outras partes da mesma entidade ou de entidades relacionadas.

Em termos simples, é uma maneira de informar ao framework RAP que, após uma ação (como criar, atualizar ou deletar dados), determinados campos ou entidades precisam ser recalculados ou atualizados automaticamente no lado do servidor ou cliente.

Esse recurso é particularmente útil em cenários onde os dados exibidos na interface de usuário (como uma Fiori Elements UI) dependem uns dos outros. Ele garante que o comportamento da aplicação seja consistente e que a interface reflita as alterações em tempo real, sem a necessidade de recarregar toda a página ou executar chamadas manuais adicionais.

No RAP, os Side Effects são definidos no Behavior Definition de uma entidade, utilizando a sintaxe específica do ABAP CDS (Core Data Services). Eles são processados pelo Behavior Handler e podem ser acionados por ações, validações ou mudanças em campos específicos.

Por que utilizar Side Effects?

Os Side Effects trazem diversos benefícios ao desenvolvimento com RAP:

1. Experiência do Usuário Aprimorada: Eles permitem atualizações automáticas na interface, evitando que o usuário precise realizar ações manuais para ver os dados atualizados.
2. Consistência de Dados: Garantem que campos dependentes ou calculados sejam ajustados automaticamente após uma mudança, mantendo a integridade dos dados.
3. Redução de Código Manual: Em vez de escrever lógica adicional no frontend ou backend para atualizar valores dependentes, o RAP cuida disso automaticamente com base nas definições de Side Effects.
4. Suporte a Fiori Elements: Os Side Effects são especialmente úteis em aplicações baseadas em Fiori Elements, pois o framework utiliza essas definições para otimizar a interação com o serviço OData.

Quando utilizar Side Effects?

Os Side Effects devem ser usados em situações onde:

• Uma alteração em um campo impacta diretamente outros campos da mesma entidade ou de entidades relacionadas (ex.: cálculo de totais após mudar a quantidade de itens).
• Uma ação (como criar ou deletar um registro) exige a atualização de dados dependentes (ex.: recalcular o saldo após adicionar uma transação).
• É necessário garantir que a interface reflita mudanças em tempo real sem recarregar os dados manualmente.

Por outro lado, evite usá-los em cenários simples onde não há dependências entre campos ou entidades, pois isso pode adicionar complexidade desnecessária ao modelo.

Como definir Side Effects no ABAP RAP?

Os Side Effects são declarados no Behavior Definition de uma entidade CDS. Eles podem ser configurados para reagir a mudanças em campos específicos ou a ações, indicando quais campos ou entidades precisam ser atualizados.

Sintaxe Básica

A definição de Side Effects utiliza a palavra-chave side effects seguida das condições que disparam o efeito e os alvos afetados. Veja um exemplo básico:

define behavior for ZI_SalesOrder
{
  field ( mandatory ) CustomerID, OrderDate;
  field ( read only ) TotalAmount;
 
  side effects
  {
    field Quantity, Price affects field TotalAmount;
  }
}

Nesse exemplo:

• Quando os campos Quantity ou Price são alterados, o campo TotalAmount é automaticamente recalculado.

Exemplo Prático 1: Cálculo de Total em um Pedido de Venda

Imagine uma entidade de pedido de vendas (ZI_SalesOrder) com os campos OrderID, Quantity, Price e TotalAmount. O campo TotalAmount deve ser recalculado sempre que Quantity ou Price mudar.

Passo 1: Behavior Definition

define behavior for ZI_SalesOrder
implementation in class ZCL_SALESORDER_BEH unique
{
  field ( mandatory ) OrderID, Quantity, Price;
  field ( read only ) TotalAmount;
 
  side effects
  {
    field Quantity, Price affects field TotalAmount;
  }
 
  action CalculateTotal;
}

Passo 2: Implementação no Behavior Handler

No método da classe de comportamento (ZCL_SALESORDER_BEH), implementamos a lógica para recalcular o TotalAmount:

CLASS zcl_salesorder_beh IMPLEMENTATION.
 
  METHOD calculate_total.
    READ ENTITIES OF ZI_SalesOrder IN LOCAL MODE
      ENTITY ZI_SalesOrder
      FIELDS ( Quantity Price ) WITH CORRESPONDING #( keys )
      RESULT DATA(orders).
 
    MODIFY ENTITIES OF ZI_SalesOrder IN LOCAL MODE
      ENTITY ZI_SalesOrder
      UPDATE FIELDS ( TotalAmount )
      WITH VALUE #( FOR order IN orders
                    ( %tky = order-%tky
                      TotalAmount = order-Quantity * order-Price ) )
      REPORTED DATA(reported).
 
  ENDMETHOD.
 
ENDCLASS.

Resultado

Quando o usuário altera Quantity ou Price na interface Fiori, o RAP detecta a mudança, aciona o Side Effect e recalcula o TotalAmount automaticamente.

Exemplo Prático 2: Atualização de Status Após uma Ação

Agora, suponha que temos uma ação ApproveOrder que altera o status de um pedido para "Aprovado". Queremos que o campo StatusDescription seja atualizado automaticamente.

Passo 1: Behavior Definition

define behavior for ZI_SalesOrder
{
  field ( mandatory ) OrderID;
  field ( read only ) Status, StatusDescription;
 
  action ApproveOrder;
 
  side effects
  {
    action ApproveOrder affects field StatusDescription;
  }
}

Passo 2: Implementação no Behavior Handler

CLASS zcl_salesorder_beh IMPLEMENTATION.
 
  METHOD approve_order.
    MODIFY ENTITIES OF ZI_SalesOrder IN LOCAL MODE
      ENTITY ZI_SalesOrder
      UPDATE FIELDS ( Status )
      WITH VALUE #( FOR key IN keys ( %tky = key-%tky Status = 'APPROVED' ) )
      REPORTED DATA(reported).
 
    " Lógica adicional para StatusDescription pode ser implementada em um determination
  ENDMETHOD.
 
ENDCLASS.

Resultado

Ao executar a ação ApproveOrder, o campo StatusDescription é atualizado automaticamente na interface, refletindo a descrição correspondente ao novo status.

Conclusão

Os Side Effects no ABAP RAP são uma ferramenta poderosa para criar aplicações dinâmicas e consistentes, especialmente em cenários onde os dados são interdependentes. Eles reduzem a necessidade de lógica manual no frontend e garantem uma experiência de usuário fluida. No entanto, é importante utilizá-los com critério, aplicando-os apenas onde há claras relações de dependência entre os dados.

Com os exemplos acima, fica evidente que os Side Effects podem ser aplicados tanto a campos quanto a ações, oferecendo flexibilidade no desenvolvimento de soluções RAP. Ao dominar esse recurso, os desenvolvedores ABAP podem construir aplicações mais eficientes e alinhadas às melhores práticas da SAP.