Voy a compartir algunas experiencias que he tenido con S4 HANA y ciertas preconcepciones que sin ser completamente falsas si que son exageraciones probablemente fruto de la campaña publicitaria tan agresiva por parte de SAP.
Durante los 6 meses que duró el proyecto, en el que teníamos que revisar y adaptar un programa encargado a otra consultora, me encontré con muchas situaciones en las cuales cuando preguntas las razones lo que te dicen es “Porque Todo el mundo sabe que… (pon aqui alguna preconcepción de HANA) “.
Esto dio lugar a muchos desafíos en el proyecto, que si bien a mi me vinieron muy bien para asimilar un conocimiento más íntimo de cómo S4/HANA gestiona los datos, es algo que sí que intentaría evitar en un futuro.
Las CDS views pueden mostrar todos los datos que quieras en pantalla en un instante.
Si y no. Es cierto que las CDS views al funcionar en memoria pueden recuperar entradas de las tablas en un instante, pero la misma razón que hace que una búsqueda no sufra tratar columnas específicas (al tratar los datos de forma columnar) trae sus propias limitaciones.
En este tipo de base de datos las columnas generan sus propios indices. Esos indices están comprimidos y preprocesados para evitar duplicidad de información y así agilizar las búsquedas. Pero esto mismo que agiliza buscar entradas en una tabla por campos que no son índices (al contrario que las BD basadas en registros) también genera una sobrecarga cuando se busca por muchas columnas.
En mis experimentos, tratar en memoria mas de 75 columnas impacta en el rendimiento (mas o menos un 25% dependiendo de la cantidad de operaciones que tenga la CDS. Asi que recuperar en un CDS view todas las columnas de la ACDOCA a lo mejor no es la mejor idea del mundo por mucho que tire de la RAM.
Con HANA no tienes que tener cuidado con la memoria
Varias veces durante el proyecto escuche decir que HANA tiene un sistema de recolección de basura muy bueno y que no hace falta liberar variables ni nada. Que todo se limpia automáticamente y que nunca vas a tener problemas de quedarte sin memoria disponible especialmente cuando estás tratando AMDPs.
En mi experiencia esto es cierto a medias. Es cierto que la memoria se va liberando a medida que los programas se cierran, pero también es cierto que los artefactos de HANA se están guardando en la memoria del servidor HANA y no en el de servidor de aplicación. Dos factores pueden afectar seriamente el rendimiento de un programa:
- CDS de tablas enormes con múltiples Joins. Aunque la velocidad de las búsquedas en esas tablas es muy rápida esto no significa que sea conveniente abusar de ello. Cada JOIN crea una tabla intermedia de resultados y estos permanecen en memoria hasta que se termina con la ejecución del programa (y despues tambien pero ya obtienen un estado de “liberable”). En una tabla con unos pocos miles de registros esto no es algo que deba preocuparnos, pero cuando se usan tablas con millones de registros puede llegar a ser un problema.
- AMDPs con una gestión enorme de datos. El recolector de basura no va a liberar ese AMDP hasta que el programa termine ya que está en un estado “activo”. Además cada instancia del AMDP va a usar su propio espacio. Si no se van a usar los datos de esa instancia lo mejor es liberar el objeto. Estos objetos están en la memoria del servidor HANA y esa es compartida entre todas las instancias de los Servidores de Aplicación lo cual puede llegar a ser un problema si además de ser muy pesados muchos usuarios usan ese programa.
Usar los tipos de datos nativos de SQL es lo mejor.
En algún momento he llegado a escuchar que lo mejor es declarar los tipos de datos nativos (nvarchar, varchar, text, nclob…) es lo mejor ya que así se trabaja de forma directa con el motor y no hace falta usar casting. Eso es cierto, declarar las variables de forma nativa evita tener que ir a buscar la definición a otro lado.
Pero en mi caso, sobretodo en los casos de tipo de datos definidos por cliente, me ha dado mejores resultados usar los tipos de diccionario directamente. Usar eso en vez de nvarchar or text me ha evitado algún susto de “type mismatch” cuando ese tipo ha sido cambiado posteriormente ( añadir un decimal adicional, cambiar la longitud del texto…). Es posible que aun así el programa de algun Runtime Error debido alguna conversión interna entre diferentes variables.
Vamos a crear documentos FI de mas de 1000 posiciones.
Eso es cierto. Pero sabiendo que se puede… ¿Deberíamos? Todo depende de la cantidad de validaciones y sustituciones que se tengan implementadas y como. Hana aunque permite que los reportes analiticos puedan tratar una cantidad enorme de datos, no supone una mejora tan grande cuando se están modificando datos en las tablas, sobre todo cuando esas tablas no están permanentemente en memoria.
Aprovechar HANA para intentar mostrar en las facturas todos y cada uno de los movimientos cuando hasta ahora se estaban agrupando por ciertas claves debido a la cantidad de entradas es posible que necesite algún cambio adicional y no solo enviar los movimientos directamente a la BAPI. Lo primero que me preguntaría de todas formas:
¿Es realmente necesario?
¿ Se podrían agregar las entradas de otra forma que permitiera llegar a un detalle aceptable sin llegar a generar documentos con millones de posiciones?
Creo que me extendido un poco… Parece que me pagan por palabra. Vamos a dejarlo aquí y otro dia comparto más aventuras con HANA.