SmartFreight: Portal Logístico
Estudo de caso técnico: Arquitetura S/4HANA 2020 via RESTful ABAP Programming (RAP).
O Desafio do Negócio
Simulação de uma exigência real de arquitetura: Integrar o ecossistema SAP com uma parceira 3PL (GlobalFreight). O objetivo foi receber webhooks JSON em tempo real, processar regras de auditoria de quebra de cadeia de frio (-15°C) no ERP, e renderizar um dashboard Fiori dinâmico sem desenvolvimento UI tradicional.
Modelagem da Fundação de Dados
O que foi criado:
Tabela física ZLOG_TRACKING otimizada para integração.
Por que (Decisão Arquitetural):
O modelo RAP Managed exige uma 'single source of truth'. Campos como timestampl garantem tratamento universal de fuso horário UTC (crítico para integrações globais).
Interface View: Mapeamento de Negócio
O que foi criado:
A Root Entity ZI_LogTracking, realizando o mapeamento direto dos campos técnicos da tabela física para nomes de negócio amigáveis (CamelCase).
Por que (Decisão Arquitetural):
Estabelecimento da base do Virtual Data Model (VDM). Esta camada isola a complexidade do banco de dados e fornece uma estrutura reutilizável e estável para as camadas de consumo e UI.
Projection View: Orquestração da Interface (UI)
O que foi criado:
View de Projeção ZC_LogTracking enriquecida com anotações @UI.headerInfo, @UI.facet e metadados de 'criticality' para vincular cores ao StatusColor.
Por que (Decisão Arquitetural):
Desenvolvimento Declarativo. Configuramos filtros de busca (selectionField) e lógica visual diretamente no CDS, permitindo que o Fiori Elements gere o dashboard sem codificação manual de frontend.
Motor Transacional e Regra de Cadeia de Frio
O que foi criado:
Behavior Definition (Managed) com evento Determination On Save, suportado por uma classe ABAP manipulando dados via EML (Entity Manipulation Language).
Por que (Decisão Arquitetural):
Substitui o antigo framework de BAdIs/SEGW. Em vez de validações estáticas, a determinação intercepta transações do middleware, processa as regras logísticas e atua como uma engine inteligente, alterando flags de auditoria antes da gravação em disco sem contornar as travas de banco (Locks).
Publicação do Endpoint OData V4
O que foi criado:
Service Definition mapeando a CDS de consumo e Service Binding publicando a API ICF.
Por que (Decisão Arquitetural):
Adoção rigorosa do protocolo OData V4 (tipo UI). Ele não apenas expõe o CRUD transacional, mas carrega o payload de metadados estendidos, permitindo a orquestração do UI e conectividade fluida com o SAP CPI via Webhooks.
Injeção EML (Mock CPI Payload)
O que foi criado:
Script ABAP atuando como Dummy Middleware Injetor via CREATE FIELDS.
Por que não usamos SAP CPI no teste?
Isolamento de falhas. Validar o core ABAP EML garante que a inteligência de backend é impermeável a erros de conectividade de rede (Cloud Connector). A injeção provocou o RAP a tomar decisões logísticas sem ruídos externos.
Dashboard Renderizado: Zero JS, 100% ABAP
Resultado arquitetural final: A aplicação Fiori Elements leu perfeitamente os metadados. O título das colunas, os filtros de busca e a inteligência de negócios foram aplicados. A carga que excedeu o limite de frio (-10°C) foi interceptada pela classe ABAP e dinamicamente renderizada em vermelho crítico (1), provando a robustez da solução Cloud-Ready no ambiente on-premise.
Protocolo de Teste
Resultado: Renderização verde (Status 3).
Resultado: Renderização vermelha (Status 1).