Categoría: SAP

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

¿Qué es GROW with SAP?

En una entrada anterior vimos ¿Qué es RISE with SAP? hoy toca otro de esos conceptos o soluciones comerciales que ha sacado SAP para mejorar su relación con los clientes y simplificarles el camino. En este caso vamos a hablar de «GROW with SAP».

Algunas hierbas pueden convertirse en árboles

Si ya conocer en profundidad lo que es RISE with SAP es relativamente complicado, al final descubrimos que es una solución comercial de SAP para ayudar a las empresas a la transición de sus sistemas On Premise al Cloud. Ahora tenemos GROW with SAP que, teniendo medio claro RISE y soluciones SAP anteriores como SAP Business One podemos entender qué es esto de GROW with SAP.

Investiguemos

Según la propia SAP:

Una oferta completa de soluciones, comunidad, capacitación y servicios para acelerar la adopción a fin de que cualquier empresa pueda adoptar exitosamente un ERP en la nube.

www.sap.com

Pero eso no dice mucho. También podemos ver el video comercial explicativo de GROW with SAP en su propia página web.

Muy bonito, la gente es muy feliz cuando tienen SAP

Pero el video, tampoco nos dice demasiado. Pero si vamos al apartado de Características veremos el siguiente texto

A través de GROW with SAP, su empresa en crecimiento puede optimizar los procesos de trabajo cotidianos, ajustarse a los estándares regulatorios, y escalar con más facilidad.
[…]
GROW with SAP brinda los productos y servicios que necesitan las empresas medianas

https://www.sap.com/spain/products/erp/grow/features.html
¡Ahí lo tienes!

Ahora sí, ya se entiende, y tiene todo el sentido. Respondamos la pregunta.

¿Qué es GROW with SAP?

GROW with SAP es una solución comercial de SAP para que medianas empresas puedan adoptar sistemas ERP Cloud de SAP como palanca de crecimiento.

Nube pública

Por supuesto, la única opción posible para GROW with SAP es Cloud Public Edition (nube pública), y esto tiene sentido porque SAP aprovecha economías de escala explotando al máximo su nube pública (recordemos que esto es que se comparte máquina entre muchos clientes), además aportando a los clientes la posibilidad de recibir todas las innovaciones o soluciones que necesite conforme su negocio crece. Es un Win-Win de manual.

Economía de escala: Abaratamiento de los costes unitarios de un producto, logrado al aumentar la cantidad total producida.


Si aumento la producción, el coste por unidad baja, porque aprovecho mejor mis recursos

Entendiendo GROW with SAP

Ya hemos definido que Grow with SAP está diseñado específicamente para ayudar a las empresas medianas a adoptar un ERP en la nube de manera rápida y eficiente. Lo interesante de esta solución es que no solo incluye el software como servicio, sino también servicios de implementación acelerada y soporte continuo a través de la comunidad de SAP y sus partners. Esto permite a las empresas optimizar rápidamente sus procesos internos y ajustar sus sistemas según crezcan.

Los pilares fundamentales de Grow with SAP

Y es que el producto GROW with SAP es muy interesante para las medianas empresas ya que proporciona:

  • Preconfiguraciones sectoriales: Con más de 75 procesos preconfigurados, las empresas pueden elegir las mejores prácticas industriales que más se ajusten a sus necesidades específicas, sin tener que personalizar desde cero.
  • Automatización e Inteligencia Artificial: Una de las ventajas clave de esta solución es su capacidad de automatizar tareas y utilizar IA para obtener datos en tiempo real, lo que facilita la toma de decisiones informadas.
  • Escalabilidad sin complejidad: Al estar basado en la nube, Grow with SAP permite a las empresas escalar sus operaciones sin preocuparse por una complejidad técnica adicional ni sobrecostos. En este caso entendamos escalar como crecer.
  • Acceso a soluciones anexas al ERP: además de tener acceso a un SAP S4/HANA Cloud, GROW with SAP también da acceso a SAP BTP, SAP Build, SuccessFactors, SAP Analytics Cloud, Ariba, Sales Cloud… Perfecto para que la empresa vaya adaptando su landscape tecnológico a sus necesidades crecientes.
Imagen de SAP.com

Beneficios clave que proporciona GROW with SAP

Y los beneficios están claros.

Imagen de SAP.com
  • Rapidez de implementación: Según SAP, las empresas pueden estar operativas en tan solo 4-6 semanas, gracias a los procesos preconfigurados. Esto, habría que verlo. porque luego todas las empresas son «especiales».
  • Escalabilidad sin complejidad: La plataforma está diseñada para crecer con el negocio sin añadir complejidad. Las empresas pueden añadir funcionalidades conforme crecen, sin tener que modificar su infraestructura existente.
  • Costos predecibles: Al ser una solución en la nube, Grow with SAP sigue un modelo de suscripción con costos más manejables y predecibles. Esto elimina la necesidad de grandes inversiones iniciales y permite gestionar mejor el presupuesto.
  • Innovación continua: Las empresas reciben actualizaciones automáticas de las últimas funcionalidades, incluyendo IA y automatización, sin interrumpir su operación. Esto asegura que siempre estén al día con las nuevas tecnologías.
  • Acceso a un ecosistema de expertos: Grow with SAP ofrece acceso a una red global de expertos y partners certificados que brindan soporte continuo (como por ejemplo contratarme a mi). Esto facilita la adopción y el uso eficiente del ERP sin necesidad de grandes equipos de TI internos.

En Conclusión

Me parece un verdadero acierto esto de GROW with SAP, en todos los sentidos, para los clientes, para SAP y para la consultoría SAP. Con esta solución, las empresas medianas tienen la oportunidad de adoptar tecnología avanzada sin la complejidad ni los altos costos que suelen acompañar a las grandes soluciones ERP.

SAP ha dado en el clavo al lanzar una oferta tan ajustada a las necesidades del mercado medio, diseñando una plataforma que no solo impulsa el crecimiento de sus clientes, sino que también los mantiene competitivos en un entorno digital en constante cambio. Si tu empresa está en pleno crecimiento, GROW with SAP podría ser la solución ideal para optimizar procesos y acelerar tu expansión sin complicaciones.

ABAP Development Tools – ¿Qué es SAP ADT?

En la entrada «SAP CDS Core Data Services – ¿Qué son las CDS?» adelantamos que la herramienta ADT (ABAP Development Tools) es imprescindible para el uso de CDSs, pero ahí nos quedamos, ahora toca explicar qué es el ADT y cómo podemos empezar a usarlo. Pero, por supuesto, su uso no es únicamente para poder gestionar las CDSs Tiene muchos más usos. Vamos por partes.

¿Qué es SAP ADT?

ADT (ABAP Development Tools) es un conjunto de herramientas integradas en el entorno Eclipse por medio de un Plugin que permite a los desarrolladores trabajar de manera más moderna y eficiente en proyectos ABAP. A diferencia del tradicional SAP GUI, ADT proporciona una interfaz más intuitiva, con funcionalidades avanzadas que facilitan la escritura, depuración y gestión del código.

Características Principales de SAP ADT

SAP ADT trae consigo una serie de funcionalidades que optimizan el proceso de desarrollo, algunas de las cuales no estaban disponibles en SAP GUI.3.1.

Editor de Código Mejorado

El editor de código de SAP ADT ofrece una experiencia de edición mucho más rica en comparación con SAP GUI. Soporta características como:

  • Autocompletado: Facilita la escritura de código al sugerir funciones, variables y estructuras.
  • Resaltado de Sintaxis: Mejora la legibilidad del código con resaltado de diferentes componentes de ABAP.
  • Navegación Rápida: Permite saltar rápidamente entre funciones, clases y definiciones.

Herramientas de Refactorización

La capacidad de refactorizar código es esencial para mantener un código limpio y eficiente. Refactorizar es el proceso de mejorar la estructura interna del código de un programa sin alterar su comportamiento externo. SAP ADT permite:

  • Renombrado de Elementos: Cambiar el nombre de variables, clases y métodos sin romper referencias.
  • Extracción de Métodos: Facilita la reestructuración del código extrayendo segmentos en nuevos métodos.

Depuración Avanzada

La herramienta de depuración en SAP ADT es más intuitiva y poderosa que la disponible en SAP GUI. Ofrece:

  • Puntos de Ruptura Condicionales: Permiten detener la ejecución bajo condiciones específicas.
  • Visualización de Variables en Tiempo Real: Posibilita monitorear y modificar valores durante la ejecución.

Beneficios de Utilizar SAP ADT

Bueno, lo primero que habría que destacar es que es el camino claro que indica SAP de cara al desarrollo de S/4 HANA y de ciertas tecnologías en particular (CDS, RAP, ABAP Test Cockpit (ATC), etc.). Por lo tanto, un desarrollador debería estar atento al camino que toma su herramienta de trabajo y adaptarse al cambio, no vaya a ser que la carretera termine en una calle sin salida.

Pero, además de esto, que parece obvio, pero muchos no lo asimilan, ofrece mejoras en:

  • Usabilidad: SAP ADT ofrece una interfaz gráfica más moderna e intuitiva en comparación con SAP GUI. La integración con Eclipse proporciona una experiencia de usuario más fluida, con herramientas de navegación, autocompletado, y personalización del entorno de desarrollo.
  • Productividad en el desarrollo: Ofrece características avanzadas como la refactorización de código, depuración en tiempo real, y soporte para pruebas automatizadas con ABAP Test Cockpit (ATC). Estas herramientas permiten a los desarrolladores completar tareas más rápidamente y con menos errores, facilitando un desarrollo ágil y eficaz.
  • Gestión de versiones: ADT facilita la integración con sistemas de control de versiones como Git, permitiendo a los desarrolladores gestionar el código fuente de manera efectiva. Con esta integración, es posible realizar commits, merges y revertir cambios directamente desde el entorno de Eclipse, lo que asegura un control completo sobre el historial de cambios y facilita la colaboración en proyectos con múltiples desarrolladores.
  • Debugging: Ofrece características como puntos de ruptura condicionales, monitoreo en tiempo real de variables, y la posibilidad de modificar el flujo de ejecución mientras se depura.
  • Compatibilidad con todo el ecosistema S/4 HANA haciéndolo esencial para los desarrolladores que migran o desarrollan en este entorno.

Instalación y Configuración de SAP ADT

Para comenzar a usar SAP ADT, es necesario instalar Eclipse y luego agregar el plugin de ABAP Development Tools. Vamos a verlo paso a paso pero todos ellos están explicados en el siguiente enlace:

Download the Eclipse IDE and add the ABAP Development Tools (ADT) Plugin

SAP Developer Center

Eclipse IDE

Hay que descargar la versión de Eclipse desde la web «Eclipse download page» tal y como comenta el tutorials del SAP Developer Center

SAP ADT Plugin

Una vez tengamos descargado y funcionando el Eclipse hay que instalar el Plugin de ADT en Eclipse. Se puede instalar directamente desde Eclipse utilizando el gestor de plugins con la URL https://tools.hana.ondemand.com/latest. Una vez más, lo mejor es seguir los pasos del tutorial del SAP Developer Center.

Configurar la conexión al sistema SAP

Una vez instalado el Plugin ADT en Eclipse tenemos que conectarnos al sistema. SAP. Para ello abrimos la perspectiva de ABAP en Eclipse.

Y se nos abrirá la visión de SAP ADT en Eclipse

Fijate bien en la barra de botones a ver si te suena alguno

A continuación tenemos que añadir la conexión al sistema que queramos pulsando Create an ABAP project. Esto abrirá una ventana con los sistemas que tengamos configurado en el SAP Logon para poder conectarnos.

Yo tengo algún que otro sistema configurado

En conclusión

Al principio se te puede hacer difícil salir de la comodidad de tu SAP GUI, y no es que el framework de trabajo Eclipse me encante, pero es el camino y, posteriormente, te va a dar más de lo que te quita, porque vas a estar al día de todas las tecnologías SAP.

Yo también he sido reacio al cambio, sobre todo porque no lo necesitaba y el SAP GUI me permitía navegar por los mares técnicos de SAP. Pero es como nadar con un solo brazo, puedes nadar, pero irás más lento y cuando te persiga un tiburón no podrás ir deprisa y te comerá el tiburón.

Con la evolución constante de SAP hacia S/4HANA y la adopción de tecnologías emergentes como CDS y RAP, ADT se posiciona como una herramienta imprescindible para cualquier desarrollador que quiera estar a la vanguardia. Luego no digáis que no lo sabíais.

En este artículo hemos sentado las bases de qué es el ADT, sus beneficios y usos y cómo se instala y se configura inicialmente. En posteriores artículos intentaré hacer ejemplos de uso, y cosas más concretas como son:

  • Manejo básico en nuestro día a día como hacemos en SAP GUI
  • Debugging en ADT
  • Crear y gestionar CDS en ADT