Devolver mensajes de error estándar de proxies

Cuando se definen interfaces con Fault Message Type, para rellenar la estructura estándar cuando se han producido errores existe el siguiente método:
  
  data: standard_data type zpi_exchange_fault_data,
        detail_data   type zpi_exchange_log_data,
        ls_return     type bapiret2.

Value Mapping

El mapeo por valor (value mapping) es una función estándar de PI que permite realizar asignaciones de valores en función de la relación definida en el sistema. Esta opción solo es válida para relaciones entre valores 1 a 1. A diferencia con la función de asignación de valores fijos (FixValues), el value mapping permite reutilizar y mantener fácilmente las relaciones debido a que sus valores se almacenan en el Integration Directory. Mientras que con FixValues, la relación se establece a nivel local entre los campos mapeados.

Para definir un mapeo de valores, hay que ir a la opción Tool à Value Mapping del Integration Builder (Integration Directory). 

Mensajes de confirmación en proxies asíncronos

Cuando se envía una mensaje de manera asíncrona, puede interesar conocer si el mensaje ha llegado correctamente o si  ha habido algún tipo de error. Este escenario me lo encontré en una comunicación proxy -> jdbc, donde quería conocer si la inserción en la base de datos se hizo correctamente.

Como requisito, es necesario que el sistema origen tenga definido el adaptador proxy de recepción para que pueda recibir el mensaje de confirmación (con esto es suficiente, no es necesario definir nada más como el "Receiver agreement"). En el caso de PI 7.11 en adelante, también será necesario definir en el adaptador de envío, la conexión que utilizará para devolver las confirmaciones (esta conexión debe ser creada previamente en el NWA de PI).

Un aspecto a tener en cuenta es que, en mi caso no servía indicar el path "/MessagingSystem/receive/AFW/XI", ya que me daba un error de servicio no activado. Sin embargo sí me sirvió utilizar el path "/sap/xi/engine?type=receiver" y activar el servicio sap/xi/engine en el sistema ECC (tx: SICF), para que pueda recibir dichas respuestas.

Datos SLD no se actualiza en sistema ECC

Síntomas

• Obtención del mensaje LCR_GET_OWN_BUSINESS_SYSTEM - NO_BUSINESS_SYSTEM al realizar una llamada a proxy desde la máquina ECC o al ejecutar la transacción SXI_CACHE desde dicha máquina. También puede verse desde la transacción SLD_CACHE.
• La tabla LCRT_CLNTCACHE está vacía. En esta tabla es donde se recogen los datos de la SLD de la máquina XI.

Posibles problemas

1. El usuario de la transacción SLDAPICUST puede estar mal. El usuario que se indica en esta transacción debe estar definido en la máquina XI. Si el usuario está definido en XI y el problema está en que el password definido en la transacción SLDAPICUST de la máquina ECC está mal, lo podremos saber porque si ejecutamos la transacción SLDCHECK 3 veces  comprobamremos que en XI el usuario está bloqueado.
2. También se recomienda comprobar que el parámetro com.sap.aii.connect.integrationserver.r3.client del perfile de integración se corresponde con el mandante del Servidor de Integración.

Más información

• SAP NetWeaver Process Integration Troubleshooting Guide

Mensajes asíncronos no se envían/reciben con proxies

De entre las diferentes fuentes de las que puede proceder el problema (mala configuración del adaptador, mala configuración del escenario, no se ha actualizado la cache, etc.), se encuentra el caso en el que la cola de envío o la de recepción se encuentre saturada, generalmente porque uno de los mensajes contiene errores y no permite que el resto se ejecuten.

El escenario del que hablo hace referencia a un tipo de comunicación proxy asíncrona (asynch) relacionada con un canal de comunicación de tipo fichero de contenido fijo (File Content Conversion). En este caso se ha programado la interfaz para que cada vez que se detecte un fichero determinado en un directorio de XI se procese y se envíe mediante proxy al sistema ERP. El problema estaba en que al dejar el fichero en el directorio, el canal de comunicación correspondiente lo procesaba adecuadamente pero el mensaje nunca llegaba al sistema ERP (existía un mensaje de envío, pero no uno de recepción).

Existen varios modos para acceder a la cola de envío/recepción de mensajes. Uno es a través de la transacción SXMB_MONI y en la misma línea del mensaje en cuestión aparece un link, fuera de pantalla, a la derecha, a la cola en la que se encuentra. La otra manera es de manera directa a través de las transacciones SMQ1 (cola de salida) y SMQ2 (cola de entrada). Se recomienda revisar ambas colas y si se encuentran llenas bastará lanzar los mensajes ( F8 ) o eliminarlos para que los futuros mensajes de la interfaz puedan circular.

Eliminar Espacio de Nombres de fichero XML

Los ficheros XML generados por defecto en XI contienen una especificación explícita del espacio de nombres, aunque sólo exista uno.

<ns0:Mess_MT xmlns:ns0="http://sap.com/xi/namespace"> … </ns0:Mess_MT>

En ocasiones los mensajes que nos envían vienen sin especificar dicho espacio de nombres:

<Mess_MT> … </Mess_MT>

Para otros tipos de adaptadores (Ficheros/FTP, SOAP, …) existen módulos que permiten definir/filtrar los espacios de nombres de los ficheros (mirar entrada Cambiar la codificación de caracteres de un fichero XML), pero para el adaptador XI (ABAP Proxy) no es posible utilizar módulo alguno. Para ello es necesario modificar los tipos de mensajes involucrados y dejar en blanco el campo XML Namespace.

Una vez hecho esto, será necesario regenerar el/los ABAP proxies correspondientes desde la máquina con la que esté conectada el servidor XI a través de la transacción SPROXY.

Referencias:

• How to remove namespaces in Mapping - XI