Desde hace más de diez años, todos los meses en el sitio de la comunidad de SAP, alguien publica un blog sobre cómo cargar/descargar datos de EXCEL a ABAP. Entonces, voy a comenzar a hacer esto también, solo que siempre hablaré de ABAP2XLSX como el mecanismo preferido para hacer esto.

Blogs de los últimos diez años

Los 120 blogs publicados en los últimos diez años generalmente nunca mencionan ABAP2XLSX en absoluto. O hablan de la tecnología OLE arcaica que se puede usar para comunicarse con los productos de Microsoft o reinventan el concepto ABAP2XLSX.

Luego, yo mismo y unas tres o cuatro personas más (los «sospechosos habituales», como los llamo) publicaremos en la sección de comentarios hablando de ABAP2XLSX y el autor original admitirá que nunca había oído hablar de ABAP2XLSX o, a veces, se ofenderá y dirá de Por supuesto que habían oído hablar de él, solo se olvidaron de mencionarlo en su blog.

Luego viene uno (o ambos) de los siguientes dos argumentos: –

• No puedo usar ABAP2XLSX porque mi organización tiene una política de «no código abierto»
• Los proyectos ABAP de código abierto no son compatibles con SAP
• No puedo usar ABAP2XLSX porque es demasiado complicado, un mazo tratando de romper una nuez,
• ABAP2XLSX no está documentado en absoluto

Tomemos estos uno a la vez

Sin política de código abierto

Hace algunos años, la organización para la que trabajo tenía una política global de «NO CLOUD». Entonces, cuando en Australia quisimos comenzar a usar SAP Ariba (que, por supuesto, es un producto en la nube), tuvimos que obtener una exención especial, lo cual no fue fácil.

Hoy en día, por supuesto, no existe tal política global por alguna razón. ¿Qué podría haber cambiado de opinión a todos?

De la misma manera, cuando alguien dice que su organización no tiene una política de código abierto, está publicando esa declaración desde un teléfono inteligente proporcionado por el trabajo que está lleno de software de código abierto, o una PC proporcionada por el trabajo que está llena de software de código abierto, utilizando un navegador que está repleto de software de código abierto, y luego se sube al automóvil de la empresa (que está repleto de software de código abierto) para conducir hacia o desde el trabajo.

Si una organización De Verdad no tenía una política de código abierto, entonces a ningún empleado se le permitiría usar ninguna tecnología moderna y la compañía tendría que trabajar como los Picapiedra donde al final del día sales de tu oficina deslizándote por el cuello de un Brontosaurus. Lo cual probablemente sería bastante divertido. Pero en la vida real, la mayoría de las oficinas no tienen tales diapositivas, aparte de las oficinas de Google.

Además, realmente no puedo ver la diferencia entre copiar un programa de código abierto de un repositorio de GitHub en su sistema de desarrollo y cortar y pegar el código de cualquier blog que sea en su sistema de desarrollo, que es, por supuesto, lo que el cartel del blog lo alienta. hacer.

Sin soporte

Si está utilizando un marco oficial proporcionado por SAP, entonces, por supuesto, si algo no funciona, puede generar lo que todavía llamo un mensaje OSS y se supone que SAP investigará y solucionará el problema. Sin embargo, con un proyecto de código abierto como ABAP2XLSX, no puede ejecutar SAP si algo no funciona. Por lo tanto, según el argumento, no utilice proyectos ABAP de código abierto.

Esto es más un cambio de mentalidad que otra cosa. Debe pasar mentalmente del modelo de soporte A al modelo de soporte B mediante el cual: –

• En el modelo de soporte A pagas millones de dólares al año, y cuando tienes un problema haces una solicitud de OSS, vas y vienes con soporte de primer nivel durante varias semanas, que te sigue pidiendo cosas que ya les has enviado. Eventualmente, llega a un nivel más alto de soporte que le dice que esto es una consulta y que no se puede arreglar a menos que esté dispuesto a pagar más. Incluso si usted mismo ha depurado el código defectuoso y proporciona la solución (los cambios de código necesarios) a menudo no hace ninguna diferencia. Si por algún milagro se soluciona el problema, obtiene una nota de OSS que puede aplicar de inmediato, y todos los demás clientes de SAP obtienen la solución la próxima vez que apliquen una pila de soporte dentro de tres meses, un año o lo que sea.
• En el modelo de soporte B, no paga nada y cuando tiene un problema, se le recomienda encarecidamente que lo solucione usted mismo y luego presente la solución en el sitio de GitHub, donde una vez que se haya aprobado, la base de código central se actualiza para todos a la vez, por lo que la próxima vez que revisen el repositorio usando abapGit obtendrán las últimas correcciones. Si no puede solucionar el problema usted mismo, registre un problema en el sitio de GitHub y, en muy poco tiempo, alguien en el mundo de Internet lo habrá solucionado sin contraatacar constantemente, o decirle que esto está funcionando como se diseñó o lo que sea.

La gente está acostumbrada a apoyar el modelo A y ha llegado a gustarles bastante, una especie de Síndrome de Estocolmo, supongo, y la sola idea de apoyar el modelo B les hace sudar frío.

Para dar algunos ejemplos de la vida real del modelo B

• Mientras escribía la última edición de mi libro ABAP, encontré una forma de mejorar ABAP2XLSX y describí cómo enviar dicha solicitud de mejora. En cuestión de días, varias personas del mundo de Internet se lanzaron a esto y propusieron soluciones incluso mejores que las mías. Cuando plantea una nota de OSS, ¿diferentes desarrolladores que trabajan para SAP luchan entre sí para ver quién puede resolver su problema de la mejor manera?
• Varias veces, un colega mío ha hecho sugerencias/solicitudes al autor del marco del complemento ADT (Lukasz Pegiel) y al día siguiente la solución/nueva función estaba allí.
• Varias veces planteé un problema en el repositorio abapGit GitHub y una hora después recibo un mensaje que dice que la solución está lista, descárguela y responda diciendo lo que piensa (esto funciona incluso mejor que el soporte estándar de SAP porque descarga la nueva versión del código de una rama diferente, por lo que si no funciona, nadie más se ha visto afectado, y la solución generalmente solo se publica una vez que usted y el propietario del proyecto están satisfechos de que todo funciona correctamente)

Demasiado complicado

Cuando descarga el código ABAP2XLSX del repositorio de GitHub (que es https://github.com/abap2xlsx/abap2xlsx por cierto) a su sistema de desarrollo t notará que no es solo un gran programa sino más bien alrededor de 70 u 80 clases diferentes.

Eso parece hacer que la gente se queje de que todo es demasiado complicado, pero lo contrarrestaría con dos puntos:

1. No creo que 70 clases impares en un repositorio sea tan excesivo. Algunos paquetes estándar de SAP tienen muchos más objetos.
2. Esto es nada menos que un buen diseño OO. Es decir, el diseño sigue el principio de responsabilidad única (SRP, la «S» en SOLID) por el cual cada clase hace una sola cosa y, por lo tanto, solo tiene una posible razón para cambiar.

CL_SALV_TABLE sigue el mismo principio básico. En lugar de un gran módulo de funciones como REUSE_ALV_DISPLAY_GRID, tiene una serie de clases pequeñas, cada una de las cuales hace una cosa.

Codificación con CL_SALV_TABLE para crear un informe ALV y codificación con ABAP2XLSX para descargar ese informe a Excel; en ambos casos, deberá crear instancias de una variedad de objetos de bajo nivel y hacer que funcionen juntos. Además, en ambos casos puede crear plantillas reutilizables, por lo que no tiene que escribir medio millón de toneladas de código de placa de caldera cada vez.

Entonces, la pregunta es: ¿por qué lo primero no se considera un problema en absoluto, pero lo segundo se considera tan complicado que es imposible?

La razón habitual que se da es que CL_SALV_TABLE está documentado, mientras que ABAP2XLSX no está documentado en absoluto. En 2000, cuando apareció REUSE_ALV_DISPLAY_GRID, tampoco estaba muy bien documentado, pero eso no impidió que ALV despegara como un cohete y reemplazara los informes que usaban declaraciones WRITE.

Documentación Clasificada en mi Oficina

De todos los argumentos en contra de ABAP2XLSX, el único para el que tengo tiempo es la falta de documentación. Los programadores generalmente no son buenos para escribir documentación, les encanta escribir código tanto que no quieren hacer nada más.

Sin embargo, de la misma manera que Thomas Jung escribió toneladas de documentación sobre CL_SALV_TABLE en su libro SAP Press «Next Generation ABAP Development», yo escribí toneladas de documentación sobre ABAP2XLSX en mi libro «ABAP to the Future».

Se me ha señalado en Internet que si realmente quiero que miles de programadores ABAP comiencen a usar ABP2XLSX, obligarlos a comprar mi libro probablemente no sea la forma correcta de proceder, y veo ese punto. Por otro lado, si simplemente cortara y pegara todo, desde el capítulo del libro, en un blog de SCN, imagino que SAP Press no estaría muy feliz. Entonces, ¿puedo encontrar un término medio feliz?

ABAP2XLSX viene con un conjunto de programas de demostración. Cada uno demuestra una o más cosas de las que ABAP2XLSX es capaz y da un ejemplo de cómo codificarlo. Me parecen bastante autoexplicativos, pero obviamente no lo son.

El camino a seguir

Pasarela a los extras de Excel

Como mencioné al principio, intentaré hacer mi propio blog ABAP2XLSX mensual, para contrarrestar todos los que reinventan el concepto. Escribiré mis propios programas de demostración.

Para cuando el próximo blog esté listo, habré creado un nuevo repositorio de GitHub para que la gente pueda descargar mis programas de ejemplo. Intentaré explicar el código con tanto detalle como pueda.

Comenzaremos con el caso de uso más básico que es tomar un informe ALV existente y agregar la opción de convertirlo en una hoja de cálculo que luego puede enviarse por correo electrónico a usted mismo (o a cualquier persona) incluso si el programa se ejecuta en segundo plano.

En blogs posteriores, pasaremos a agregar una variedad de funciones ABAP2XLSX adicionales, por ejemplo, configuración de parámetros de impresión, formato condicional, gráficos circulares, etc.

Sin duda, cuando esté listo para mi próximo blog, habrá uno o más blogs publicados por alguien que acaba de inventar una forma de cargar/descargar Excel a/desde ABAP y, cuando eso suceda, les señalaré este blog. que mantendré actualizado a medida que escriba los próximos blogs.

Saludos alegres

Pablo