Headers e propriedades desconhecidos no SAP CPI: detecte-os antes que falhem em silêncio

Um header que nunca é definido não interrompe um iFlow do SAP CPI. A expressão que o lê retorna um valor vazio, uma condição de Router fica falsa, um campo do payload fica em branco, e a mensagem segue em frente. O erro, se houver, aparece vários passos depois ou no sistema receptor.

Este artigo explica por que headers e exchange properties ausentes falham em silêncio, as causas que aparecem sempre, e as verificações que os detectam antes que uma mensagem tropece neles.

Por que um nome ausente não gera erro

O Apache Camel trata um header ou uma propriedade que não existe como vazio, não como um erro. Isso é prático para valores opcionais, e é o motivo de um erro de digitação poder viver meses em um iFlow. O que você vê depende de onde o nome é lido:

• Um valor de Content Modifier como ${property.orderId} vira uma string vazia.
• Uma condição de Router ou Filter como ${header.orderType} = 'EXPRESS' é avaliada como falsa, então a mensagem segue outra rota, muitas vezes a padrão.
• Um endereço de receptor como /orders/${property.orderId} chama /orders/, e o sistema receptor responde com um erro que não menciona a propriedade ausente.
• Em um script Groovy, message.getHeader("orderId", String) retorna null, e o script falha mais tarde com um erro de ponteiro nulo ou grava o texto null no payload.

As causas mais comuns

• Um erro de digitação, ou maiúsculas e minúsculas trocadas no nome de uma propriedade: nomes de exchange property diferenciam maiúsculas de minúsculas, então orderID e orderId são duas propriedades diferentes. Nomes de header não diferenciam.
• Um espaço a mais, por exemplo ${header.orderId }: o nome com o espaço é outro nome.
• Um valor definido em apenas uma rota de um Router e lido depois que as rotas se juntam de novo.
• Um header enviado pelo chamador mas não liberado: um emissor HTTPS só deixa passar os headers personalizados listados em Allowed Header(s), na Runtime Configuration do iFlow.
• Uma propriedade esperada de outro iFlow: exchange properties não atravessam uma chamada ProcessDirect, só os headers atravessam (veja o artigo sobre ProcessDirect e JMS).
• Uma linha de header lendo uma propriedade criada no mesmo Content Modifier, que processa a tabela de headers antes da tabela de propriedades.

Faça um valor ausente falhar de forma visível

Para valores sem os quais o fluxo não funciona, faça o fluxo falhar no ponto em que eles são necessários, e não três passos depois. Um passo curto em Groovy no início do fluxo basta:

import com.sap.gateway.ip.core.customdev.util.Message

def Message processData(Message message) {
    def orderId = message.getProperty("orderId")
    if (orderId == null || orderId.toString().trim().isEmpty()) {
        throw new IllegalStateException("Exchange property orderId is not set")
    }
    return message
}

A mensagem então termina em erro com uma frase que cita a propriedade ausente, visível no log de processamento da mensagem. Para condições de Router, dê à rota padrão um propósito claro: termine-a em um evento Error End quando a mensagem sempre tiver de seguir uma das rotas, em vez de deixá-la seguir por um caminho pensado só como alternativa.

Enquanto testa, coloque o nível de log do iFlow em Trace. O trace mostra os headers e as exchange properties em cada passo, para você ver exatamente onde um valor desaparece.

Um checklist antes de implantar

1. Liste cada header e cada propriedade que o iFlow lê: em expressões, condições, campos de adaptadores e scripts.
2. Para cada um, encontre o passo que o define, em todos os caminhos que chegam ao ponto de leitura.
3. Compare a grafia exata, incluindo maiúsculas e minúsculas nas propriedades e qualquer espaço.
4. Para headers que vêm do emissor, confira se estão em Allowed Header(s).
5. Para valores vindos de outro iFlow, confira se viajam como headers, e não como propriedades.

Feita à mão, essa verificação leva um bom tempo em um iFlow grande, e é por isso que ela é a primeira que vale a pena automatizar.

Hábitos de nomenclatura que evitam o problema

• Escolha um estilo, como camelCase, e use-o em todos os headers e propriedades do pacote.
• Defina os valores de que o fluxo inteiro depende em um único Content Modifier perto do início, para ter um só lugar onde procurar.
• Deixe os prefixos SAP_ e Camel para o SAP e o Apache Camel; dê aos seus próprios nomes outro formato.
• Use propriedades para valores de que só este iFlow precisa, e headers apenas para valores que precisam sair dele.

O artigo sobre expressões Camel Simple explica a sintaxe por trás de cada nome desta lista.

Como o Kitegra ajuda

A extensão de navegador Kitegra executa este checklist no designer do SAP Integration Suite. O painel de lint aponta headers e propriedades que nada no iFlow define, um ${ não fechado e espaços sobrando em expressões, antes de você implantar.

Quando você digita ${ ou $, ela sugere só nomes que o iFlow define, incluindo os definidos em scripts Groovy e JavaScript, além dos headers padrão do SAP e do Camel, então um erro de digitação fica menos provável desde o início. Um nome definido só em alguns caminhos aparece marcado como “Definido apenas em alguns caminhos”. A extensão nunca salva, implanta nem edita o conteúdo de um iFlow, e o seu tenant só muda quando você clica em uma de quatro ações nomeadas, que podem ser desativadas.

Quando um valor está vazio em tempo de execução, rastrear a mensagem passo a passo mostra os headers e as propriedades antes de cada passo, e o checklist de revisão de iFlows cobre os erros de design por trás disso.

Sem uma conta Kitegra, ela funciona em 5 iFlows por módulo. O plano Free cobre 50, o Starter 100 e o Pro 300; o Business não tem limite. Compare os planos.

Experimente no seu próximo iFlow

Veja o que o Kitegra faz no designer do SAP Integration Suite, ou confira-o ao lado das outras extensões do Chrome da Kitegra.

Perguntas frequentes