Ir al contenido
Kitegra
← Volver al blog

Módulo de este artículo: Integration Flow Helper

Headers y propiedades desconocidos en SAP CPI: detéctalos antes de que fallen en silencio

Por qué un header o una exchange property mal escrito o ausente en SAP CPI falla sin error, las causas habituales y cómo detectarlos en diseño y en tiempo de ejecución.

Headers y propiedades desconocidos en SAP CPI: detéctalos antes de que fallen en silencio

Un header que nunca se define no detiene un iFlow de SAP CPI. La expresión que lo lee devuelve un valor vacío, una condición de Router se vuelve falsa, un campo del payload queda en blanco y el mensaje sigue su camino. El error, si lo hay, aparece varios pasos después o en el sistema receptor.

Este artículo explica por qué los headers y las exchange properties ausentes fallan en silencio, las causas que se repiten una y otra vez, y las revisiones que los detectan antes de que un mensaje tropiece con ellos.

Por qué un nombre ausente no genera un error

Apache Camel trata un header o una propiedad que no existe como un valor vacío, no como un error. Eso es cómodo para valores opcionales, y es la razón por la que un error de tipeo puede vivir meses en un iFlow. Lo que ves depende de dónde se lee el nombre:

  • Un valor de Content Modifier como ${property.orderId} se convierte en una cadena vacía.
  • Una condición de Router o Filter como ${header.orderType} = 'EXPRESS' se evalúa como falsa, así que el mensaje toma otra ruta, a menudo la predeterminada.
  • Una dirección de receptor como /orders/${property.orderId} llama a /orders/, y el sistema receptor responde con un error que no menciona la propiedad ausente.
  • En un script de Groovy, message.getHeader("orderId", String) devuelve null, y el script falla más tarde con un error de puntero nulo o escribe el texto null en el payload.

Las causas habituales

  • Un error de tipeo, o mayúsculas y minúsculas equivocadas en el nombre de una propiedad: los nombres de exchange property distinguen mayúsculas de minúsculas, así que orderID y orderId son dos propiedades distintas. Los nombres de header no las distinguen.
  • Un espacio sobrante, por ejemplo ${header.orderId }: el nombre con el espacio es otro nombre.
  • Un valor definido en una sola ruta de un Router y leído después de que las rutas vuelven a unirse.
  • Un header que envía quien llama pero que no se deja pasar: un emisor HTTPS solo deja pasar los headers personalizados listados en Allowed Header(s), dentro de la Runtime Configuration del iFlow.
  • Una propiedad que se espera de otro iFlow: las exchange properties no cruzan una llamada ProcessDirect, solo los headers (consulta el artículo sobre ProcessDirect y JMS).
  • Una fila de header que lee una propiedad creada en el mismo Content Modifier, que procesa la tabla de headers antes que la de propiedades.

Haz que un valor ausente falle de forma visible

Para los valores sin los que el flujo no puede funcionar, haz que falle en el punto donde se necesitan y no tres pasos después. Basta un paso corto de Groovy al inicio del flujo:

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
}

El mensaje termina entonces en error con una frase que nombra la propiedad ausente, visible en el log de procesamiento del mensaje. En las condiciones de Router, dale a la ruta predeterminada un propósito claro: termínala en un evento Error End cuando el mensaje siempre deba tomar alguna de las rutas, en lugar de dejar que siga por un camino pensado solo como respaldo.

Mientras pruebas, pon el nivel de log del iFlow en Trace. El trace muestra los headers y las exchange properties en cada paso, así que puedes ver exactamente dónde desaparece un valor.

Una lista de comprobación antes de desplegar

  1. Enumera cada header y propiedad que lee el iFlow: en expresiones, condiciones, campos de adaptadores y scripts.
  2. Para cada uno, encuentra el paso que lo define, en cada ruta que llega al punto donde se lee.
  3. Compara la ortografía exacta, incluidas las mayúsculas y minúsculas en las propiedades y cualquier espacio.
  4. Para los headers que vienen del emisor, comprueba que estén en Allowed Header(s).
  5. Para los valores que llegan desde otro iFlow, comprueba que viajen como headers y no como propiedades.

Hecha a mano, esta revisión lleva un buen rato en un iFlow grande; por eso es la primera que vale la pena automatizar.

Hábitos de nombres que evitan el problema

  • Elige un estilo, como camelCase, y úsalo en todos los headers y propiedades del paquete.
  • Define los valores de los que depende todo el flujo en un solo Content Modifier cerca del inicio, para tener un único lugar donde buscar.
  • Deja los prefijos SAP_ y Camel para SAP y Apache Camel; dale a tus propios nombres otra forma.
  • Usa propiedades para los valores que solo necesita este iFlow, y headers solo para los valores que deben salir de él.

El artículo sobre expresiones Camel Simple explica la sintaxis detrás de cada nombre de esta lista.

Cómo ayuda Kitegra

La extensión de navegador Kitegra aplica esta lista de comprobación en el diseñador de SAP Integration Suite. Su panel de lint señala los headers y las propiedades que nada en el iFlow define, un ${ sin cerrar y los espacios sobrantes en las expresiones, antes de que despliegues.

Cuando escribes ${ o $, solo sugiere nombres que el iFlow define, incluidos los definidos en scripts de Groovy y JavaScript, además de los headers estándar de SAP y Camel, así que un error de tipeo es menos probable desde el principio. Un nombre que solo se define en algunas rutas aparece marcado como «Solo se define en algunas rutas». La extensión nunca guarda, despliega ni edita el contenido de un iFlow, y tu tenant solo cambia cuando haces clic en una de cuatro acciones con nombre, que se pueden desactivar.

Cuando un valor está vacío en tiempo de ejecución, trazar el mensaje paso a paso muestra los headers y las propiedades antes de cada paso, y la lista de revisión de iFlows cubre los errores de diseño que hay detrás.

Sin una cuenta de Kitegra funciona en 5 iFlows por módulo. El plan Free cubre 50, Starter 100 y Pro 300; Business no tiene límite. Compara los planes.

Pruébalo en tu próximo iFlow

Descubre lo que hace Kitegra en el diseñador de SAP Integration Suite, o míralo junto a las demás extensiones de Chrome de Kitegra.

Preguntas frecuentes

¿Por qué SAP CPI no lanza un error cuando falta un header?

Apache Camel devuelve un valor vacío para un header o una propiedad que no existe. El problema solo aparece donde ese valor vacío causa daño, a menudo varios pasos después.

¿Por qué mi exchange property es null si veo que está definida?

Revisa las mayúsculas y minúsculas: los nombres de exchange property las distinguen. Comprueba también que el paso que la define se ejecute en la ruta que tomó el mensaje, y que el valor no se esperara a través de una llamada ProcessDirect.

¿Por qué un header que envía quien llama no llega a mi iFlow?

Un emisor HTTPS solo deja pasar los headers personalizados listados en Allowed Header(s), en la Runtime Configuration del iFlow. Agrega ahí el nombre del header.

¿Cómo puedo ver los headers y las propiedades en cada paso?

Pon el nivel de log del iFlow en Trace y ejecuta un mensaje. El trace del monitor muestra los headers y las exchange properties de cada paso.

¿Cómo detengo el flujo cuando falta un valor obligatorio?

Agrega un paso de script que compruebe el valor y lance una excepción con un mensaje claro, o dirige la rama predeterminada de un Router a un evento Error End.

¿Se puede comprobar antes del despliegue?

Sí, comparando cada nombre que lee el iFlow con los nombres que define. El panel de lint de Kitegra lo hace en el diseñador.

Trabaja en iFlows sin salir del diseñador

Agrega Kitegra a Chrome o Microsoft Edge. Empieza gratis, sin necesidad de cuenta.