¿Quién ha hecho esta mierda de programa?

Si eres desarrollador, es probable que más de una vez se te haya venido esa frase a la cabeza al revisar el código de un programa. Y es también muy posible que ese «quién» fueras tú mismo… 15 años antes 😉

Que no siempre tiene porqué ser así, que hay gente que hace las cosas muy bien desde el minuto 1, pero aunque fuera así, me cuesta creer que ahora mismo alguien haría igual las cosas que hace 15 años, sobre todo teniendo en cuenta lo que ha avanzado la tecnología en este tiempo.

Sí, ya conozco la máxima de «si funciona, no lo toques», pero es que si trabajas con SAP puede que las cosas dejen de funcionar en breve… ya sabéis, HANA, S/4HANA y esas cositas.

«¿¿¿Cómo??? ¿Pero es que las cosas no funcionan directamente más rápido por poner HANA?».

Claro, claro que sí… es todo automático. Tú metes el «CD de HANA», le das a «siguiente» unas cuantas veces y está todo listo.

A ver, si hace 20 años tú ya tuviste en cuenta que pasado un tiempo te iban a decir justo lo contrario («mete caña a la base de datos, que la aplicación sea ligera») de lo que te estaban diciendo en ese momento («no leas mucho de la base de datos, mete caña en la aplicación»), puede que no tengas que revisar mucho… o si lo tienes todo estándar… porque, por supuesto, las buenas prácticas las has aplicado desde siempre, ¿no?

Si, por un casual, no tuviste en cuenta eso y tienes algún «zeta», o no siempre has sido muy cuidadoso con las buenas prácticas, quizás sea el momento de que revises tu código ABAP.

No esperes al último momento y empieza con esa tarea, ya que obtendrás beneficios inmediatos (optimización del código existente, eliminación de programas obsoletos…) y te preparará mejor para lo que está por llegar, porque sí o sí, vas a pasar a S/4HANA… ¡y lo sabes!

Hace unos meses ya escribí una entrada sobre esto: Revisión de código para migrar a S/4HANA

¿Por qué lo recuerdo ahora? Pues porque es otra de las cosas para las que vas a necesitar las ABAP Development Tools (ADT), de las que os hablaba ayer, es para poder corregir automáticamente muchos de los errores de tu código.

¿Y esto cómo se hace? Pues, por resumir:

  1. Cargas la Simplication Database. Que es una lista que contiene las verificaciones a realizar.
  2. Lanzas el ABAP Test Cockpit (ATC). Una herramienta que busca esas verificaciones en tu código.
  3. Ejecutas la SPDD y la SPAU. Estas son viejas conocidas, ¿no?
  4. Vuelves a lanzar el ABAP Test Cockpit (ATC). Ahora en el sistema destino.
  5. Corriges el código con las ABAP Development Tools (ADT). Hay una perspectiva especial para leer los resultados del ATC.

¿Demasiado resumido? Tenéis todo el detalle aquí: Custom Code Migration Guide for SAP S/4HANA 1809

Venga, que aún estamos a tiempo de hacer bien las cosas y evitar que dentro de 15 años, cuando nos encontremos con nuestro código, vuelva a aparecer en nuestra mente la misma pregunta… 😉

ABAP Development Tools (ADT): ¿qué es esto?

Si eres un desarrollador ABAP y te preguntas esto: tienes un problema.

Vale que sigas haciendo tus cositas con la SE80 (incluso con la SE38), pero al menos tienes qué saber qué es esto de las ABAP Development Tools (ADT).

¿Por qué? Pues entre otras cosas porque puede que en poco tiempo todo lo que tengas que hacer por ahí, como ahora mismo tienes que hacer, sí o sí, lo de los Core Data Services (CDS), por ejemplo.

Y si no sabes lo qué es eso de los CDS, el problema que tienes es muy gordo 😉

Una pista: Core Data Services: ¿esto qué es?

Una vez solventados tus problemas, sigamos leyendo…

Las ABAP Development Tools (ADT), eso que a ti te aparece tan nuevo, aparecieron en al año 2012, y no dejan de ser una serie de componentes que se le añaden a Eclipse, para poder trabajar en ABAP desde ese entorno.

Si no sabes lo que es Eclipse, me rindo… 😉

El caso es que Eclipse hasta hace unos meses iba sacando una nueva versión cada año y SAP iba adaptando las ADT a cada una de esas versiones, al poco tiempo.

Muchas veces no era necesario actualizar, pero sí recomendable. Además, solía haber unos meses de decalaje entre que aparecía la nueva versión de Eclipse y la correspondiente de las ADT.

Los nombre de las versiones de Eclipse tenían que ver con temas «espaciales» (Mars, Neon, Oxygen, Photon…) pero desde septiembre del año pasado ha cambiado la nomenclatura y ahora son mucho mas sosas (aunque más útiles), del tipo AAAA-MM, es decir, 2018-09, 2018-12, etc…

Aquí os dejo el enlace a la última: Eclipse IDE 2019-03

De todas formas, no suele ser conveniente estar a la última, sino a la penúltima, por lo que os comentaba del tiempo de decalaje. Por ejemplo, a día de hoy, aún no están disponibles las ADT para esa versión, como podéis ver en SAP Development Tools.

Aparte de la nomenclatura, ha cambiado la frecuencia y ahora habrá actualizaciones trimestrales, con lo que el ritmo de actualización de las ADT se tiene que adaptar a esto.

¿Y es imprescindible seguir este ciclo de actualizaciones? Imprescindible, imprescindible, no… sobre todo, si me paso el día haciendo batch-inputs y ALVs… si uso CDS y AMDPs empieza a ser recomendable… y si tengo pensado hacer algo en ABAP en Cloud, entonces sí, entonces será imprescindible, ya que el servidor ABAP en Cloud será actualizado de manera automática (cosas de la nube) y necesitaremos la versión adecuada de las ADT para poder trabajar contra él.

Y, al igual que anteriormente, podremos trabajar siempre con 2 versiones anteriores, lo que pasa es que antes ese tiempo era de 2 años y ahora el tiempo se reduce a 6 meses; se supone que para poder tener ciclos de innovación más cortos, aunque alguno puede argumentar que es para volvernos más locos de lo que estamos… 😉

PD.- Información extraída de este artículo: Important changes to the ABAP Development Tools (ADT) release cycle

SAP Cloud Application Programming Model: ¿esto qué es?

Bueno, esto realmente es lo mismo de lo que os hablaba ayer: ABAP RESTful Programming Model.

Realmente, deberíamos hablar por un lado del modelo de programación (ABAP RESTful Programming Model) y por otro lado del entorno (SAP Cloud Platform ABAP Environment).

Aquí os dejo una presentación sobre el tema: Overview of the ABAP RESTful Programming Model in SAP Cloud Platform ABAP Environment

En la misma nos intentan explicar todo esto y, entre otras cosas, conceptos clave como Business Objects y Business Services.

Puedes engañarte y decirte que todo está muy bien, pero que ahora mismo no tienes tiempo de mirar estas cosas porque tus clientes sólo te piden batch-inputs, ALVs y SAPscripts, pero… ¿estás seguro de que todo eso te va a servir de algo en un par de años?

Así que yo que tú, iría enterándome un poco de qué va todo esto y aquí tenéis una nueva oportunidad, con este curso de openSAP: SAP Cloud Platform Essentials (Update Q2/2019) 

¿Lo vas a hacer o vas a seguir con tus módulos de funciones? 😉

ABAP RESTful Programming Model: un paso más

En la entrada de ayer os comentaba que algo, con lo que es probable que ni os hayáis puesto aún, se estaba quedando ya obsoleto. Realmente, debería decir que ha ido evolucionando.

Si ayer hablaba del ABAP Programming Model, hoy escribo de algo que no es exactamente lo mismo: ABAP RESTful Programming Model.

Todo esto está muy relacionado con el anunciado ABAP en Cloud, que nos presentaron hace unos meses en el SAP TechEd y que se basa en lo siguiente:

    • Modelado (CDS)
    • Aprovisionamiento de servicios (OData)
    • Consumo de servicios (Fiori)

Entre otras cosas, en este modelo, deberíamos trabajar con las ABAP Development Tools (ADT), ya no hace falta entrar a la SE80 por SAP GUI, a pesar de la flamante versión 7.60 😉

El ABAP sigue vivo, aunque no será el de siempre, y hay que habituarse al uso de API’s y el modelado de datos con CDS.

Aquí os dejo el artículo donde hablan de todo esto: Evolution of the ABAP Programming Model

¿Y tú, te apuntas a la evolución o piensas seguir con tus ALV’s? 😉

ABAP Programming Model: algo que te debería sonar

Hace menos de 1 año escuché esta frase: «El ABAP orientado a objetos casi no se utiliza». Que es algo así como decir, a estas alturas del partido, que La Tierra es plana, pero ya sabéis que hay de todo en este mundo… 😉

También cuando cuento algo de SAP Cloud Platform alguien me dice lo de «todo esto es muy  nuevo»… y cuando miro el primer curso que hubo en openSAP sobre esto veo que es del 26 de octubre de 2013… ¡hace casi 5 años y medio!

Lo que sí es cierto es que, por ejemplo, todo lo de SAP Cloud Platform ha cambiado bastante desde que empezó, pero de ahí a que sea «muy nuevo», hay una gran diferencia.

Y aunque tengo claro que esto es un poco predicar en el desierto, vuelvo de nuevo a la carga, intentando explicar por qué, sobre todo si eres desarrollador, deberías ir pensando en actualizarte.

La clave de todo está en entender este gráfico:

Simplificándolo mucho: tengo mis datos en HANA, los modelo con CDS, los pongo en formato OData y los consumo en aplicaciones SAPUI5/Fiori.

De entrada, tengo que tener muy claros algunos conceptos: HANA, CDS, OData y SAPUI5. Algo que ya era básico a finales de 2017… 😉

¿Por dónde empiezo? Aquí os dejo una pequeña ayuda: Be prepared for the ABAP Programming Model for SAP Fiori

¿Te vas a actualizar o vas a pasarte la vida haciendo batch-inputs?

Y lo mejor es que esto, está empezando a quedarse «obsoleto»… 😉

 

Desarrollo en SAP HANA: ¿a qué esperas?

Cuando apareció HANA, a finales de 2010, empezaron a circular mensajes apocalípticos, diciendo que, por ejemplo el BW y el ABAP iban a desaparecer.

A día de hoy, que alguien siga diciendo cosas así, te hace ver que vive anclado en el pasado. Lejos de desaparecer, precisamente esos 2 productos, tienen sus especificaciones propias para trabajar con HANA, como podéis ver en estos 2 cursos de openSAP:

Cursos, por cierto, que son de 2014 y 2016, por si alguien me va a salir con lo de «esto es muy nuevo»… y, por supuesto, ambas cosas han ido evolucionando, a lo largo de estos años.

HANA empezó siendo una base de datos en memoria pero ahora es mucho más que eso: es la plataforma de innovación de SAP.

Por cierto, que si alguien quiere saber cómo surgió HANA, os recomiendo que leáis la entrada que hay en la Wikipedia al respecto. ¿Alguien sabía que el «famoso» TREX era uno de sus componentes principales? Sí, ya sabemos que HANA tiene capacidades de búsqueda y análisis, etc… pero que el origen venga de ahí es, cuando menos, curioso. Aquí os dejo el enlace: SAP HANA Wikipedia – Historia

En cualquier caso, aunque es cierto que el ABAP no está muerto, también lo es que deberíamos conocer de qué va esto del desarrollo en HANA. Y no hablo sólo del ABAP para HANA, hablo del desarrollo nativo en HANA.

Sobre esto, como os podéis imaginar, también ha habido cursos en openSAP, desde el año 2013 concretamente. Este fue el primer curso: Introduction to Software Development on SAP HANA

Y el último, que está ahora mismo en marcha, es este: Software Development on SAP HANA (Update Q1/2019) 

Entre medias, ha habido varios, de actualizaciones de las distintas versiones, con sus correspondientes novedades y/o alguna repetición de un curso anterior.

Si eres de los pocos que empezaste con el desarrollo en HANA, cuando surgió todo esto y no te has actualizado, tienes un problema.

Si no te has puesto aún con esto y eres desarrollador en el mundo SAP, es probable que en un futuro inmediato tengas un problema.

Si todo ha cambiado en los últimos años, esto ha cambiado mucho. Aún conservando la idea base de que hay que meter toda la carga que podamos de nuestras aplicaciones a nivel base de datos, en lugar hacerlo sobre la propia aplicación, la forma de construir y gestionar las mismas, ha cambiado.

El cambio principal vino en el SPS11 de HANA 1.0, cuando pasamos de hablar del XS clásico (XSC) al XS Advanced (XSA). Aquí os dejo un vídeo en el que intentan explicar la nueva arquitectura:

¿Cuál es mi consejo? Pues que empecéis a mirar de qué va esto, con los cursos de openSAP y con la SAP HANA Academy.

Si empezaste con XSC, entérate de cómo va el tema de XSA. Si no has empezado, empieza directamente con XSA, aunque no estaría mal que te sonara cómo va lo de XSC, por si te encuentras alguna aplicación «antigua».

Por mi parte, me comprometo a escribir algún artículo con algún ejemplo básico.

¿No crees que va siendo hora de que te pongas con esto? 😉

Revisión de código para migrar a S/4HANA

Tranquilo, esto no es para ti… tú lo tienes todo estándar y no tienes ningún desarrollo a medida. Además, en caso de tener alguno seguro que está perfectamente optimizado y lo hiciste pensando que en unos años iba a aparecer S/4HANA y no hace falta que toques nada.

Pero… como quizás conozcas a alguien que puede que sí que haya tocado algo, sería bueno que le aconsejaras que leyera esto… 😉

Teniendo en cuenta que en S/4HANA se ha modificado y/o eliminado una gran cantidad de código, es muy probable que tengas que revisar tus desarrollos de cliente, ya que muchos puede que ya no tengan sentido o que directamente no funcionen.

Para ello, SAP nos proporciona una serie de herramientas, basada en la Simplification Database, que recoge todos los objetos SAP que han sido modificados, ofreciéndonos notas de soporte para saber qué hacer en cada caso.

Para realizar esos chequeos, necesitamos tener un sistema central, desde el que conectarnos a los distintos sistemas que tengamos para poder realizar dichas verificaciones.

Desde ese sistema central, se lanzará el ABAP Test Cockpit (ATC), que nos ofrecerá como resultado un listado con los problemas detectados y sus posibles soluciones:

Podéis ver más detalle de todo esto aquí: Custom Code Migration Guide for SAP S/4HANA 1809

Y aunque esto realmente está indicado para el paso a S/4HANA, no os engañéis, quizás no sería malo que aunque no tengáis pensado dar el salto en un futuro inmediato, empecéis a revisar ya vuestro código, que luego ya sabemos lo que pasa…

En España nunca hay tiempo de hacer bien las cosas… pero sí de hacerlas 2 veces.

Perdón, vosotros no, que no tenéis nada «zeta», pero quizás algún amigo… 😉

SAP Cloud Platform ABAP Environment: ¿por dónde empezamos?

En los últimos días, he recibido algunas preguntas sobre el tema del ABAP en Cloud y creo que lo mejor para estar bien informados es ir a las fuentes.

Así que lo primero que os recomendaría es leer las Frequently Asked Questions, donde podéis encontrar respuestas a muchas de las preguntas que os estáis haciendo. Por ejemplo:

  • No estará disponible en Neo, sólo en Cloud Foundry.
  • Hay que estar familiarizado con cosas como Eclipse, Git, APIs¡adiós SE80!
  • En un principio, se utilizará para extender la funcionalidad de S/4HANA Cloud, aunque técnicamente está preparado para hacerlo con cualquier producto.
  • ¿Me podré llevar mis «zetas» al cloud? Si los has hecho de manera óptima y siguiendo las mejores prácticas, puede que sí. Es decir: NO 😉

Y una de las cosas que más nos preocupan: «¿pero esto cuánto vale?». Bueno, esto lo podéis ver en la página del producto: SAP Cloud Platform, ABAP environment.

De momento, parece que no está disponible para las cuentas trial, se puede adquirir en modo suscripción (a partir de 1.800 €/mes) o en modo créditos (pago por hora).

Personalmente, podría probar la opción de créditos, siempre que tenga el control para apagar/encender el sistema, como en SAP Cloud Appliance Library, aunque esto no es exactamente lo mismo, ya que esto se trata más de una plataforma (PaaS) que de una infraestructura (IaaS) en sí.

En cualquier caso, dejemos que pasen unas semanas, a ver si sale alguna otra opción, que sería lo suyo, como en muchos de los servicios de SAP Cloud Platform.

Mientras, os dejo con un vídeo de presentación del entorno:


¿Podremos jugar con esto sin tener que pasar por caja? 😉

SAP Cloud Platform ABAP Environment: que viene el coco

Ya os dije hace tiempo que el ABAP no estaba muerto y que SAP estaba trabajando en la forma de llevárselo a la nube.

Este ha sido uno de los mayores anuncios en la primera jornada del SAP TechEd: SAP Delivers New Cloud-Native Services, SAP Cloud Platform, ABAP Environment, to Help Customers Become Intelligent Enterprises

En el artículo, hace referencia al entorno ABAP en SAP Cloud Platfom y al modelo de programación de aplicaciones del que os hablé hace unos días en el artículo: Application Programming Model: ¿esto de qué va?

Además habla de nuevos servicios que estarán disponibles en SAP Cloud Platform a lo largo de 2019:

  • SAP Cloud Platform Enterprise Messaging: que nos permitirá automatizar nuestros procesos mediante la gestión de eventos y mensajes. Algo del tipo IFTTT
  • SAP Cloud Platform Backend: para poner a disposición nuestros datos para el consumo en tiempo real, mediante el uso de APIs y servicios. Habrá que ver cómo encaja esto con los servicios ya existentes como el API Management
  • SAP Cloud Platform Functions: podremos crear, implementar y ejecutar microservicios desde un entorno centralizado.

Podéis ver la charla inaugural (ya sé que queda más profesional lo de «keynote») completa en la que Bernd Leukert nos cuenta de qué va esto de «la empresa inteligente»:

Es algo más de una horita, pero seguro que no tenéis nada mejor que hacer… 😉

En cualquier caso, esta entrada me sirve para recordarte que si eres un desarrollador ABAP no puedes ir por la vida sin saber qué es SAP Cloud Platform… y diría más, no sólo un desarrollador, sino cualquiera que esté metido en este mundo.

No me vale con ponerlo en el powerpoint  de turno y soltar cuatro generalidades, hablo de entender lo que se dice. Sé que pido imposibles, pero por pedir…

Y lo malo de todo esto es que lo que sabías hace 1 año, probablemente, te sirva de muy poco hoy. La evolución es continua y toca estar actualizándose continuamente.

Así que aunque el ABAP no esté muerto, puede que tú si lo estés, aunque no te des cuenta…

No es por asustar, pero llevan tiempo avisándonos de que viene el coco… 😉

ABAP en SAP Cloud Platform

Pues sí, como lo leéis, ya os dije que el ABAP no estaba muerto y esto es una prueba más.

Tal y como anunciaron en el SAP TechEd de Las Vegas de la semana pasada, a partir del año que viene vamos a poder desarrollar nuestras aplicaciones en SAP Cloud Platform con ABAP.

¿Con nuestro ABAP de toda la vida? Sí, bueno, o con gran parte de ese ABAP, con ciertas variaciones para que podamos operar en «la nube» y eliminando sentencias obsoletas.

Y no sólo desarrollar nuevas aplicaciones, también crear extensiones o ampliaciones de cliente del código estándar. Ya sabéis lo que dicen las buenas prácticas: modificar no, pero ampliar funcionalidad sí.

De hecho, a finales de este año se empezaran con las primera pruebas para extensiones de S/4HANA Cloud.

Y como seguro que me habéis hecho caso a lo comentado hace unos días, no tendréis ningún problema en que esto sólo esté disponible con las ABAP Development Tools (ADT), porque ya estáis más que acostumbrados a trabajar con ABAP desde Eclipse… ¿no? 😉

Aquí os dejo los artículos que me han servido de «inspiración»: