1. Los cambios en ABAP a partir de SAP HANA
1.1. Las nuevas opciones técnicas
- Acelerar: Se refiere a hacer los programas ABAP mas rápidos. Por ejemplo, se puede mejorar el tiempo de ejecución de un programa que se ejecuta en fondo o también podemos mejorar el tiempo de respuesta de un programa de dialogo.
- Ampliar: Debido a la mejoría del tiempo de ejecución de los programas en fondo, tenemos la oportunidad de convertir estos programas en transacciones de dialogo. Además, podemos agregarles funcionalidad como análisis integrados y búsquedas de texto completo con tolerancia a errores. A esto ultimo se le conoce como Full Text Search.
- Innovar: Con SAP HANA nacen las aplicaciones hibridas, es decir, aplicaciones que combinan funciones transaccionales (OLTP) y analíticas (OLAP) dentro de un sistema para que los usuarios finales puedan tomar medidas directas basadas en conocimientos adquiridos en tiempo real.
1.2. El Code Pushdown
Para que las aplicaciones aprovechen las innovaciones de hardware y software de SAP HANA, al menos parte de la lógica de la aplicación debe ejecutarse en la base de datos. A esto se le conoce como pushdown de código (paradigma code-to-data)
Si pasamos la lógica de calculo hacia la capa de base de datos, la transferencia de datos desde la base de datos hacia la capa de aplicación se puede mantener al mínimo. Incluso si se necesitan millones de registros para un cálculo, el sistema solo transfiere los pocos cientos calculados que el usuario desea ver.
- Data-to-code: En este paradigma, la lógica de la aplicación, que comprende la lógica de orquestación y lógica de cálculo, se ejecuta por completo en la capa de aplicación, lo que implica una gran transferencia de datos desde la base de datos hacia la capa de aplicación.
- Code-to-data: Al aplicar este paradigma, la lógica de orquestación se ejecuta en la capa de aplicación y la lógica de cálculo se ejecuta en la capa de base de datos. En un caso extremo, toda la lógica de la aplicación se puede ejecutar en la capa de base de datos.
1.3. La base de datos como una caja blanca
Gracias a la arquitectura del servidor de aplicaciones y a que Open SQL es un lenguaje independiente de la base de datos, podemos desarrollar aplicaciones ABAP sin conocer los detalles específicos de la base de datos, es decir, la base de datos la vemos como una caja negra.
Sin embargo, si la lógica de la aplicación, o al menos parte de ella, ahora debe ejecutarse en la base de datos, el conocimiento de los detalles específicos de la base de datos es muy útil. La base de datos debe convertirse en una caja blanca.
Además de Open SQL, también podemos utilizar Native SQL. Con Native SQL podemos ejecutar operaciones específicas de la base de datos.
Sin embargo, la desventaja de Native SQL es que los programas que utilizan operaciones específicas de la base de datos no se pueden ejecutar en todos los sistemas de bases de datos admitidos por SAP.
%_HINTS ORACLE es un ejemplo de sentencia propia del Native SQL de la base de datos Oracle.
Al optimizar programas para SAP HANA, siempre debemos preguntarnos si estos programas también van a utilizarse en diferentes sistemas de bases de datos. Si bien podríamos, por ejemplo, tener un rendimiento significativamente mejor, tenemos por el otro lado como desventaja el código ABAP dependiente de la base de datos que resulta de esta optimización.
Dentro de un programa, podríamos distinguir entre el código ABAP para SAP HANA y el código ABAP para otros sistemas de base de datos mediante IF...ENDIF o CASE...ENDCASE.
Si el código ABAP se vuelve demasiado complejo, podríamos modularizar cada implementación para cada base de datos. En el caso extremo, deberíamos desarrollar un programa separado para cada sistema de base de datos.