Después de haber explicado ¿Qué son los Servicios Web (Web Services)? ahora vamos a ver como manejar los Servicios SOAP en SAP.
Para ello lo primero es diferenciar las dos roles que puede actuar nuestro sistema en base a una comunicación vía servicio web.
- Publicador: se trata del sistema que publica el servicio web y que espera ser llamado.
- Consumidor: se trata del sistema que consume un servicio web existente de otro sistema.
Y esto es importante porque en base a esto lo que tenemos que hacer en el sistema difiere.
Serie de Artículos sobre servicios SOAP en SAP
Este artículo pertenece a una serie de artículos sobre la gestión de servicios SOAP en SAP:
- Servicios Web SOAP en SAP – Publicar un servicio SOAP (Este artículo)
Publicar un Servicio Web SOAP
Publicar un servicio Web SOAP supone la creación de una puerta de entrada para que un sistema externo nos llame y nosotros realicemos la acción para la que esté hecho el servicio Web. Esta acción puede ser la consulta o búsqueda de datos en base a una entrada o bien la creación o modificación de registros o la ejecución de una acción en nuestro sistema. Sea cual sea la opción el proceso es similar. Veámoslo.
Modelo de datos
Vamos a poner un ejemplo, nos vamos a basar en el mismo modelo de datos que hemos usado en la serie de OData y SAP Gateway en la entrada «OData y SAP Gateway – II – Publicar un servicio OData en SAP«:
Módulo de Función de acceso remoto
Para publicar un servicio web SOAP lo primero que tendremos que hacer es un módulo de función que tenga la lógica que queramos implementar, con los parámetros de entrada/salida que queramos publicar para la ejecución de la lógica implementada.
En este ejemplo vamos a crear nuestro módulo de funciones de recuperación de datos del BP en base al modelo de datos que hemos visto anteriormente, lo llamaremos ZCRM_GET_BP_DATA. Y tendrá la siguiente estructura
Parámetros de Entrada
Parámetros de salida
En este caso contendrá la estructura de datos generales que tenga los datos de la BUT000 y las tablas de funciones, direcciones, relaciones e identificadores. Es importante destacar que, para que este módulo de función pueda ser usado como base para un servicio SOAP es necesario que sea de acceso remoto, por lo que todos los parámetros deben ser de Traspaso de Valores.
Módulo de función de acceso remoto
Importante es que ese MF esté marcado como de acceso remoto (RFC).
Lógica del Servicio Web
La lógica a aplicar, en este caso de consulta de bps, será algo sencillo. Recuperamos los datos de las tablas BUT000, BUT100, ADRC, BUT050 y BUT0IE.
Y, al ejecutar el Módulo de Función, vemos su resultado.
En este ejemplo hemos implementado una consulta de datos pero podemos hacer lo que queramos, al final es un Módulo de Función y puede hacerse creaciones, Borrados, actualizaciones o, como en este caso, consultas.
Wizard de creación del servicio
Una vez tengamos el Módulo de Función de acceso remoto tendremos que ir a la SE80 o bien pulsar el botón 
para acceder al repositorio.
Una vez en el repositorio buscamos nuestro MF en la lista y haciendo click derecho del ratón encima del Módulo de Función y accederemos a la opción «Crear->Enterprise Services» .
Y comienza el Wizard de creación del servicio SOAP. Lo primero en ponerle un nombre y descripción.
El siguiente paso es seleccionar el módulo de función, pero como hemos comenzado este wizard desde un Módulo de Función esto nos vendrá dado.
El siguiente paso es definir el perfil de seguridad del servicio. Esto nos permitirá, más adelante, en la SOAMANGER configurar unas opciones u otras de seguridad. Yo siempre elijo la LOW, que obliga al llamante a indicar usuario y password pero sin necesidad de hacer la comunicación con certificados entre máquinas. Para eso suele estar la gente de sistemas y seguridad que determinan los sistemas que pueden entrar.
Por último tenemos que seleccionar el paquete y la orden de transporte. En este ejemplo lo he puesto como objeto local porque es una prueba.
Al finalizar el Wizard nos aparecerá la definición del servicio.
Donde además veremos la estructura y tipo de datos de Entrada/Salida del servicio (que son los del módulo de función).
Tenemos que guardar y activar este servicio creado y con esto hemos terminado la primera parte, pero todavía no es accesible este servicio desde fuera, porque nos falta crear en Endpoint o puerto lógico de acceso.
SOAMANAGER
Ya tenemos el Servicio a nivel técnico creado, pero tenemos que publicarlo. Para publicarlo y crear el Endpoint con sus opciones tenemos la herramienta SOAMANAGER en SAP. Para acceder a la SOAMANAGER, la forma más sencilla es introducir la transacción SOAMANAGER en el SAP GUI.
Una vez aquí veremos muchas opciones. Para poder publicar un servicio SOAP tendremos que ir a la opción «Web Service Configuration» y ahí nos saldrá un buscador de servicios tanto de Publicador como de Consumidor.
En esta aplicación podemos buscar servicios publicados (Service Definition) o Servicios a consumir (Consumer Proxy). En este caso buscamos nuestro servicio creado en la SE80 usando el Object Type «Service Definition».
Pulsamos en nuestro servicio creado en la SE80 para acceder a su configuración,.
Cuando accedemos a él veremos que no tiene ningún Service/Binding creado, esto es la creación de Endpoints o puestas de entrada al servicio. Como no tenemos ninguna pulsamos al botón Create Service.
Y empezará un nuevo Wizard. En la primera pantalla le datos un nombre al Servicio a publicar (habitalmente le pongo el mismo que el nombre del servicio creado en la SE80), una descripción y un nombre al Binding o puerto lógico para construir el Endpoint.
En el siguiente paso, nos aparecerán las opciones dependiendo lo que hayamos configurado en el wizard de creación del servicio de la SE80. En mi caso tengo la opción de seleccionar que es necesario usuario y contraseña para poder acceder. Si vuestro departamento de sistemas o de seguridad os pide algo más sería en la creación del servicio y aquí donde hay que afinar.
Los siguientes pasos no hay que hacer nada. Finalizamos el wizard.
Una vez publicado el Servicio y creado el Endpoint tendremos disponible el WSDL para mandárselo al consumidor del servicio web que corresponda. Como vimos en la entrada:
El fichero WSDL (Web Services Description Language) es un fichero para describir la estructura y el uso de un servicio web SOAP. Este fichero puede estar disponible vía URL o como fichero plano. Pero siempre es mucho más recomendable que sea vía URL porque puede tener dependencias con otros ficheros XSD (XML Schema Definition). Para acceder a la URL del WSDL del endpoint recién creado de nuestro servicio pulsamos en este icono.
Y veremos en la parte inferior, en el campo WSDL URL for Binding la URL para acceder al WSDL. Nota: Si hemos puesto que necesitamos Usuario y Contraseña para que alguien consuma el servicio también lo necesitará para consultar el WSDL.,
Si copiamos la URL y la abrimos en un navegador veremos un archivo XML de esta forma.
La importancia del WSLD
El archivo WSDL es fundamental para el correcto uso de un web service SOAP, sea cual sea la tecnología. Define las operaciones disponibles, los tipos de datos de entrada y salida, y el protocolo de comunicación. Esto permite que cualquier sistema que consuma el servicio entienda cómo interactuar con él.
El WSDL contiene:
- Tipos de datos: Estructuras que se envían y reciben, así como los tipos de datos y longitudes. Esto es de suma importancia porque SAP es muy estricto en esto (y otros sistemas se ve que no) y si recibe algo que no se acoge a la definición da error en la entrada.
- Mensajes: Solicitudes y respuestas entre el cliente y el servicio.
- Operaciones: Acciones que el servicio web puede ejecutar.
- Bindings: Protocolo de comunicación y formato de los mensajes (SOAP/HTTP).
- Puertos/Servicios: La URL para acceder al servicio y sus modos de seguridad.
Al compartir el WSDL, se facilita la integración y se garantiza que diferentes sistemas puedan comunicarse correctamente con el servicio, independientemente de su plataforma o lenguaje de desarrollo.
Conclusión y Siguientes Pasos
En una entrada posterior vamos a ver cómo manejar el WSDL para poder hacer pruebas sobre servicios web publicados por nosotros en SAP o consumidos de otros sistemas externos. Con lo que continuaremos esta entrada sobre la publicación de servicio SOAP en SAP añadiendo la gestión de errores y logs, las formas de probar los servicios, etc.
Además otro de los apartados importantes será Cómo consumir un servicio web SOAP de un sistema externo en SAP. A
Jorge Ocampos 