Categoría: SAP

Transportes en SAP – ¿Qué son las Órdenes de Transporte?

Vamos a explicar otro de los temas básicos pero no por ello dominados totalmente y, seguro, todos aprenderemos algo, tanto el nuevo en el mundo SAP, como el senior. En esta serie de artículos hablaremos de los transportes en SAP.

Y el primero de esta serie será acerca de qué son las órdenes de transporte. En primera instancia hablaremos de los transportes clásicos, no hablaremos de transportes de las nuevas herramientas SAP como Build Apps, Sales Cloud, BTP, Fiori, Ariba, Success Factors, etc…

¿Qué es una orden de transporte en SAP?

Una orden de transporte es un contenedor que almacena todos los cambios transportables realizados en un sistema SAP. Estos cambios pueden incluir configuraciones, desarrollos de ABAP, personalizaciones y cualquier otra modificación en el sistema. Las órdenes de transporte garantizan que los cambios realizados en un entorno de desarrollo se puedan mover de manera controlada y segura a los entornos de pruebas y producción.

Mete tus objetos en el camión, que va a salir ya

¿Cómo se crean las Órdenes de transporte?

Pues hay dos formas de crear órdenes de transportes en el sistema.

Creación automática

Cuando se realiza una modificación en el sistema, dicha modificación pide guardarse una orden de transporte.

Pudiendo, en este popup, crear una nueva orden de transporte o seleccionar una ya existente. Al pulsar a crear una nueva nos saldrá un nuevo popup donde indicar la descripción. Y el sistema creará la orden automáticamente.

Esta es la forma más básica de crear una orden de transporte, la más básica pero también la más controlada, puesto que el sistema se encarga de meter la modificación realizada en la orden que has seleccionado. Obviamente puedes seleccionar una orden que ya exista, lo cual es lo habitual.

Pongamos un Ejemplo de creación de orden de transporte

Imagínate que estás realizando un proyecto para implantar una funcionalidad concreta, por ejemplo un proceso nuevo de Ventas Online. Cuando realices la primera configuración al respecto te pedirá una orden de transporte, pero no la habrás creado inicialmente, y podrás crearla en el momento, para lo cual lo único que tendrás que hacer es ponerle un nombre. Pero para las siguientes configuraciones, te volverá a pedir la orden de transporte, pero ya no tendrás que crearla, solo seleccionar la que creaste anteriormente, que será la que aglutine todas las configuraciones de tu funcionalidad.

Creación manual

Sin embargo, aunque sea menos habitual, también podemos crearla directamente en la transacción SE10 que veremos posteriormente. Esto es especialmente útil cuando necesitamos trabajar con los objetos de una funcionalidad concreta para agruparlos, realizar transportes de copias, depurar errores, etc. Todo esto lo veremos a continuación.

Id de las Órdenes de Transporte

Los Ids de órdenes y tareas son consecutivos y se forman de la siguiente forma <SID>K9<Número> Donde:

  • <SID> es el Id del sistema
  • K9<Número> – Es un número consecutivo del rango, que se construye del K900000 al K999999 (esto se puede ver en la tabla E070L).

Por lo tanto, si tu id de sistema de desarrollo es JOD una orden de transporte podría tener por id JODK9001627.

Tipos de Órdenes de Transporte

Y es que existen varios tipos de órdenes de transporte que, cada una tiene su razón de ser y su funcionalidad. Los tipos pueden agruparse en dos grupos, dependiendo de su funcionalidad.

Órdenes de Transporte sobre cambios en el sistema

Estas son las órdenes de transporte habituales, las que se crean automáticamente cuando realizamos un cambio en la configuración o los objetos técnicos del sistema. Pero precisamente esa distinción es la que hace SAP de cara a organizar los dos tipos de órdenes de transporte:

  • W – Customizing: Las órdenes de Customizing son las que contienen las modificaciones sobre el Customizing del sistema, es decir, sobre la modificación de los parámetros del menú de configuración (SPRO – IMG).
  • K – Workbench: Las órdenes de Workbench son las que contienen las modificaciones sobre los objetos del repositorio técnico. Código, modificaciones sobre objetos del diccionario de datos (Tablas, Vistas, Elementos de datos, Dominios, Estructuras, Tipos Tabla, etc.). Por resumir a algo que entendamos todos, guarda todas modificaciones o creaciones de objetos técnicos dentro de Paquetes.

Órdenes de Transporte para realizar gestiones

Existen otros tipos de órdenes de transporte además de las básicas de Customizing y Workbench. Obviamente, como órdenes de transporte que son. contienen también los objetos que han sufrido cambios en el sistema, pero quería separarlo para que se entendiese que su propósito es ligeramente diferente.

  • T – Transporte de Copias: Las ordenes de transporte de copias sirven para transportar modificaciones de objetos (Customizing o Workbench) de un sistema a otro sin necesidad de transportar la orden de transporte original que contiene esa modificación. Tiene las siguientes características:
    • No se catalogan como Customizing o Workbench, pudiendo contener objetos de ambos tipos.
    • Su ciclo de vida de transporte solo sirve para hacer un transporte de un sistema al siguiente, pero no se quedan pendientes en la cola del siguiente sistema.
    • Se deben crear siempre de forna manual. Teniendo que incluir los objetos en ellas o manualmente o incluyendo los objetos desde otras órdenes.
    • Se utilizan principalmente para transportar objetos de un sistema al siguiente pero manteniendo los objetos bloqueados en las órdenes originales. Esto ayuda a pasar funcionalidades al entorno de Test, manteniendo las órdenes originales en desarrollo, poder probar la funcionalidad y, cuando se quiera pasar a Producción, pasar las órdenes originales sabiendo que esa funcionalidad está probada. Esto evita tener que pasar a Producción muchas versiones de órdenes con correcciones y solo pasar las órdenes definitivas.
  • Traslados (Relocations): Se trata de un tipo de orden de transporte que yo en 17 años no he tenido que usar nunca. He estado investigando, pero no puedo aportar valor añadido aquí, por lo que prefiero no ahondar en este punto. Si necesitais algo de información en esta entrada del la help de SAP hay algo de información. Transports of Copies and Relocations

Estructura de una orden de transporte

Por lo general una orden de transporte comprende de un nivel superior que es la orden de transporte propiamente dicha, y de 0 a n Tareas.

  • Id Orden de Transporte – Usuario – Descripción
    • Id Tarea 1 – Usuario
      • Objetos bloqueados en la tarea
    • Id Tarea 2 – Usuario
      • Objetos bloqueados en la tarea
En este caso solo hay una tarea porque solo hay un usuario tocando los objetos

Y digo, por lo general, porque también puedes encontrar órdenes sin Tareas, pero esto sería dado por alguna manualidad.

¿Todos los cambios se guardan en una orden de transporte?

No, y cuidado con esto, hay configuraciones (Customizing) que no se guardan en órdenes de transporte. Se tratan de las configuraciones independientes de mandante. ¿No sabes lo que es un mandante? Revisa esta entrada.

SAP Mandante (Cliente)

El caso es que puede haber Customizing que no se graba en orden de transporte (el sistema te avisará) y actualizaciones de tablas que no requieran transporte (el sistema no te avisará).

¿Para qué sirven las órdenes de transporte?

Pues para transportar objetos y configuración de un sistema a otro ¿no?. Por supuesto, pero no solo para eso. Vamos a ver la utilidad de las órdenes de transporte.

Transportar objetos y configuración de un sistema a otro

Es la función principal, lo que les da nombre, y que desgranamos en futuros artículos.

Gestión de versiones

Permiten llevar un control de las versiones de los objetos, asegurando que se pueden gestionar y revertir cambios si es necesario.

Cada vez que se transporta una orden de transporte de desarrollo al sistema destino se guarda la versión transportada, de esa forma, se pueden ver todas las versiones pasadas e incluso recuperar una versión que se requiera.

Bloqueo de objetos y control de modificaciones

Aseguran que los objetos que se están modificando no puedan ser alterados por otros desarrolladores simultáneamente, evitando conflictos y asegurando la coherencia de los cambios.

Cuando un desarrollador modifica un objeto se guarda en una orden de transporte y se «bloquea». Cuando otro. Desarrollador modifica posteriormente el mismo objeto, al guardar la modificación le dirá que el objeto ya está bloqueado en una orden de transporte y que está no es suya, que se creará una tarea dentro de la orden del compañero. Esto asegura:

  • Que el segundo desarrollador sabe que el objeto modificado ya fué modificado por un compañero
  • Que el primer desarrollador sabe que el segundo ha tocado un objeto bloqueado, en una primera instancia por él, viendo que en su orden de transporte hay una tarea del segundo desarrollador.

Es importante indicar que esto sólo sucede con los objetos Workbench ya que el customizing son registros en tablas.

Auditoría

Las órdenes de transporte proporcionan un registro detallado de quién hizo qué cambios, cuándo y cómo, lo que es esencial para auditorías y revisiones de seguridad.

Transacciones para gestionar órdenes de transporte

Para gestionar las órdenes de transporte tenemos varias transacciones disponibles.

SE10 – Transport Organizer

Es que yo más uso, es mi punto de entrada para revisar y gestionas la órdenes de transporte. Siempre se ejecuta por un usuario, pudiendo ver todo poniendo un asterisco *. Además puede seleccionar ver unos tipos de órdenes u otros y según su estado (Modificable/Liberadas).

Una vez dentro veremos, por cada entorno, tipo, sistema destino y estado, las órdenes de transporte con sus tareas y objetos.

Esta transacción es la principal de gestión de las ordenes de transporte y la veremos con detenimiento en un artículo concreto, porque da para mucho contar.

SE01 – Transport Organizer (Ampliado)

Se trata de una transacción de varias herramientas, puedes buscar directamente por un Id de Orden de transporte o realizar distintos tipos de búsqueda. Yo suelo usar la SE10 para todo.

Logo retro

SE03 – Herramientas del Transport Organizer

Esta transacción es muy importante, contiene herramientas para poder gestionar casos especiales al respecto de órdenes de transporte. No podemos detenernos ahora en todo ello así que intentaré desgranarlo en una entrada aparte.

STMS – Transport Management System

Se trata de la transacción para la gestión de los transportes de la ordenes de un sistema a otro.

Logo retro con colorinchis

Obviamente, la gestión del transporte de las órdenes es uno de los puntos clave, y requiere estudiarlo pormenorizadamente. Lo haremos en esta serie.

Conclusión

Esta primera entrada hemos abortado qué es una orden de transporte, los tipos, como se crean, su estructura básica y su utilidad. Seguiremos viendo en esta serie cómo trabajar con las órdenes de transporte y, en definitiva, cómo transportar objetos y customizing de un sistema a otro.

SAP Activate: Metodología Ágil para Implementar Soluciones SAP

Anteriormente hemos visto dos de las metodologías de gestión de Proyectos más usadas actualmente.

Ahora vamos a ver una metodología de gestión de proyecto propia de SAP para el paso ágil a SAP S/4HANA. Vamos a ver SAP Activate.

¿Qué es SAP Activate?

SAP Activate es una metodología que ha sido desarrollada por SAP allá por el 2015 (Sí, 9 años he tardado en escribir esto) para proporcionar un enfoque estandarizado y ágil para implementar soluciones SAP. Este enfoque incluye las mejores prácticas, metodologías ágiles y herramientas de última generación para ayudar a las organizaciones a implementar soluciones SAP de manera más rápida y eficiente, minimizando los riesgos y maximizando el retorno de la inversión.

Si te quieres ahorrar leer este artículo hay varias referencias oficiales y/o útiles para conocer esto del SAP Activate.

Elementos principales

SAP Activate es una metodología compuesta por tres elementos principales:

Best Practices (Mejores Prácticas)

SAP ha compilado una serie de mejores prácticas que son específicas para diferentes industrias y procesos. Estas mejores prácticas son plantillas de configuración que permiten a las empresas implementar sus soluciones más rápidamente y con menos riesgos.

Para ello tenemos el SAP Best Practices Explorer (requiere usuario de support SAP).

Guided Configuration (Configuración Guiada)

Se refiere a las herramientas y recursos que SAP proporciona para facilitar la configuración de las soluciones. Esta configuración guiada permite que las organizaciones configuren sus sistemas de manera ágil, asegurando que se adhieran a las mejores prácticas y a los estándares de la industria.

Agile Methodology (Metodología Ágil)

SAP Activate adopta un enfoque ágil para la implementación de soluciones, lo que permite a las organizaciones adaptar y ajustar sus procesos durante el proyecto, en lugar de seguir un enfoque rígido y secuencial.

Fases de SAP Activate

La metodología SAP Activate, como se ha comentado anteriormente, es una metodología Ágil y está organizada en seis fases clave:

Discover (Descubrimiento)

En esta fase, se analiza la viabilidad del proyecto. Las organizaciones evalúan las soluciones disponibles, identifican sus necesidades y definen el valor que pueden obtener de la implementación de SAP.

Prepare (Preparación)

En esta fase se establecen los fundamentos del proyecto, incluyendo la formación del equipo, la planificación inicial y la preparación de los recursos necesarios.

Explore (Exploración)

En esta fase, se realiza un análisis detallado de las necesidades del negocio y se exploran las diferentes soluciones de SAP que pueden satisfacer esas necesidades. Las configuraciones iniciales también se establecen durante esta fase.

Realize (Realización)

Esta es la fase de ejecución, donde las soluciones se configuran, prueban y ajustan según los requisitos del negocio. Los datos se migran y se realizan pruebas exhaustivas para asegurar que todo funcione según lo planeado.

Deploy (Despliegue)

En esta fase, la solución se pone en marcha en el entorno de producción. Se realizan pruebas finales, capacitaciones para los usuarios finales y se asegura que todo esté listo para la operación en vivo.

Run (Operación)

Una vez que la solución está en producción, comienza la fase de operación y soporte. SAP proporciona herramientas y recursos para monitorear el sistema, solucionar problemas y optimizar el rendimiento.

Herramientas ejecutar un proyecto SAP Activate

Para implementar un proyecto y seguir la metodología SAP Activate, SAP proporciona una serie de herramientas recomendadas para cada fase del proyecto.

SAP Solution Manager

¿Qué voy a decir de Solution Manager? Es una plataforma integral que proporciona soporte durante todo el ciclo de vida de las aplicaciones SAP, desde la implementación hasta el uso en producción. Facilita la gestión de cambios, pruebas, documentación de procesos, y el monitoreo de sistemas.

Todo esto sobre el papel está genial, lo que yo he solido usar no suele estar bien pensado o bien implementado.

SAP Cloud ALM (Application Lifecycle Management)

A grandes rasgos y como un resumen rápido podemos decir que es una heerramienta en la nube que soporta la gestión de proyectos y el ciclo de vida de las aplicaciones SAP, ideal para implementaciones en entornos Cloud.

SAP Best Practices Explorer

Se trata de un portal que permite explorar y acceder a las mejores prácticas de SAP específicas para diferentes industrias y procesos de negocio. Es esencial para la configuración inicial de soluciones SAP. Lo hemos visto en la parte de Elementos Principales de SAP Activate y podemos acceder a este portal en el SAP Best Practices Explorer.

SAP Central Business Configuration

Es una herramienta diseñada para configurar de manera centralizada los procesos de negocio en SAP S/4HANA Cloud, facilitando la adopción de SAP Best Practices.

Tricentis for SAP

Conjunto de herramientas para la automatización de pruebas dentro de proyectos SAP, que complementa la metodología SAP Activate asegurando calidad y estabilidad en las implementaciones.

SAP Roadmap Viewer

Una herramienta que proporciona una visión estructurada y personalizada de las hojas de ruta de implementación dentro de SAP Activate. Ayuda a los equipos de proyecto a seguir un plan claro y adaptado a las necesidades de su solución SAP. Podemos acceder a los Roadmaps disponibles en la web:

Welcome to SAP Activate
Roadmap Viewer

sap.com

SAP Signavio

Se trata de un conjunto de herramientas que facilita el modelado, gestión y optimización de procesos de negocio. Es particularmente útil en las fases de Explore y Realize de SAP Activate, donde se necesita entender y mejorar los procesos empresariales. Esto, en sí mismo, ya tiene miga como para explicarlo pormenorizadamente.

En conclusión

Lo que antes era la metodología de gestión de proyectos ASAP (Acelerated SAP) pasó a evolucionar a SAP Activate, siendo ambas opciones válidas, pero siendo Activate la idónea para entornos S/4Hana y tecnologías SAP modernas.

Yo, y supongo que casi todos, estoy mucho más acostumbrado a metodologías Waterfall como ASAP. Pero hay que estar atento las formas de gestión de proyecto que tenemos encima de la mesa para saber aprovecharnos de sus ventajas.

OData y SAP Gateway – V – Documentar y Probar con OpenAPI

Vamos a hacer un parón en el camino, entenderéis porqué, en el estudio de cómo manejar servicios web OData en SAP con SAP Gateway. Lo que vamos a implementar es una herramienta de documentación y pruebas muy potente para nuestros servicios OData en nuestro sistema SAP. Se trata de implementar la funcionalidad de OpenAPI (el antiguo Swagger) en nuestro SAP para que genere el aplicativo de documentación y pruebas.

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:

¿Qué es OpenAPI?

OpenAPI es una especificación que define un estándar para construir y describir interfaces de programación de aplicaciones (APIs). OpenAPI es una evolución del formato conocido anteriormente como «Swagger», aunque a veces ambos términos se usan indistintamente. Es ampliamente utilizado para APIs RESTful y permite a los desarrolladores y sistemas documentar y entender cómo interactuar con una API sin necesidad de ver su implementación interna.


Algunos puntos clave de OpenAPI:

  • Estandarización: Define un formato estandarizado para describir los endpoints de una API, incluyendo los métodos HTTP disponibles (GET, POST, PUT, DELETE, etc.), los parámetros de entrada, respuestas y errores que puede generar.
  • Documentación automática: Una de las características más útiles es que permite generar documentación automáticamente a partir de la descripción de la API, lo cual facilita su uso por otros desarrolladores. Este es el motivo principal de este artículo sobre la serie de OData.
  • Interacción simplificada: Con OpenAPI, las herramientas y bibliotecas pueden generar clientes o servidores automáticamente en diversos lenguajes de programación, facilitando el desarrollo de aplicaciones que consumen o exponen APIs.
  • Archivo descriptor: Usualmente, la especificación OpenAPI se escribe en un archivo YAML o JSON, que describe toda la estructura de la API.

Como he comentado anteriormente, este artículo se llama «Documentar y Probar con OpenAPI» porque es extremadamente útil usar OpenAPI para documentar y tener un entorno de pruebas sólido y robusto. Y, dentro de nuestro estudio de OData, nos va a venir muy bien esta herramienta para entender como funciona y en que afecta la configuración del Proyecto Gateway.

Proyecto OpenAPI para SAP en GitHub

Existe un proyecto OpenAPI para SAP open source en GitHub para poder ser importado y usado en los sistemas SAP. El proyecto, de Geert Janklaps es el siguiente geert-janklaps / abap-openapi-ui y lo explica en este artículo de SAP Community ABAP OpenAPI UI v1 released!.

Pero ¿Cómo importamos ese proyecto en nuestro sistema SAP? Pues como vimos en la entrada:

abapGit: Integración de Git para Desarrollo ABAP en SAP

Tenemos la herramienta abapGit para poder manejar los repositorios Git como GitHub en SAP, por lo que el primer paso es instalar la versión standalone de AbapGit. Hago esto porque en principio lo único que quiero es poder importar el proyecto OpenAPI. Si quisiese usar un repositorio Git para trabajar con versionado y todo lo que ofrece instalaría la «Developer version».

Por lo tanto creamos el report ZABAPGIT_STANDALONE en nuestro sistema, como yo solo lo quiero para importar proyectos de ABAP en Git lo crearé como objeto local, porque no necesito transportarlo. Una vez hayamos importado el código tendremos el siguiente report:

Instalar el proyecto ABAP OpenAPI

Una vez tenemos el report de ABAPGit y sabemos donde está el proyecto podemos instalarlo, para ello lo primero que hacemos es crear un repositorio Offline pulsando el botón superior New Offline.

Y como resultado nos habrá creado el repositorio Offline.

Ahora es cuando vamos a importar, en este repositorio, el proyecto ABAP OpenAPI que s el siguiente geert-janklaps / abap-openapi-ui y descargamos el proyecto en ZIP

Y con este ZIP pulsamos el botón ImportZIP del repositorio que hemos creado anteriormente.

Y al importar nos dará un resumen de todos los objetos que va a crear en el repositorio en base al proyecto ABAP OpenAPI.

Si nos parece correcto, pulsaremos el botón Pull para aceptar la creación de los objetos.

Una vez aceptado, nos pedirá orden de transporte y generará los objetos del proyecto.

Transacción ZGW_OPENAPI

Si accedemos a la transacción ZGW_OPENAPI accederemos a esta pantalla:

Donde poder indicar nuestro Servicio OData y que nos genere la vista Swagger UI o JSON y, si seleccionamos Swagger UI nos saldrá una aplicación web OpenAPI con la definición de nuestro servicio, acciones posibles, campos y la posibilidad de probarlo.

Para los que conocen el antiguo Swagger (ahora OpenAPI) ya sabrán las funcionalidades que ofrece. Pero para todos, de cara a los proyectos OData de SAP Gateway.

  • Opciones sobre entidades y propiedades: Si repasamos el artículo OData y SAP Gateway – IV – Opciones sobre Entidades y Campos donde explicamos diversas opciones sobre entidades y propiedades de un proyecto SAP Gateway en la SEGW. Estas opciones se verán reflejadas en el OpenAPI generado, de forma que podremos ver el resultado de nuestra configuración en esta herramienta.
  • Visualización del diagrama entidad relación: en la. Parte superior del OpenAPI generado de nuestro proyecto SAP Gateway veremos todas nuestras entidades y sus relaciones (que vimos en la entrada OData y SAP Gateway – III – Recuperar Subentidades)
  • Plantilla de ejecución de métodos sobre entidades: En base a los métodos de ejecución que se haya generado en base a las opciones de la entidad en el proyecto (GET, POST, PUT) podremos realizar pruebas en OpenAPI. La principal diferencia es que estás pruebas estarán mucho más guiadas y tendrán mucha más información que el Gateway Client. Tendremos campos para Filter, Skip, Top, Order, Select, Count, Expand, además de tener acceso directo a la documentación oficial OData de como se usa.
  • Ejecucion OData REST de métodos sobre entidades: Una vez preparada la ejecución con todos los campos de opciones sobre la ejecución, al ejecutar podremos ver la URL de ejecución, el resultado y posibles errores. Además podremos poner un break point externo en nuestro método de la clase DPC_EXT y al ejecutar podremos capturar la ejecución en debugging.

Para mi, cuando estoy trabajando en proyectos OData en SAP es un imprescindible. Me sirve para entregar una documentación, como capa de pruebas y para ver si la configuración de mi proyecto SAP Gateway OData sea coherente.

SAP Mazinger Z

El título de este artículo sólo lo entenderán los Boomers y los Milenials como yo. Mazinger Z eran unos dibujos animados japoneses sobre un niño y un súper robot acojonante que luchaba con otros robots acojonantes u otros bichejos. Tampoco lo recuerdo mucho.

El tema del que vamos a hablar no son los dibujos, no os preocupéis, pero el nombre me venía perfecto para lo que quería explicar.

El caso es que SAP es una herramienta estándar, de caja, instalar, configurar y listo. Esa es su ventaja competitiva, y eso es por lo que los clientes pagan las licencias tan baratas que cobra SAP. Eso es lo que le ha traído aquí a estar donde está, y lo que ha hecho que sus competidores vayan saliendo con sus soluciones «Out of the box» al igual que SAP (Salesforce, Oracle, Microsoft, etc).

Out of the box

Pero en ocasiones, como los niños o los gatos.

A ciertos clientes y consultores lo que les gusta es jugar con la caja y no con el contenido.

Entienden que lo divertido es lo que ponga en la caja del software pero los procesos estándar, aplicaciones, integraciones no se adecúan a ellos.

Es aquí donde nace SAP Mazinger Z, poco a poco empresas, consultores y desarrolladores van construyendo una especie de sistema paralelo al sistema estándar.

Ampliaciones en SAP

Pero ¿por qué he traído el nombre de Mazinger Z? Porque en SAP, las ampliaciones de cliente se realizan, normalmente, con el prefijo Z. Hay locos que usan ‘Y’, pero esa gente quiere ver el mundo arder.

Yo entrando en un proyecto donde las ampliaciones comienzan por Y

Y claro, ceñirse al estándar es, en ocasiones, más difícil que hacerte un Mazinger Z monstruoso.

El primer nivel que debe controlar esto es el propio cliente, que es el dueño del negocio y es el que compra el producto (SAP) y debe ser consecuente con esa decisión.

Nadie compra un Ferrari para llevar una caravana

El segundo nivel es la consultoría. Como consultores tenemos la obligación de conocer la herramienta y saber adaptar el negocio del cliente manteniendo, en la medida de lo posible, el estándar. Ofrecerle al cliente las mejores prácticas tecnológicas de un software usado por miles de empresas. En definitiva, ser un buen consultor.

Ser consultor

Presas del desarrollo

Y es que, en ocasiones, los sistemas se modifican tanto o se crean tantos procesos no estándar y tan complejos (y mal codificados/documentados) que el cliente y la consultora se hace presa del desarrollo realizado. En ocasiones me he encontrado con semidioses intocables, creadores del averno codificado, que están ahí porque son los padres de la fiera y los únicos que saben domarla. Se han convertido en los dueños del Mazinger Z.

Upgrades y actualizaciones estándar

Porque claro, cuando se compra una herramienta como SAP se paga una licencia anual que, entre otras cosas, te asegura el soporte y mantenimiento de la herramienta estándar, corrigiendo errores vía Support Packages o Notas. Además puedes querer o necesitar un upgrade a una nueva versión superior.

Cada vez que SAP lanza una actualización, los desarrollos Z pueden generar incompatibilidades que requieren tiempo y recursos adicionales para ser resueltos, afectando la agilidad del negocio.

Futuro y tendencia

Con el avance de las plataformas Low-code y No-code, el futuro del desarrollo en sistemas ERP podría orientarse hacia configuraciones cada vez más sofisticadas sin necesidad de recurrir a desarrollos complejos, facilitando el mantenimiento y las actualizaciones. Ejemplos de esto en SAP seria, SAP Build, SAP Build Code, Github Copilot, Microsoft Power Platform, etc.

SAP Build

En conclusión

El desarrollo dentro de suites como SAP es, sin duda, necesario, pero, como consultores, tenemos que conocer la herramienta y sus posibilidades, saber si de una manera u otra los requerimientos del negocio pueden ser satisfechos configurando la herramienta y, finalmente, si es necesario un desarrollo, acotar bien el alcance del mismo.

En un mundo donde la tecnología evoluciona rápidamente, saber cuándo y cómo construir tu propio ‘Mazinger Z’ dentro de SAP puede ser la diferencia entre un sistema que empodera a tu negocio y uno que lo atrapa en su propia complejidad.

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