¿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

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? 😉