Uno de los posibles motivos por los que no haya llegado un fichero a un servidor FTP es que el servidor esté lleno. Este caso aparecerá reflejado en la herramienta de visualización de mensajes de XI (XI Message Display Tool), informando un log similar al siguiente:
viernes, junio 19, 2009
Error during communication with SLD: User credentials are invalid or user is denied access
Este error aparece cuando se intenta acceder al "Runtime Workbench" del repositorio de XI, en este caso, tras introducir las credenciales de usuario, aparece el error "Following error occurred while executing the application: Error during communication with System Landscape Directory: User credentials are invalid or user is denied access". El problema puede estar en que el usuario de XI "XIRWBUSER" o "PIRWBUSER" (dependiendo de la versión de XI) está bloqueado.
En la entrada Usuario PIRWBUSER bloqueado frecuentemente se indica cómo solucionar este problema.
Más información:
http://sap.ittoolbox.com/groups/technical-functional/sap-basis/error-during-communication-with-system-landscape-directory-user-credentials-are-invalid-or-user-is-denied-access-1718332
En la entrada Usuario PIRWBUSER bloqueado frecuentemente se indica cómo solucionar este problema.
Más información:
http://sap.ittoolbox.com/groups/technical-functional/sap-basis/error-during-communication-with-system-landscape-directory-user-credentials-are-invalid-or-user-is-denied-access-1718332
martes, junio 16, 2009
Cliente FTP multiprotocolo y multiplataforma
En ocasiones, existen servidores FTP que hacen uso del protocolo TLS. Esto requiere configurar de la manera adecuada el firewall tras el que se encuentra el servidor XI para que se pueda conectar de manera correcta con dicho servidor FTP.
Para comprobar si el firewall estaba bien configurado, busqué un cliente FTP multiprotocolo disponible para varios sistemas operativos (UNIX, AIX, Linux, Windows,...) de manera que me permitiera realizar una prueba de conexión desde un equipo, en mi caso con Windows, exterior a la red y, una vez logrado conectar con el servidor FTP, reproducir los mismos comandos, pero esta vez desde el cliente FTP instalado en el servidor XI.
El cliente utilizado fue el Curl y el enlace de descarga es http://curl.haxx.se/download.html (recomiendo usar el wizard de descarga para obtener la últiva versión: http://curl.haxx.se/dlwiz/).
El cliente funciona por comandos. En Windows no necesita instalación, basta descomprimir el archivo en una carpeta local y seguidamente ejecutar los comandos. La versión que utilicé fue la curl-7.19.5-ssl-sspi-zlib-static-bin-w32.zip.
El servidor FTP requería:
Para las pruebas de conexión basta con que funcione algunos de los siguientes comandos:
Comandos que muestran el contenido de la carpeta raíz del servidor de pruebas:
C:\curl>curl -k -u <user>:<pass> --ftp-ssl -1 ftp://ftp.server.com:990
C:\curl>curl -k -u <user>:<pass> --ftp-ssl-reqd -1 ftp://ftp.server.com:990
C:\curl>curl -k -u <user>:<pass> --ftp-pasv --ftp-ssl -1 ftp://ftp.server.com:990
Resultado:
drwxrwxr-x 5 (?) (?) 4096 Mar 31 13:14 dir
Comandos que muestran un listado del directorio /DIR/:
C:\curl>curl -k -u <user>:<pass> --ftp-pasv --ftp-ssl -1 ftp://ftp.server.com:990/dir/
Resultado:
drwxrwxr-x 2 (?) (?) 4096 Jun 8 16:27 input
drwxrwxr-x 2 (?) (?) 4096 Jun 8 16:28 output
A continuación indico el significado de las opciones utilizadas:
-k/--insecure
(SSL) This option explicitly allows curl to perform "insecure" SSL connections
and transfers. All SSL connections are attempted to be made secure by using the
CA certificate bundle installed by default. This makes all connections considered
"insecure" fail unless -k/--insecure is used.
-u/--user <user:password>
Specify the user name and password to use for server authentication. Overrides
-n/--netrc and --netrc-optional.
If you just give the user name (without entering a colon) curl will prompt for
a password.
If you use an SSPI-enabled curl binary and do NTLM authentication, you can
force curl to pick up the user name and password from your environment by simply
specifying a single colon with this option: "-u :".
If this option is used several times, the last one will be used.
--ftp-ssl
(FTP) Try to use SSL/TLS for the FTP connection. Reverts to a non-secure
connection if the server doesn’t support SSL/TLS. See also --ftp-ssl-control and
--ftp-ssl-reqd for different levels of encryption required. (Added in 7.11.0)
--ftp-ssl-reqd
(FTP) Require SSL/TLS for the FTP connection. Terminates the connection if the
server doesn’t support SSL/TLS. (Added in 7.15.5)
-1/--tlsv1
(SSL) Forces curl to use TLS version 1 when negotiating with a remote TLS server.
Lo único que falta es probar que estos mismos comandos funcionan desde el servidor de XI con la configuración actual del firewall.
Para comprobar si el firewall estaba bien configurado, busqué un cliente FTP multiprotocolo disponible para varios sistemas operativos (UNIX, AIX, Linux, Windows,...) de manera que me permitiera realizar una prueba de conexión desde un equipo, en mi caso con Windows, exterior a la red y, una vez logrado conectar con el servidor FTP, reproducir los mismos comandos, pero esta vez desde el cliente FTP instalado en el servidor XI.
El cliente utilizado fue el Curl y el enlace de descarga es http://curl.haxx.se/download.html (recomiendo usar el wizard de descarga para obtener la últiva versión: http://curl.haxx.se/dlwiz/).
El cliente funciona por comandos. En Windows no necesita instalación, basta descomprimir el archivo en una carpeta local y seguidamente ejecutar los comandos. La versión que utilicé fue la curl-7.19.5-ssl-sspi-zlib-static-bin-w32.zip.
El servidor FTP requería:
- Protocolo: TLS
- Puerto: 990
- Conexión: pasiva
Para las pruebas de conexión basta con que funcione algunos de los siguientes comandos:
Comandos que muestran el contenido de la carpeta raíz del servidor de pruebas:
C:\curl>curl -k -u <user>:<pass> --ftp-ssl -1 ftp://ftp.server.com:990
C:\curl>curl -k -u <user>:<pass> --ftp-ssl-reqd -1 ftp://ftp.server.com:990
C:\curl>curl -k -u <user>:<pass> --ftp-pasv --ftp-ssl -1 ftp://ftp.server.com:990
Resultado:
drwxrwxr-x 5 (?) (?) 4096 Mar 31 13:14 dir
Comandos que muestran un listado del directorio /DIR/:
C:\curl>curl -k -u <user>:<pass> --ftp-pasv --ftp-ssl -1 ftp://ftp.server.com:990/dir/
Resultado:
drwxrwxr-x 2 (?) (?) 4096 Jun 8 16:27 input
drwxrwxr-x 2 (?) (?) 4096 Jun 8 16:28 output
A continuación indico el significado de las opciones utilizadas:
(SSL) This option explicitly allows curl to perform "insecure" SSL connections
and transfers. All SSL connections are attempted to be made secure by using the
CA certificate bundle installed by default. This makes all connections considered
"insecure" fail unless -k/--insecure is used.
-u/--user <user:password>
Specify the user name and password to use for server authentication. Overrides
-n/--netrc and --netrc-optional.
If you just give the user name (without entering a colon) curl will prompt for
a password.
If you use an SSPI-enabled curl binary and do NTLM authentication, you can
force curl to pick up the user name and password from your environment by simply
specifying a single colon with this option: "-u :".
If this option is used several times, the last one will be used.
--ftp-ssl
(FTP) Try to use SSL/TLS for the FTP connection. Reverts to a non-secure
connection if the server doesn’t support SSL/TLS. See also --ftp-ssl-control and
--ftp-ssl-reqd for different levels of encryption required. (Added in 7.11.0)
--ftp-ssl-reqd
(FTP) Require SSL/TLS for the FTP connection. Terminates the connection if the
server doesn’t support SSL/TLS. (Added in 7.15.5)
-1/--tlsv1
(SSL) Forces curl to use TLS version 1 when negotiating with a remote TLS server.
Lo único que falta es probar que estos mismos comandos funcionan desde el servidor de XI con la configuración actual del firewall.
jueves, mayo 14, 2009
Objetos de autorización (AUTHORITY-CHECK OBJECT)
Los objetos de autorización disponibles se encuentran en las transacciones SU20 y SU21. Mediante la primera podremos buscar por campo/elemento de datos los objetos disponibles. Por ejemplo, podemos buscar qué objetos de autorización existen asociados al campo división (GSBER). Al hacer doble clic sobre el resultado de la búsqueda accederemos a la pantalla de "Ámbito de autorización" donde se detalla, en la sección inferior, los objetos de utilización que utilizan el criterio seleccionado. Para el caso del campo División, nos puede ser útil los objetos de autorización que se encuentran en la clase de objeto FI.
La transacción SU21 ofrece más detalle sobre los objetos de autorización. Si quisiéramos conocer la composición del objeto F_BKPF_GSB, el cual se encuentra en la clase FI, deberemos buscar por el nombre del objeto mediante el icono de los prismáticos y hacer doble clic sobre el mismo. El objeto F_BKPF_GSB está compuesto de la siguiente manera:
Tras conocer la composición del objeto, podremos hacer uso del mismo del siguiente modo:
Donde p_gsber es el campo que contiene la división sobre la que se quiere comprobar si el usuario tiene permiso. También se puede hacer uso del identificador ACTVT para determinar el tipo de actividad que se quiere comprobar. Las atividades permitidas del objeto se pueden visualizar en la parte inferior de la ventana de descripción del objeto en la transacción SU21.
La transacción SU21 ofrece más detalle sobre los objetos de autorización. Si quisiéramos conocer la composición del objeto F_BKPF_GSB, el cual se encuentra en la clase FI, deberemos buscar por el nombre del objeto mediante el icono de los prismáticos y hacer doble clic sobre el mismo. El objeto F_BKPF_GSB está compuesto de la siguiente manera:
Tras conocer la composición del objeto, podremos hacer uso del mismo del siguiente modo:
Donde p_gsber es el campo que contiene la división sobre la que se quiere comprobar si el usuario tiene permiso. También se puede hacer uso del identificador ACTVT para determinar el tipo de actividad que se quiere comprobar. Las atividades permitidas del objeto se pueden visualizar en la parte inferior de la ventana de descripción del objeto en la transacción SU21.
jueves, abril 30, 2009
Reemplazar caracteres por espacios en blanco
El siguiente código reemplaza los caracteres que concuerden con las expresiones lógicas por un espacio en blanco. Nótese como la definición del espacio en blanco se realiza mediante comillas simples inversas (`), esto es así porque se trata de una expresión de "sustitución".
Significado de las expresiones:
La constante GC_ISO contiene los caracteres imprimibles propios del conjunto ISO 8859-1, para las pruebas.
Significado de las expresiones:
- GC_ISO_EXP: sustituye los caracteres típicos de ficheros XML y de texto por espacios en blanco (< >' " & ; : ¨ ^).
- GC_LN: sustituye los caracteres que NO sean minúsculas (\l) ni mayúsculas (\u) ni numéricos (\d).
- GC_LC: sustituye los caracteres que NO sean minúsculas (\l) ni mayúsculas (\u) ni numéricos (\d) ni el guión (-) ni la barra (/).
- GC_LNG: sustituye los caracteres que NO sean minúsculas (\l) ni mayúsculas (\u) ni numéricos (\d) ni el guión (-) .
La constante GC_ISO contiene los caracteres imprimibles propios del conjunto ISO 8859-1, para las pruebas.
martes, abril 28, 2009
Función de mapeo de usuario para decodificar un campo en Base64
La siguiente función definida por usuario o User-Defined Function (UDF) decodifica el contenido de un campo en base64.
En este caso he utilizado la librería "sun.misc.BASE64Decoder" de la que es propietaria SUN. Podría valer cualquier otra, pero es la que utilizaban en el código de referencia que utilicé para este ejemplo: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9793
De manera análoga se puede codificar un campo en Base64 utilizando la librería correspondiente.
En este caso he utilizado la librería "sun.misc.BASE64Decoder" de la que es propietaria SUN. Podría valer cualquier otra, pero es la que utilizaban en el código de referencia que utilicé para este ejemplo: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9793
De manera análoga se puede codificar un campo en Base64 utilizando la librería correspondiente.
martes, marzo 24, 2009
Comprobar conexión servidor hacia fuera
A la hora de consumir un web service externo es necesario saber si la conexión hacia el exterior está configurara correctamente (puertos del firewall, etc.). Una manera sencilla de realizar dicha comprobación es a través de la creación de una conexión HTTP con servidor externo (tipo G) en la transacción SM59 y en la que incluiremos la dirección del servidor al que se desea acceder. Para comprobar si hay conexión bastará pulsar el botón "Test de conexión".
Una mala configuración puede provocar que se reciban timeouts a la hora de invocar el web service o que se produzcan fallos a la hora de crear el socket de comunicación...
Una mala configuración puede provocar que se reciban timeouts a la hora de invocar el web service o que se produzcan fallos a la hora de crear el socket de comunicación...
jueves, marzo 05, 2009
Timeouts en escenarios síncronos
Existen ocaciones en las que los programas que utilizamos pueden tardar mucho en función de la cantidad de datos que le vayamos a pedir. Esto puede dar lugar a que si nos encontramos en un escenario síncrono podamos obtener un timeout como respuesta.
En mi caso, el escenario en el que se producía el error era de tipo síncrono (SOAP -> RFC). Y el timeout aparecía cuando la función tenía que recopilar demasiados datos.
En la transacción SM21 aparece una versión más detallada del error:
Una de las maneras de ampliar el tiempo de timeout es a través de la transacción SMICM. En el menú Pasar a -> Servicios (Shift+F1) veremos que el tiempo definido para el servicio HTTP es de 60 segundos, por lo que bastará marcar dicho servicio y editarlo (menú Servicio -> Modificar) para asignarle el tiempo que deseemos.
NOTA: Hay que tener en cuenta que estos cambios se perderán si se reinicia el servicio ICM, tal como notifica el siguiente mensaje:
Una de las opciones posibles para definir de manera definitiva esta parametrización es por medio de la creación del parámetro de perfil icm/server_port_<xx> a través de la transacción RZ10. Ejemplo:
icm/server_port_0 = PROT=HTTP,PORT=8000,TIMEOUT=30,PROCTIMEOUT=600
Los posibles valores vienen descritos en el link Timeout Options for ICM and Web Dispatcher.
Este parámetro se debe incluir en un fichero del sistema, por lo que deberá ser un administrador el que realice la configuración.
Links de referencia:
500 Connection timed out
|
| © 2001-2005, SAP AG |
En mi caso, el escenario en el que se producía el error era de tipo síncrono (SOAP -> RFC). Y el timeout aparecía cuando la función tenía que recopilar demasiados datos.
En la transacción SM21 aparece una versión más detallada del error:
Una de las maneras de ampliar el tiempo de timeout es a través de la transacción SMICM. En el menú Pasar a -> Servicios (Shift+F1) veremos que el tiempo definido para el servicio HTTP es de 60 segundos, por lo que bastará marcar dicho servicio y editarlo (menú Servicio -> Modificar) para asignarle el tiempo que deseemos.
NOTA: Hay que tener en cuenta que estos cambios se perderán si se reinicia el servicio ICM, tal como notifica el siguiente mensaje:
Una de las opciones posibles para definir de manera definitiva esta parametrización es por medio de la creación del parámetro de perfil icm/server_port_<xx> a través de la transacción RZ10. Ejemplo:
icm/server_port_0 = PROT=HTTP,PORT=8000,TIMEOUT=30,PROCTIMEOUT=600
Los posibles valores vienen descritos en el link Timeout Options for ICM and Web Dispatcher.
Este parámetro se debe incluir en un fichero del sistema, por lo que deberá ser un administrador el que realice la configuración.
Links de referencia:
- Ken's SAP Basis Blog - Connection to partner timed out after 60s
- XI: Timeouts, timeouts, timeouts....
- How To... Investigate Timeouts In Synchronous XI/PI Scenarios
- Troubleshooting Guide - SAP Exchange Infrastructure 3.0 and 2.0
lunes, marzo 02, 2009
Cómo Eliminar un Componente del Integration Builder
Si por casualidad has importado desde el System Landscape Directory una versión de software de un componente por error y la deseas eliminar, deberás hacer doble clic sobre la misma y en la ventana del componente seleccionar la opción Software Component Version -> Delete (Ctrl+D).
martes, febrero 17, 2009
Convertir Workarea a Caracteres
En ocasiones es necesario pasar el contenido de un área de trabajo a una ristra de caracteres (sobre todo cuando se desea crear un fichero de texto a partir de una tabla interna con campos de distintos tipos). Para esos casos podremos utilizar la función estándar C147_WORKAREA_TO_CHARFIELD que nos simplificará mucho la vida.
viernes, enero 23, 2009
Campos de extensión de las BAPIs
Directamente copiado del texto de ayuda de los campos ExtensionIn/Out de las BAPIs:
Txt.brv.
ExtensionIn
Description
With the parameters ExtensionIn and ExtensionOut, it is possible to enhance the interface of a BAPI without modification to achieve the automatic processing of customer-specific data.
The data is passed on in a table. The format of the individual data records of this table is determined via the structure BAPIPAREX. This structure contains several data record fields (VALUEPART1, VALUEPART2 etc.) and a field for the name of an auxiliary structure (STRUCTURE). Because per data record the data is written piecewise consecutively to the data record fields available for the purpose, an auxiliary structure is needed for the interpretation of the data.
In the event that an SAP database table is to be enhanced by additional fields, BAPI table extensions are especially suitable as auxiliary structures. A BAPI table extension can either be already predefined by SAP or created by the customer. Examples of auxiliary structures and BAPI table extensions can be found at the following points:
Description of the various customer enhancement options
Enhancement of BAPI based on existing SAP database tables
Enhancement of BAPI through incorporation of additional customers' own database tables
Enhancement of BAPI by import data that does not show up the database level
Note that only fields of the data type CHAR and similar data types may be used in the BAPI parameter ExtensionIn/ExtensionOut.
If the customer Include contains deviating parameters, the configurable message ME 887 is invoked. However, the data is not adopted in the target structure from the container.
Default
The auxiliary structures have been defined as follows:
Header data:
BAPI_TE_MEOUTHEADER
BAPI_TE_MEOUTHEADERX
Item data:
BAPI_TE_MEOUTITEM
BAPI_TE_MEOUTITEMX
Account assignment data:
BAPI_TE_MEOUTACCOUNT
BAPI_TE_MEOUTACCOUNTX
Ejemplo:
Txt.brv.
ExtensionIn
Description
With the parameters ExtensionIn and ExtensionOut, it is possible to enhance the interface of a BAPI without modification to achieve the automatic processing of customer-specific data.
The data is passed on in a table. The format of the individual data records of this table is determined via the structure BAPIPAREX. This structure contains several data record fields (VALUEPART1, VALUEPART2 etc.) and a field for the name of an auxiliary structure (STRUCTURE). Because per data record the data is written piecewise consecutively to the data record fields available for the purpose, an auxiliary structure is needed for the interpretation of the data.
In the event that an SAP database table is to be enhanced by additional fields, BAPI table extensions are especially suitable as auxiliary structures. A BAPI table extension can either be already predefined by SAP or created by the customer. Examples of auxiliary structures and BAPI table extensions can be found at the following points:
Description of the various customer enhancement options
Enhancement of BAPI based on existing SAP database tables
Enhancement of BAPI through incorporation of additional customers' own database tables
Enhancement of BAPI by import data that does not show up the database level
Note that only fields of the data type CHAR and similar data types may be used in the BAPI parameter ExtensionIn/ExtensionOut.
If the customer Include contains deviating parameters, the configurable message ME 887 is invoked. However, the data is not adopted in the target structure from the container.
Default
The auxiliary structures have been defined as follows:
Header data:
BAPI_TE_MEOUTHEADER
BAPI_TE_MEOUTHEADERX
Item data:
BAPI_TE_MEOUTITEM
BAPI_TE_MEOUTITEMX
Account assignment data:
BAPI_TE_MEOUTACCOUNT
BAPI_TE_MEOUTACCOUNTX
Ejemplo:
CLEAR le_extensionin.
le_mepoheader-campo_extendido = <valor_del_campo>.
le_extensionin-structure = 'BAPI_TE_MEPOHEADER'.
le_extensionin-valuepart1 = le_mepoheader.
APPEND le_extensionin TO lt_extensionsin.
CLEAR le_extensionin.
le_mepoheaderx-campo_extendido = 'X'.
le_extensionin-structure = 'BAPI_TE_MEPOHEADERX'.
le_extensionin-valuepart1 = le_mepoheaderx.
APPEND le_extensionin TO lt_extensionsin.
CALL FUNCTION 'BAPI_PO_CREATE1'
EXPORTING
poheader = le_header
poheaderx = le_headerx
IMPORTING
exppurchaseorder = l_numdoc
TABLES
return = lt_return
poitem = lt_items
poitemx = lt_itemsx
poaccount = lt_accounts
poaccountx = lt_accountsx
extensionin = lt_extensionsin.
viernes, diciembre 19, 2008
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
- 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.
- 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
jueves, diciembre 04, 2008
Error al enviar mensajes de ECC a XI
Se puede dar la posibilidad de que al enviar un mensaje desde ECC a XI aparezca el error HTTP_RESP_STATUS_CODE_NOT_OK por problemas de autorización del usuario. Esto es común cuando se realizan "reseteos" de contraseñas generalizadas o se borran usuarios.
Para registrar de manera correcta al usuario, se deberá ir a "XI" (a pesar de que la conexión es ECC -> XI) y en la transacción SICF deberemos ir al nodo default_host -> sap -> xi -> engine y haciendo doble clic sobre engine, asignaremos el usuario correspondiente.
Para registrar de manera correcta al usuario, se deberá ir a "XI" (a pesar de que la conexión es ECC -> XI) y en la transacción SICF deberemos ir al nodo default_host -> sap -> xi -> engine y haciendo doble clic sobre engine, asignaremos el usuario correspondiente.
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.
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.
jueves, noviembre 20, 2008
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:
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:
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:
- 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:
- Por defecto, los mensajes SÍNCRONOS no se almacenan en XI para ahorrar espacio de almacenamiento.
- Hasta la versión PI 7.0 no hay manera directa de configurar XI para que guarde los mensajes síncronos procesados.
- 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.
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:
Uno de ellos es mediante el uso de herramientas externas específicas como lo son:
- SAP SOAP Client Tool
- Altova XML Spy
- SOAP Scope
- WS Unit from Java.net
- soapUI (como comentó Jorge Anibal)
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:
- How to Develop, Monitor and Debug WS Consumer and Provide
- XI/PI: A Guide to Using SAP XI SOAP Adapter
- How To… Use the XI 3.0 SOAP Adapter
- Testing sender web service Interfaces (SOAP) in PI 7.1
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:
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:
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:
- Publishing Interface as Web Service (Web Service to RFC)
- How To… Use the XI 3.0 SOAP Adapter
- Walkthrough - SOAP <-> XI <-> FC/BAPI
UDDI:
- WebAS : A step by step guide for Configuring UDDI registry on Local Server
- XI : How To publish WSDL generated from XI to 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.
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.
Suscribirse a:
Entradas (Atom)