jueves, octubre 16, 2008

El Payload del contendido de un mensaje no aparece en el Message Monitoring

ACTUALIZADO: por fin he encontrado la manera de registrar los mensajes síncronos en el monitor de XI. Para ello hay que ir a la transacción SXMB_ADM -> Configurar Integration Engine -> Configuración específica y añadimos el parámetro:
  • Categoría: RUNTIME
  • Parámetro: LOGGING_SYNC
  • Valor actual: 1

    Y por si acaso, también recomiendan tener el valor del TRACE_LEVEL a nivel 3.

    Referencia: https://forums.sdn.sap.com/message.jspa?messageID=4599158

    Existen tres premisas que se deben conocer relacionadas con los payloads de los mensajes gestionados por XI:
    1. Por defecto, los mensajes SÍNCRONOS no se almacenan en XI para ahorrar espacio de almacenamiento.
    2. Hasta la versión PI 7.0 no hay manera directa de configurar XI para que guarde los mensajes síncronos procesados.
    3. En la versión de PI 7.1 existe una opción de indicar al servidor que guarde los mensajes síncronos procesados y ésta se describe en el blog Display Adapter Synchronous Message Content in RWB of PI 7.1

      Respecto al punto 2, no es del todo cierto. Existe un mecanismo de archivado de mensajes que permite, mediante un job, indicar qué mensajes de qué interfaces se deseean mantener registrados en el sistema. A esta opción se accede a través de la transaccion SXMB_ADM -> Especificar interfaces para archivo y tiempos de permanencia (Define Interfaces for Archiving and Retention Periods).


      En esta pantalla definiremos qué interfaces queremos rastrear y a través del botón Retention period indicaremos los días que deseamos que permanezcan los mensajes almacenados en el sistema. Por defecto los mensajes síncronos aceptados aparecen como no almacenables (0 días), por lo que deberemos cambiarlo para que dichos mensajes queden registrados.


      Una vez realizado esto deberemos planificar el job encargado de registrar los mensajes y, por último, para poder ver los mensajes recogidos en el sistema deberemos utilizar la transacción XMS_SARA para ir al administrador de mensajes y acceder a los archivos deseados en función del día.

      Referencias:

        martes, octubre 14, 2008

        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.



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



        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:

          lunes, octubre 13, 2008

          Probar un Web Service

          Una vez publicado un Web Service (mirar esta entrada para más información), falta poder probarlo. Existen varios modos de probar el funcionamiento de los Web Services.

          Uno de ellos es mediante el uso de herramientas externas específicas como lo son:

            Otro modo sería a través de la herramienta SAP Web Services Navigator (for Web services created/deployed on SAP Web AS) que proporciona XI para probar sus servicios web. Esta herramienta es el Navegador de Web Services y se puede acceder a ella desde la URL http://<servidor>:<puerto_java>/wsnavigator/enterwsdl.html. En ella deberemos introducir la dirección URL del WSDL publicado en la máquina. Para conocer dónde están publicados los servicios dentro de XI deberemos ejecutar la transacción SICF y navegar por el árbol base hasta encontrar el nombre del servicio correspondiente. Por defecto la ruta de los servicios suele ser: /default_host/sap/bc/bsp/sap/. Una vez conocida su ubicación se facilitará la URL al navegador (p.ej.: http://<servidor>:<puerto>/sap/bc/bsp/sap/aplicacion_ws/servicio_web.wsdl ). Tras introducir la ubicación del fichero WSDL se nos pedirá que nos identifiquemos en el sistema XI. A continuación, una vez cargado, pulsaremos sobre la opción Test y seleccionaremos la interfaz que deseamos probar pulsando sobre ella. Por último introduciremos los datos de entrada "a mano" y al pulsar el botón Send nos devolverá el mensaje de respuesta devuelto por el servidor. Este mecanismo es más visual e intuitivo pero no es muy rentable del punto de vista funcional ya que para pruebas que necesiten introducir muchos valores serían inviables de este modo.

            Por último, también se podría usar la página HTML cuyo código se proporciona en este link, la cual permite tanto introducir el código de petición XML a mano como a través de fichero, además de otras opciones de selección relativas al tipo de comunicación del servicio.

            Referencias:

              Publicar un Web Service

              ACTUALIZACIÓN (2009/03/11) - Este artículo pretende describir los pasos necesarios para generar el archivo WSDL correspondiente al Web Service creado sin llegar a tocar la publicación del mismo en los directorios UDDI. Mediante el fichero WSDL, el sistema externo podrá conocer la estructura de los datos del servicio y la dirección de conexión del mismo, por lo que bastará con hacerles llegar dicho fichero para que se puedan conectar al servicio deseado. Si se desea conocer más acerca de la publicación del fichero en directorios UDDI se puede consultar los enlaces de referencia que se encuentran al final del artículo.

              Una vez definido y configurado correctamente la interfaz de tipo Web Service queda publicar el servicio correspondiente.  En el Integration Builder existe un asistente que permite generar el documento WSDL necesario para que los servicios externos se puedan comunicar con el Web Service. Esta herramienta se puede encontrar en el menú Tools -> Define Web Service...


              Lo primero por lo que te pregunta el asistente es por la URL del canal de entrada del servidor SOAP de integración (Integration Server SOAP inbound channel). Bastará pulsar el botón de proponer URL (Propouse URL) para que el asistente nos facilite una URL válida del tipo http://<servidorXI>:<http_port>/sap/xi/engine?type=entry. No se recomienda el uso de esta URL ya que, aunque es válida para conectar con el servicio, no hace uso de la capa SOAP y, por lo tanto, no es segura.  Para hacer uso de la capa SOAP, la URL debe ser del tipo  http://<host>:<java_port>/XISOAPAdapter/MessageServlet?channel=<party>:<service>:<channel> o, en el caso de no existir PARTY: http://<host>:<java_port>/XISOAPAdapter/MessageServlet?channel=:<service>:<channel> (manteniendo los ':' previos al servicio).

              Ejemplo: http://ServidorXI:50000/XISOAPAdapter/MessageServlet?channel=:Service_BS:Sender_WS_CC

              Para comprobar que la dirección es válida se podrá probar la URL en el navegador de Internet y, tras identificarse con un usuario con los permisos adecuados, devolverá una página con el siguiente contenido:

              Message Servlet is in Status OK


              Status information:

              Servlet com.sap.aii.af.mp.soap.web.MessageServlet (Version $Id: //tc/xi/NW04S_12_REL/src/_adapters/_soap/java/com/sap/aii/af/mp/soap/web/MessageServlet.java#4 $) bound to /MessageServlet
              Classname ModuleProcessor: null
              Lookupname for localModuleProcessorLookupName: localejbs/ModuleProcessorBean
              Lookupname for remoteModuleProcessorLookupName: null
              ModuleProcessorClass not instantiated
              ModuleProcessorLocal is Instance of com.sap.aii.af.mp.processor.ModuleProcessorLocalLocalObjectImpl0_0
              ModuleProcessorRemote not instantiated

              En segundo lugar se nos pedirá que indiquemos la interfaz de mensaje del Repositorio de Integración que deseamos publicar. Hay que tener en cuenta que si el que inicia el servicio es el sistema externo, la interfaz será de salida (outbound). Para seleccionarla utilizaremos el botón de ayuda que aparece junto a los campos.


              El tercer paso consiste en indicar el sistema que inicia el servicio, en el campo Service se indicará el nombre lógico de la máquina (sistema o servicio de negocios), en el campo Interface Name indicaremos el nombre de la interfaz de mensajes que se especificó en el paso anterior y el espacio de nombres será el correspondiente a dicha interfaz.


              Una vez introducidos los campos necesarios, pulsaremos Finish y se generará el archivo WSDL que  permitirá a los sistemas externos comunicarse con el Web Service de nuestro sistema. Para ello pulsaremos el botón SAVE y lo guardaremos en algún directorio local de nuestro equipo. Hay que tener en cuenta que el servicio web está en funcionamiento desde el momento en el que se activan los canales de comunicación, por lo que la generación del WSDL no guarda relación con la activación del mismo.

              A continuación podremos incluir el servicio web en la Biblioteca BSP a través de la transacción SE80, pero esto no es necesario para el funcionamiento del mismo. En ella deberemos seleccionar el paquete donde deseemos vincular el servicio y con el botón derecho sobre el mismo seleccionaremos la opción Crear -> Biblioteca BSP. Seguidamente pulsaremos de nuevo con el botón derecho sobre la Biblioteca BSP recién creada y seleccionaremos la opción Crear -> Aplicación BSP y, por último, sobre la propia aplicación pulsaremos una vez más con el botón derecho del ratón y crearemos una aplicación.

              Cada aplicación puede contener más de un Web Service definido. Para crear un WS a partir del fichero WSDL que acabamos de generar pulsaremos con el botón derecho del ratón sobre la aplicación creada y seleccionaremos la opción Crear -> Objeto MIME -> Importar y seleccionaremos el archivo WSDL que hemos creado. No hay que olvidar activar la aplicación BSP tras generar el objeto MIME para que funcione correctamente. En este caso, cada vez que se modifique la "estructura" de los componentes implicados en la interfaz será necesario generar de nuevo el fichero WSDL y actualizarlo en la aplicación de la biblioteca BSP correspondiente (activando la aplicación después de su importación).

              Referencias:

                UDDI:

                  sábado, octubre 11, 2008

                  Problema de conexión de SPROXY a nivel de mandante

                  Este problema me sucedió en un entorno de red filtrado por un servidor proxy. La transacción SPROXY desde un mandante determinado, el 100, funcionaba correctamente mientras que para otro mandante de la misma máquina, el 200, dicha transacción devolvía un error de conexión con el Integration Builder.

                  Para conocer el posible motivo del fallo ejecuté el test de conexión que se proporciona en la transacción SPROXY y concretamente fallaba en el tercer punto, al ejecutar el report SPROX_CHECK_IFR_RESPONSE aparecía el siguiente mensaje:



                  El problema estaba en que para el mandante 200 se había activado la parametrización del proxy mientras que para el 100 no lo estaba. Esta parametrización es dependiente del mandante y para activarla/desactivarla hay que ir a la  transacción SICF y en el menú superior ir Mandante --> Parametriz.proxy (Ctrl+F2) y desmarcar la casilla "Parametriz.proxy activa" o en su defecto se pueden definir los filtros de las direcciones correspondientes.


                  El mensaje que devolvía el report SPROX_CHECK_IFR_RESPONSE se debía a que intentaba resolver la dirección de "servidorXI" a través del proxy en vez de resolverlo a través de los registros DNS definidos en el propio servidor.

                  Cambiar la codificación de caracteres de un fichero XML

                  Por defecto XI genera los mensajes XML en formato UTF-8. Para que estos se codifiquen en otro formato como el ISO-8859-1 habrá que configurar el adaptador receptor para que éste se encargue de hacerlo.

                  Como ejemplo se mostrará la configuración para un receptor de tipo fichero. Para lograr que el “contenido” del fichero se muestre en formato ISO-8859-1 se necesita añadir un módulo específico al adaptador que se encarga de realizar la conversión, entre otras cosas. En el caso de los ficheros XML, para que el módulo pueda procesar el contenido del fichero éste deberá ser de tipo BINARIO, de otro modo se producirá una excepción a la hora de procesar el fichero diciendo que el fichero pasado no se encuentra en el formato correcto. Esta restricción queda especificada en el enlace Configuring the Receiver File/FTP Adapter, en el apartado "Select the File Type of the document".



                  En la pestaña Module del adaptador se inserta el módulo AF_Modules/XMLAnonymizerBean en una posición anterior al módulo CallSapAdapter ya que de lo contrario se enviaría el fichero antes de procesarlo.

                  file_adapter_module

                  Una vez definido el módulo como tipo “Local Enterprise Bean”, se deberán especificar los parámetros anonymizer.acceptNamespaces y anonymizer.encoding. El primero sirve para filtrar los Espacios de Nombre (namespaces) del fichero que se desean conservar (los que no se informen aquí se eliminarán del fichero). Hay que tener en cuenta que un fichero XML puede contener más de un espacio de nombres definido y a través de este parámetro también se permitirá renombrar a los mismos. En el caso del namespace principal se indicará haciéndole corresponder 2 comillas simples (‘’). En la nota 880173 - XI 3.0 Adapter Framework XML Anonymizer Modulese se muestran varios ejemplos sobre el comportamiento de estos parámetros.

                  El segundo parámetro, encoding, indica el formato con el que se generarán los datos del fichero.

                  En este caso los valores que se le han dado a los parámetros han sido:
                  • anonymizer.acceptNamespaces = http://www.server.com/DIR/NameSpace ‘’
                  • anonymizer.encoding = ISO-8859-1

                    Para más información se pueden consultar los siguientes enlaces:

                      jueves, octubre 09, 2008

                      Reloj de proceso y mensaje en barra de estatus

                      La función SAPGUI_PROGRESS_INDICATOR imprime el reloj de proceso en la barra de estatus y el mensaje que se indique. En el siguiente ejemplo, se buscan todas las transacciones a las que no tiene permiso el usuario que ejecuta el código. Mientras se muestra el progreso de la búsqueda mediante el reloj el cual se actualiza cada 25% para que el refresco de pantalla no sea incómodo:


                      lunes, octubre 06, 2008

                      MAPPING.NO_MAPPINGPROGRAM_FOUND

                      El motivo de que se produzca este error se debe a que uno de los campos pasados contiene un formato no esperado y por lo tanto no se puede mapear en XI, lanzando un mensaje como el que sigue:



                      Cuando el volumen de datos enviados es demasiado grande se aconseja probar el servicio con un mensaje más pequeño representativo que nos permita validar el correcto funcionamiento de la interfaz. Una vez comprobado que el proceso de mapeo funciona correctamente, habrá que detectar cuál fue el campo que vino informado con un formato incorrecto (p.ej. "100,09" en vez de "100.09").

                      Otra posible causa de este error se debe a que los datos de la cache no hayan sido actualizados, por lo que bastaría refrescarla para que se registren los cambios.