OmniStudio para Energy & Utilities: padrões de arquitetura e aprendizados

Projetos de Energy & Utilities costumam combinar cálculos extensos, contratos de vários períodos, cadeias de aprovação e grandes estruturas de dados. Isso exige mais do que montar uma sequência de telas. É preciso separar interface, orquestração, processamento e persistência.

Os padrões abaixo são didáticos e genéricos. Os nomes, classes, campos e exemplos são fictícios e não representam projeto, cliente ou regra de negócio real.

Por que esses projetos exigem atenção especial

Em uma implementação simples, o OmniScript coleta dados, uma Integration Procedure orquestra chamadas e um Data Mapper lê ou grava registros. Em cenários intensivos em cálculo, uma única solicitação pode combinar curvas, períodos, condições comerciais e grande quantidade de linhas. O Data JSON cresce e o processamento pode se aproximar dos limites da plataforma.

Padrão 1: separar o motor de cálculo

Camada 1, OmniScript: coleta apenas as escolhas necessárias e envia uma carga controlada.

Camada 2, Integration Procedure: valida entradas, organiza chamadas e reduz a resposta.

Camada 3, serviço Apex: executa cálculos que exigem controle de volume, bulkificação e tratamento explícito de limites.

Camada 4, atualização da interface: informa a conclusão por um mecanismo assíncrono apropriado e atualiza os dados exibidos.

call() → CalculationCoordinator.process()
       → PricingService.calculate()
       → ResultRepository.persist()

Os nomes acima são apenas exemplos fictícios. O princípio importante é a separação de responsabilidades.

Padrão 2: aprovação baseada em dados persistidos

Quando critérios de aprovação dependem do resultado de um cálculo, use valores persistidos e auditáveis. Não dependa somente do Data JSON presente no navegador, pois ele representa um estado transitório e pode ficar desatualizado.

Um resumo consolidado pode reduzir a complexidade das regras de aprovação, desde que o cálculo seja rastreável e sua origem esteja documentada.

Padrão 3: controlar o tamanho do Data JSON

Respostas completas de objetos, listas intermediárias e nós que já cumpriram sua função aumentam o custo de cada transição. Na Response Action da Integration Procedure, retorne somente os campos necessários à interface ou à próxima etapa.

Request
  ├─ Context
  ├─ Configuration
  └─ Items
Response
  ├─ Status
  ├─ Summary
  └─ RequiredFields

A estrutura é fictícia e serve apenas para mostrar uma resposta reduzida.

Padrão 4: disciplina nas Conditional Views

Confirme o caminho real no Data JSON e o tipo do valor comparado. Booleano true é diferente do texto "true". Quando vários elementos possuem a mesma condição, avalie aplicar a regra a um bloco comum para reduzir duplicação e facilitar manutenção.

Padrão 5: pré-validação antes do processamento pesado

Valide identificadores, datas, configurações obrigatórias e disponibilidade dos dados antes de iniciar um cálculo caro. Retorne erros estruturados e compreensíveis para que o OmniScript consiga orientar a pessoa usuária.

validateRequest()
validateConfiguration()
normalizeDates()
invokeCalculation()

Cuidados com processamento assíncrono

Assíncrono não significa automaticamente mais rápido. Ele muda o limite e o ciclo de execução, mas adiciona estado, monitoramento, idempotência e tratamento de falhas. Use quando a carga e a experiência realmente exigirem. Defina como evitar execução duplicada e como recuperar uma operação interrompida.

Principais conclusões

Separe interface, orquestração e cálculo. Reduza o Data JSON. Baseie aprovações em dados persistidos. Pré-valide antes de consumir recursos. Use processamento assíncrono com estado e estratégia de recuperação.

Esses padrões não eliminam a necessidade de medir. Use logs, testes de volume e dados representativos para confirmar se a arquitetura atende aos limites e ao tempo de resposta esperado.

Fontes oficiais

Call an Apex Class or Invocable Action from an Integration Procedure
Apex Governor Limits
Platform Events Developer Guide