Después de empezar, en el post anterior, esta serie sobre análisis de código ABAP, con la ayuda de Walter, Director de Calidad de Vision IT y especialista en entornos SAP, vamos a ver hoy lo que se necesita saber para la implantación de un proceso de análisis de código ABAP con Sonar.

Como probablemente sabéis, ABAP (Advanced Business Application Programming) es el lenguaje de programación de SAP, un software ERP nacido en los años 80, que ha conocido ya diferentes versiones. Las que se encuentran más a menudo actualmente son SAP R3, 4.0 hasta 6.0, o ECC5 y ECC6. Hay también una versión Netweaver para desarrollar aplicaciones tipo Web, y una extensión Orientada a Objetos – ABAP Objects – pero su uso no está aún muy extendido.

SAP en sí mismo es un núcleo de diferentes módulos llamados ‘areas’ correspondientes de diferentes conjuntos de funcionalidades y tablas para diferentes tipos de gestión: finanzas, ventas, recursos humanos, compras, etc.
Ahora, como cada empresa tiene su propio modelo de negocio y sistema de gestión usando esos diferentes dominios, hay que poder adaptar o customizar el ERP. Es decir, recoger datos y tratamientos del núcleo SAP, y adaptarlos al negocio de la empresa a través de pantallas, informes, datos, etc.

Este es el objetivo de ABAP y a lo que se dedican los desarrolladores ABAP. No es un lenguaje difícil de leer, si conoces ya programación y SQL, claro. Pertenece al grupo de los llamados 4GL o Lenguajes de Cuarta Generación y se acerca más a Cobol que a Java. Solamente, tiene una organización no del todo usual y un vocabulario propio, que a veces puede confundirte, pero esencialmente, es lo que hay que saber y que vamos a tratar de ver en este post.

El Workbench SAP

SAP no es únicamente un ERP, un software con sus propias pantallas, tratamientos y estructuras de datos, sino que es también un entorno de ejecución del software y un entorno de desarrollo de los programas personalizados.

La primera cosa que se debe saber, es que un programador no va a instalar un IDE tipo Eclipse con un compilador ABAP en su máquina: él se conecta a un servidor SAP y trabaja con el Workbench (literalmente ‘taller de trabajo’ o ‘banco de trabajo’) para crear un programa, una pantalla, acceder al diccionario de SAP para acceder a objetos del núcleo SAP, etc. Y todo se guarda en el Workbench, nada de ficheros ni de directorios (aunque si hay ciertas maneras de organizar el código).

El acceso a este Workbench se hace a través de transacciones. Por ejemplo, para editar un programa existente, hay que ir al ABAP Editor en el Workbench y entrar el código de la transacción (SE38 en nuestro caso) para acceder a una pantalla donde se puede entrar en más detalles respecto al programa que quieres modificar. Pues, no es una interfaz gráfica y un desarrollador ABAP no solamente tiene que saber programar, sino que también tiene que saber navegar en el Workbench.

Lo que significa que nosotros, para poder analizar código ABAP, tendremos que extraerlo del Workbench. Esto no es un problema y lo veremos en un post ulterior.
Otra cosa, es que a veces, hay que prestar atención al uso de la palabra ‘transacción’. No solamente todo lo que se hace en el workbench necesita un código de transacción. También un usuario no va a utilizar un programa sino acceder a este a través de una transacción.

Supongamos que estoy hablando con un consultor o un administrador SAP, respecto a un módulo de código y le pregunto qué tipo de transacciones hay dentro, para poder dar un nombre a este módulo en un análisis y en el dashboard. Y claro que estoy hablando de transacción funcional – creación de un cliente, impresión de una factura, etc. – y ellos entienden ‘transacción SAP’, y eso puede provocar un malentendido, para no decir cara de consternación (ya que no es difícil si eres un francés perdido en Madrid).
Ya he mencionado que el vocabulario es un poco particular. Tampoco, no es como hablar el idioma Klingon (se trata de SAP, no de Star Trek).

Areas SAP

Otro punto importante que conocer, porque vamos a tener unas preguntas respecto a eso en el próximo post: las áreas o módulos SAP ERP. Ya hemos visto que se compone de diferentes módulos o areas funcionales o servidores SAP. Los más conocidos son FICO (Financial & Controlling), HR (Human Resources), o SD (Sales & Distribution) y PP (Production Planning).

Claro que todos esos módulos hablan entre ellos: una factura en SD pasará en un cuenta de FICO, pero son módulos bastante complejos, que necesitan un conocimiento funcional bastante especializado, además no todos los equipos trabajan en las mismas áreas SAP, y por eso a veces no usan el mismo servidor SAP. Esto puede llegar a ser un problema, porque no vas a hablar de, por ejemplo, la aplicación de ‘compras’ sino de FI, CO, AM (Asset Management), MM (Material Management) por el sub-modulo Inventory Management, etc. Ah, hay también un QM para Quality Management, para el control de calidad de los productos en fabrica.

Esto es importante porque, como tenemos que hacer una extracción del código ABAP desde un servidor:

• Si hay diferentes servidores, podemos necesitar más de una única extracción.
• El código estará siempre organizado por áreas SAP. Es decir, en nivel más alto en el dashboard Sonar será una area FI, CO, HR, etc.

Objetos SAP

No vamos a hablar demasiado de los tipos de objetos ABAP porque eso lo veremos más en detalle cuando empezemos los análisis. Ahora, cuando vais a encontrar los ABAPers para ver cómo poner en marcha un proceso de análisis de código ABAP, ellos pueden preguntar cuales son los objetos que se pueden analizar o no, así que vamos a hacer una breve descripción de unos elementos de código ABAP que podrían parecer un poco confuso:

• Class: aunque existe un ABAP objeto, una clase se refiere a un paquete, es decir un conjunto de ficheros que implementan una funcionalidad (o un proceso técnico). Puedes hablar de paquete o package para evitar cualquier malentendido, pero hay que saber que una clase ABAP no será el equivalente de una clase Java.
• Report / Module pool: un programa es básicamente una interfaz que permite a un usuario introducir unos datos para producir un informe, o una serie más compleja de procesos (normalmente reutilizables) para interactuar con un usuario, llamado ‘Module pool’ o ‘Function pool’.
• Form: no es una pantalla sino un sub-programa llamado desde un PERFORM.
• Include: lo mismo que en otros lenguajes, un tratamiento que se puede llamar (para inclusión) desde un programa, como el Copy de Cobol.

Walter: En tu equipo de calidad, ¿tienes personas que vienen del mundo J2EE – o que no vienen del mundo SAP – y que analizan código ABAP? ¿Ha sido difícil adaptarse a este nuevo mundo para ellos? ¿Cuál es el nivel de esfuerzo, es decir, se necesita mucho tiempo para adaptarse?

La pregunta que haces es importante, pero requiere un matiz: a la hora de analizar código, hay que tener en cuenta dos tareas fundamentales, aunque no son las únicas tareas de un análisis (por ejemplo, ya has mencionado la actividad de extracción). Estas dos tareas diferenciadas son: la ejecución del análisis y la interpretación de resultados.

La adaptación necesaria de una persona que no viene del mundo ABAP para la ejecución del análisis ABAP es sencilla; casi bastan uno o dos días, como mucho, dependiendo si ha usado la misma herramienta con otra tecnología o es nueva para él.

Sin embargo la tarea de interpretar los resultados de los análisis normalmente requiere un conocimiento más profundo de la tecnología o lenguaje, en este caso ABAP, que se puede adquirir con el apoyo de un experto en una o dos semanas.
Por ejemplo, en qué circunstancias la sentencia considerada muy práctica MOVE CORRESPONDING TO puede dar problemas de truncamiento de información y por tanto de fiabilidad. Necesito que alguien con buenos conocimientos ABAP, me explique eso al menos una vez y lo deje documentado, para que alguien procédete de otra tecnología, pueda interpretar un análisis que señala un imcumplimiento de una buena práctica.

Así, nuestros equipos de análisis de código están formados por expertos en las diferentes tecnologías que analizamos (ABSP, Java, PL/SQL, .Net, etc.).
Hay otras actividades, como la creación de nuevas reglas o métricas en una herramienta, que requieren profundo conocimiento del procedimiento de creación (incorporamos personas con este perfil a nuestro equipos) y también de la tecnología en cuestión.

Gracias Walter. En los próximos artículos, veremos cuáles son las preguntas que hacer para organizar las análisis y la extracción del código ABAP.