Etiqueta: Web Services

Servicios Web SOAP en SAP – Publicar un servicio SOAP

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:

Tipos de archivos

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:

  1. 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.
  2. Mensajes: Solicitudes y respuestas entre el cliente y el servicio.
  3. Operaciones: Acciones que el servicio web puede ejecutar.
  4. Bindings: Protocolo de comunicación y formato de los mensajes (SOAP/HTTP).
  5. 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

OData y SAP Gateway – IV – Opciones sobre Entidades y Campos

En la entrada anterior de esta serie de artículos sobre OData ‘OData y SAP Gateway – II – Publicar un servicio OData en SAP‘ creamos un servicio muy básico de consulta de Businsess Partners, posteriormente añadimos la recuperación de Subentidades. Pero ahora toca para un poco, y saber las opciones de configuración del servicio Gateway. Se viene artículo denso, meramente informativo, pero necesario para sentar las bases.

Serie de Artículos sobre OData

Este artículo pertenece a una serie de artículos que se van complementando poco a poco como itinerario de conocimiento:

Opciones a nivel Modelo de Datos

Tenemos diversas opciones cuando estamos visualizando el modelo de datos, esto nos da una lista de Entidades y, para cada una de ellas, tenemos diversas opciones de configuración.

Donde tenemos las opciones de configuración:

  • Name: Indica el nombre de la entidad.
  • ABAP Structure: La estructura ABAP subyacente que define los campos y tipos de datos de la entidad. Utilizada para mapear los datos de la entidad a una estructura ABAP correspondiente en el backend.
  • Base Type: El tipo base del cual hereda la entidad, esto es utilizado en escenarios de herencia, donde una entidad puede extender otra entidad.
  • Is Abstract: Indicador de si la entidad es abstracta. Las entidades abstractas no pueden instanciarse directamente y se utilizan como base para otras entidades.
  • Label: El nombre legible o etiqueta de la entidad sirve para darle un nombre más amigable para los usuarios finales.
  • Label Editor: Herramienta para editar la etiqueta.
  • Semantics: Define el propósito de los datos contenidos en la entidad, ofreciendo un contexto adicional para entender cómo se deben utilizar e interpretar esos datos. Algunos ejemplos comunes de semántica en las entidades podrían ser CRM, HR, Clientes, Transaccional, etc. Estos términos ayudan a categorizar y definir el contexto de los datos. La ayuda del campo habla de propiedad y los valores posibles también, pero es un error, a nivel de entidad se usa para categorizar el propósito,
  • Thing Type: Checkbox que se selecciona para indicar si un tipo de entidad es una «cosa» (thing) en lugar de un objeto subordinado. En nuestro ejemplo el «objeto» serían los BusinesPartner y los objetos subordinados las entidades subordinadas.
  • Media: Especifica que el objeto de datos pertenece a una colección de medios. Este campo se utiliza para indicar que el tipo de entidad tiene un recurso de medios. Por ejemplo si tuviesemos una entidad Attachment.
  • As Author Property: No es necesario, es parte del estándar AtomPub, que se utiliza para publicar y editar recursos en un servidor web, el servidor se encarga de completar el campo atom:author utilizando la información del usuario autenticado.
  • As ETag Property: Tampoco es necesario, se refiere a una propiedad en una entidad que se utiliza para la gestión de la concurrencia optimista en SAP Gateway. ETag (Entidad Tag) es un mecanismo que ayuda a prevenir conflictos durante actualizaciones concurrentes de los datos. El atributo ETag no necesita ser proporcionado por el cliente, ya que el servidor genera y gestiona este valor automáticamente. El ETag se utiliza para asegurar que las operaciones de actualización y eliminación solo se realicen si la versión de la entidad no ha cambiado desde que fue leída por el cliente.
  • As Published Property: El campo As Published Property se refiere a una propiedad específica en una entidad que se utiliza para almacenar la marca de tiempo (fecha y/o hora) en que el elemento fue publicado por primera vez. Este es un elemento del Protocolo de Publicación Atom (AtomPub) llamado atom:published
  • As Title Property: Se refiere a un elemento en el Protocolo de Publicación Atom (AtomPub) llamado atom:title. Indicará la propiedad que usaremos como texto que transmite un encabezado legible por humanos (título) para un nuevo miembro de la colección.
  • As Updated Property: Es como «As Published Property» pero con la fecha/hora de ultima actualización. Es un elemento del Protocolo de Publicación Atom (AtomPub) llamado atom:updated.

Opciones por entidad y propiedades

Si pulsamos en una entidad, y vamos a ver sus propiedades, vemos que, por cada campo, tenemos varias opciones para ser configuradas. Estas opciones serán las que marquen el comportamiento de dicho campo en dicha entidad en el Servicio OData.

Las opciones de configuración son:

  • Name: Nombre de la propiedad o campo de la entidad, el identificador único del campo dentro de la entidad.
  • Is Key: Marca de si la propiedad es clave en la entidad, indica si el campo es una clave primaria para la entidad. Esto es importante para el uso del servicio y para relacionar dicha entidad con otras subordinadas.
  • Edm. Core Type: Tipo de datos, el tipo de datos en el modelo de datos de entidad (EDM), como Edm.String, Edm.Int32, etc.
  • Precision: Precisión del campo, número de dígitos totales que el campo puede tener.
  • Scale: Escala del campo, número de dígitos que el campo puede tener a la derecha del punto decimal.
  • Max Length: Longitud máxima, la longitud máxima del campo, aplicable principalmente a tipos de datos string.
  • Unit Property Name: Nombre de la propiedad de unidad, campo relacionado que especifica la unidad de medida para este campo (por ejemplo, metros, kilogramos).
  • Creatable: Indicador de que la propiedad puede ser Creada, permite la asignación de valor a esta propiedad en solicitudes de creación (POST).
  • Updatable: Indicador de que la propiedad puede ser Actualizada, permite la asignación de valor a esta propiedad en solicitudes de actualización (PUT/PATCH).
  • Sortable: Indicador de que la propiedad puede ser Ordenada, permite que este campo sea utilizado en sentencias $orderby para ordenar datos.
  • Nullable: Indicador de que la propiedad puede ser Nula, permite que esta propiedad tenga un valor nulo. Por ejemplo, algo que da muchas veces error son las fechas a ‘00000000’, para que funcione correctamente tenemos que poner este indicador.
  • Filterable: Indicador de que la propiedad puede ser Filtrada, permite que esta propiedad sea utilizada en sentencias $filter para filtrar datos.
  • Label: Etiqueta descriptiva de la propiedad, un nombre descriptivo utilizado en interfaces de usuario o documentación.
  • Label Editor: Editor de la etiqueta de la propiedad, herramienta para editar y gestionar el texto de la etiqueta, incluyendo referencias a textos traducibles.
  • Complex Type Name: Nombre del tipo complejo, si la propiedad es de un tipo complejo, este es el nombre del tipo complejo.
  • ABAP Field Name: Nombre del campo en ABAP, el nombre del campo correspondiente en ABAP.
  • ABAP Type: Tipo de datos en ABAP, el tipo de datos ABAP correspondiente (por ejemplo, CHAR, NUMC, DATS).
  • Semantics: Semántica del campo, describe el propósito o la función del campo en un contexto más amplio, proporcionando significado adicional sobre su interpretación y uso.

Opciones por EntitySet

A nivel de EntitySet podemos elegir el comportamiento de cada entidad. Tendremos las siguientes opciones:

  • Name: Nombre del EntitySet. El nombre del conjunto de entidades utilizado en las URIs para acceder a las entidades del conjunto.
  • Entity Type Name: Nombre de la Entidad en la que se basa el EntitySet. El nombre del tipo de entidad que define la estructura y las propiedades de las entidades dentro del conjunto.
  • Label: Etiqueta descriptiva del EntitySet. Un nombre descriptivo utilizado en interfaces de usuario o documentación.
  • Label Text Reference Editor: Editor de referencia de texto de la etiqueta. Herramienta para editar y gestionar el texto de la etiqueta, incluyendo referencias a textos traducibles.
  • Semantics: Semántica del EntitySet. Describe el propósito o la función del EntitySet en un contexto más amplio, proporcionando significado adicional sobre su interpretación y uso.

Opciones de capacidades y comportamiento de las Entidades OData

Sobre el resto de checks de este menú vamos a detenernos un poco más, puesto que son las opciones que marcarán el comportamiento y capacidades de nuestras entidades dentro de un proyecto OData. Estas opciones permiten una gran flexibilidad y control sobre cómo se pueden gestionar y acceder a los datos a través de servicios OData en SAP Gateway, mejorando tanto la seguridad como el rendimiento de las aplicaciones que consumen estos servicios.

Creatable

Indicador de que la entidad puede ser Creada.

  • Descripción: Cuando esta opción está seleccionada, indica que los clientes pueden crear nuevas entidades en el conjunto de entidades utilizando el método HTTP POST.
  • Uso: Permite operaciones de creación de entidades. Esto es útil cuando el servicio OData debe permitir la inserción de nuevos registros en la base de datos.

Updatable

Indicador de que la entidad puede ser Actualizada.

  • Descripción: Permite que las entidades dentro del conjunto sean actualizables utilizando el método HTTP PUT o PATCH.
  • Uso: Esencial para permitir modificaciones a los registros existentes en el conjunto de entidades. Los clientes pueden actualizar una entidad específica mediante su clave primaria.

Deletable

Indicador de que la entidad puede ser Eliminada.

  • Descripción: Permite que las entidades dentro del conjunto sean eliminadas utilizando el método HTTP DELETE.
  • Uso: Facilita la eliminación de registros específicos del conjunto de entidades. Esto es útil para gestionar la vida útil de los datos.

Pageable

Indicador de que la entidad admite paginación.

  • Descripción: Permite la paginación de los resultados de una consulta OData utilizando los parámetros $skip y $top.
  • Uso: Mejora el rendimiento y la usabilidad cuando se trabaja con grandes volúmenes de datos. Los clientes pueden solicitar subconjuntos de datos en cada llamada, lo que facilita la gestión de grandes conjuntos de datos.

Addressable

Indicador de que la entidad es direccionable.

  • Descripción: Permite que las entidades sean accesibles directamente mediante su clave primaria en la URI.
  • Uso: Los clientes pueden acceder a una entidad específica utilizando su URI, facilitando operaciones CRUD directas sobre entidades individuales.

Searchable

Indicador de que la entidad puede ser buscada.

  • Descripción: Permite realizar búsquedas en las entidades utilizando el parámetro de consulta $search.
  • Uso: Facilita la búsqueda de entidades que contienen ciertos términos, mejorando la experiencia del usuario al permitir consultas más complejas.

Subscribable

Indicador de que la entidad puede ser suscrita.

  • Descripción: Permite que los clientes se suscriban a cambios en el conjunto de entidades.
  • Uso: Útil para aplicaciones que necesitan notificaciones o actualizaciones en tiempo real cuando ocurren cambios en los datos.

Requires Filter

Indicador de que se requiere un filtro para acceder a la entidad.

  • Descripción: Obliga a que todas las consultas al conjunto de entidades incluyan un parámetro de filtro ($filter).
  • Uso: Restringe el acceso directo a las entidades, asegurando que las consultas sean más específicas y potencialmente mejorando el rendimiento al reducir el volumen de datos devueltos en cada consulta.

Opciones aplicadas en nuestro proyecto Gateway

Pues para nuestro proyecto Gateway ZODATA_TEST_BP, en base a los apartados de este artículo se han aplicado las siguientes opciones:

Opciones a nivel Modelo de Datos

A nivel de Modelo de Datos, es decir, de Entidad, la configuración aplicada es la siguiente:

Opciones por entidad y propiedades

Por Entidad, se configuran sus propiedades de la siguiente forma:

BusinessPartners

Por ahora no se puede crear (no lo hemos implementado), no se puede actualizar (idem) por lo que las propiedades no tiene sentido que las marquemos como Creatable o Updatabe. Marcamos todos los campos con la posibilidad de hacer SORT, eso podremos afinarlo cuando afinemos el método de GetEntitySet, por ahora ninguno puede ser nulo (que no es lo mismo que vacío), y marcamos para filtrar todos menos el nombre completo.

Address

Lo mismo de la creación y actualización. Marcamos como Nullable las fechas porque si no da un error de que la fecha no puede ser «» y marcamos los campos por los que pensamos ordenar y filtrar.

IdentNumbers

Lo mismo de la creación y actualización. Lo mismo de las fechas Nullable y los filtros.

Relation

Igual que las anteriores.

Roles

Igual que las anteriores.

Opciones por EntitySet

A nivel Set de Entidad, EntitySet, como por ahora no tenemos la actualización ni creación, le ponemos la paginación y la búsqueda y que la entidad de BusinessPartner requiere filtro.

En conclusión

Nuestro proyecto está en una fase muy inicial, solo es de búsqueda y recuperación de datos, por lo tanto muchas de estas opciones directamente no aplican. Pero creo que hemos hecho un repaso exhaustivo de las posibilidades, a nivel configuración de un proyecto Gateway. Importante, he dicho posibilidades a nivel configuración, la lógica la tendremos que implementar en la clase Z*DPC_EXT correspondiente.

Si te interesa, suscríbete al blog por email

¿Qué son los Servicios Web (Web Services)?

Como he dicho en muchos de los artículos, uno de los objetivos de este blog es aprender y enseñar lo que sé dentro del mundo SAP y de tecnología en general. En este caso vamos a ir a algo básico, pero no con ello conocido por todos. Es probable que haya mucha gente que ya sepa de lo que estoy hablando, pero seguro que hay algunos que les viene bien para sentar las bases. Vamos a hablar de:

¿Qué es un Servicio Web?

Café y cigarro, muñeco binario

Los servicios web son aplicaciones que se comunican y comparten datos e información a través de la red, utilizando un conjunto de estándares y protocolos abiertos. Están diseñados para soportar la interacción máquina a máquina, facilitando la interoperabilidad entre sistemas heterogéneos. Es decir, dos sistemas no necesitan conocerse para poder comunicarse mientras se acojan a las reglas de comunicación del estándar de servicio web usado. Puedes conectar un SAP con Java, Python, etc. Y cualquier tecnología que sepa manejar los Servicios web.

Vamos a verlo con una analogía. Por ejemplo la telefonía. Existen terminales con distintas tecnologías, fijos, fax, Android, IOS, etc. Pero todos pueden conectarse a la red y hacer y recibir llamadas, mensajes y datos. Cada tecnología usa un estándar de comunicación y, cuando haces una llamada no andas pensando si el que recibe la llamada es Android, IOS o fijo.

Sistemas como Cajas Negras

Y para conseguir entenderlo del todo e intentar bajar a tierra el concepto, podemos simplificarlo viendo a los sistemas como Cajas Negras.

Imagina que cada sistema o aplicación es como una casa grande y compleja, llena de diferentes habitaciones. Cada habitación contiene algo valioso: información, herramientas, o incluso formas de interactuar con el mundo exterior. Pero para acceder a estos tesoros, necesitas entrar por la puerta correcta.

Los servicios web son como estas puertas. Cada puerta está diseñada para un propósito específico: algunas te permiten ver lo que hay dentro (consultar datos), otras te permiten cambiar algo (modificar datos), otras te permiten agregar cosas nuevas (introducir nuevos datos) o incluso eliminar algo existente.

Cuando usas un servicio web, es como si tuvieras la llave correcta para abrir una de estas puertas. Lo interesante es que estas puertas pueden estar en cualquier parte del mundo. No importa dónde estés, si tienes la llave correcta (en este caso, el acceso al servicio web adecuado y la forma de llamarlo), puedes abrir la puerta y hacer lo que necesites hacer.

Por ejemplo, cuando usas una aplicación en tu teléfono para consultar el clima, estás utilizando un servicio web para «abrir la puerta» de un sistema que te proporciona información meteorológica actualizada. O cuando haces un pedido en línea, estás usando otro servicio web para «abrir la puerta» de un sistema de comercio electrónico, permitiéndote agregar productos a tu carrito y realizar una compra.

Ejemplo «Real»

Imagínate que tienes un sistema SAP de gestión comercial y de creación con clientes (CRM) y quieres que cualquier sistema que ‘capte’ posibles futuros clientes, cree una ficha de datos y un documento para que un comercial le contacte. Por ejemplo, una persona da sus datos en una web o cuando una persona se da de alta en otra empresa del grupo pero cede sus datos para fines comerciales.

En SAP podemos crear un servicio web que permita recibir:

  • Nombre
  • Apellidos
  • Email
  • Telefono
  • Id externo

Cuando el servicio web reciba esta información, internamente, ya en SAP, creará el BP y el documento de seguimiento. Y el servicio devolverá:

  • Id BP SAP
  • Id Documento Seguimiento

¿Qué sistemas llamarán a este Servicio Web? Pues cualquiera que:

  • Tenga acceso a la Máquina de SAP (por Red, firewall y Autenticación)
  • Sepa llamar al servicio

En este caso la web y el sistema que gestione la otra empresa. ¿Qué tecnologías son? Da igual, ¿es HTML? ¿PHP? ¿Java? ¿SAP? ¿. NET? Da lo mismo, mientras que sepa como llamar y tenga visibilidad. Y quienes quieran llamar en un futuro claro.

Tipos de Web Service

Existen varios tipos de servicios web, pero los más comunes son:

SOAP (Simple Object Access Protocol)

SOAP es un protocolo estándar que permite la comunicación entre aplicaciones a través de redes, utilizando XML para codificar los mensajes.

Archivo WSDL (Web Services Description Language)

Los servicios SOAP cuentan con un archivo de definición del servicio en formato XML que el sistema que lo crea lo genera y se lo entrega a cualquier sistema que quiera usarlo. En ese documento está definido todas las acciones, estructuras de mensajes entrada / salida y los tipos de datos de cada campo.  De esa forma, cualquier sistema que quiera usar ese servicio web no necesita conocer el sistema destino, solamente debe saber generar y recibir ficheros XML en base a las especificaciones del WSDL.

Seguridad en SOAP

A nivel de seguridad tenemos muchas opciones o capas de seguridad para el uso de los servicios web SOAP:

  • WS-Security: es una extensión de SOAP para abordar la seguridad en la comunicación de servicios web. Permite Autenticación mediante tokens de seguridad como contraseñas, tokens SAML, y certificados X.509.
  • SSL/TLS: Aunque no es específico de SOAP, el uso de SSL (Secure Socket Layer) o TLS (Transport Layer Security) añade una capa adicional de seguridad al encapsular la comunicación SOAP en un canal seguro.

REST (Representational State Transfer)

REST no es un protocolo sino un conjunto de principios arquitectónicos para diseñar servicios web. REST utiliza métodos HTTP como GET, POST, PUT y DELETE para operaciones CRUD (Crear, Leer, Actualizar, Eliminar), lo que lo hace intuitivo y fácil de usar.  Los datos y la funcionalidad se consideran «recursos» y se accede a ellos a través de URIs (Uniform Resource Identifiers).

El formato de intercambio más habitual es mediante JSON (JavaScript Object Notation) que es un formato ligero de intercambio de datos. Es fácil de leer y escribir para humanos, y fácil de analizar y generar para máquinas. Aunque también puede usar XML, HTML O texto plano.

Ventajas de REST

  • Eficiencia y Escalabilidad: REST permite manejar un gran número de solicitudes simultáneamente, lo que lo hace muy escalable.
  • Facilidad de Uso: Al usar estándares HTTP, es fácil de entender y utilizar para los desarrolladores.
  • Flexibilidad: Permite el uso de múltiples formatos de datos como JSON, XML, texto plano, etc., lo que lo hace versátil.

Desventajas

  • Seguridad: La seguridad en REST debe ser manejada cuidadosamente, ya que no proporciona estándares de seguridad integrados como SOAP.
  • Limitaciones en Solicitudes Complejas: Para operaciones que requieren un procesamiento más complejo o transacciones, REST puede ser menos adecuado que otras tecnologías como SOAP.

OpenAPI (Swagger)

OpenAPI es un estándar ampliamente aceptado para describir servicios web RESTful. Permite a los desarrolladores definir toda la API (endpoints, operaciones, parámetros, respuestas, etc.) en un formato estructurado (generalmente YAML o JSON). Proporciona una interfaz gráfica muy visual donde además se pueden probar los servicios.

OData, la Evolución de REST

Sobre este tipo de servicios web ya tenemos un artículo en el blog. Así que no me voy a repetir.

OData y SAP Gateway

Comparativa entre SOAP y REST

Son dos tipos de Servicios Web distintos, hay otros pero son los más usados, a pesar de que el REST es relativamente más moderno, no implica que sea mejor o que SOAP sea obsoleto. Cada uno tiene sus ventajas e inconvenientes y sus usos recomendados.

Naturaleza

  • SOAP: Es un protocolo estándar más estricto.
  • REST: No es un protocolo sino un conjunto de principios arquitectónicos.

Formato de Mensaje

  • SOAP: Utiliza XML exclusivamente.
  • REST: Puede usar varios formatos como JSON, XML, HTML, texto plano.

Seguridad

  • SOAP: Ofrece una mayor seguridad con estándares como WS-Security. Mejor para operaciones que requieren un alto nivel de seguridad.
  • REST: La seguridad depende del transporte (como HTTPS). Menos robusto en comparación con SOAP.

Uso de Recursos

  • SOAP: Requiere más ancho de banda y recursos debido a su estructura XML más detallada.
  • REST: Generalmente más ligero, usando JSON, lo que lo hace más rápido y eficiente en términos de uso de la red.

Operaciones

  • SOAP: Ideal para operaciones complejas y con necesidades de transacciones ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad)..
  • REST: Adecuado para operaciones más simples y solicitudes de estado. Aunque con OData las posibilidades de «complicar» las operaciones relacionando entidades aumentan su complejidad.

Usos Comunes

  • SOAP: Preferido en entornos empresariales. Utilizado para operaciones que requieren un alto nivel de fiabilidad y seguridad, como transacciones financieras.
  • REST: Ampliamente utilizado en aplicaciones web y móviles por su simplicidad y facilidad de uso.Ideal para servicios que requieren escalabilidad y rendimiento, como redes sociales, servicios en la nube.

Flexibilidad

  • SOAP: Menos flexible en términos de formatos y enfoques.
  • REST: Más flexible y fácil de usar. Permite una mayor escalabilidad.

Conclusión

  • SOAP es más adecuado para operaciones que necesitan un alto nivel de seguridad y transacciones complejas, comúnmente usado en entornos corporativos y empresariales.
  • REST es preferido para aplicaciones que requieren una mayor escalabilidad y rendimiento, siendo más flexible y fácil de implementar, lo que lo hace ideal para aplicaciones web y móviles modernas.

Cada uno tiene sus fortalezas y es importante elegir el enfoque correcto basado en los requisitos específicos del proyecto y del entorno en el que se va a utilizar.

Así he hecho yo mi carrera