Cuando se inicia un proyecto, una de las cosas a las que no se suele prestar atención es cómo se gestionará el modelo de datos, es decir, dónde y cómo vamos a grabar los datos en nuestras propias tablas y cómo vamos a recuperarlos.
En este artículo conoceremos qué son los BOPF, sus características y los beneficios de utilizarlos junto a sistemas SAP con base de datos HANA.
Antiguamente, todo el proceso de grabación de datos se solía hacer de manera descentralizada. Es decir, cada función o procedimiento de actualizar los campos que se necesitan o de leer las tablas. Esto hacía que se tuviera código igual o similar esparcido por todo el proyecto.
Esto implicaba que, ante cualquier corrección o mejora habría que empezar a mirar dónde se usaba un procedimiento, tabla, etc. para realizar los cambios. Con lo cual, las mejoras no eran rápidas ni sencillas.
Este problema se iba incrementando a medida que se iba añadiendo funcionalidad parecida a la existente y se volvía a replicar el código, y la bola de nieve no hacía más que crecer provocando la tan temida deuda tecnológica haciendo que, al cabo de un tiempo, los proyectos no fueran mantenibles.
Con la interrupción de la programación orientada a objetos, estos problemas de descentralización se fueron mitigando gracias a la arquitectura MVC en los desarrollos. Con el nuevo paradigma, se comenzó a centralizar el modelo de datos en clases que se encargaban de gestionar procesos a través de sus métodos.
Y, gracias a la herencia y sobrecarga de métodos, es posible ir especializando las clases sin tener que ir llenando el código de condicionales.
No aprovechar las capacidades de la programación orientada a objetos puede provocar el mismo problema que tener el código descentralizado, cuyo mantenimiento será una odisea a medida que surjan nuevas funcionalidades o mejoras de las existentes.
Este tipo de arquitectura suele montar dos clases que gestionan el modelo.
Aunque, generalmente, se tiene un método de edición general, donde se puede editar cualquier valor del modelo, también suele haber métodos que simplifican determinadas actualizaciones (como, por ejemplo, marcar un registro para borrado, que es algo mucho más sencillo).
Es la que suele crecer más rápidamente, al ir añadiendo nuevas funcionalidades. En este tipo de clases, es importante crear pequeños métodos que puedan ser usados por otros (como ir montando piezas de Lego). Por ejemplo, se puede tener un método que obtiene las descripciones de determinados campos según los valores pasados por parámetro y, de esta manera, si cambia la tabla de un texto, solo hay que ir a ese método y cambiarlo.
Se puede pensar que esto también se puede hacer sin usar el modelo de programación orientada a objetos, y sí, es posible. Pero, la propia arquitectura de la programación orientada a objetos permite más flexibilidad al usar parámetros opcionales, limitación del ámbito de variables (adiós a los includes top, donde las variables globales nunca se destruyen, a pesar de haber terminado la ejecución), y más.
A pesar de todas estas ventajas, sigue habiendo tareas que se siguen teniendo que hacer manualmente:
Los BOPF surgen de la necesidad de evitar todo este trabajo manual a la hora de gestionar el modelo de datos de una aplicación. Una definición posible de los BOPF es la siguiente:
“BOPF es un framework que está orientado a objetos, que proporciona una serie de servicios genéricos y funcionalidades que permiten estandarizar, modularizar y acelerar los desarrollos. Con los BOPF, toda la gestión de autorización, gestión de los datos, gestión memorias intermedias, API para su gestión son simplificadas para que el desarrollador se centre en los procesos de negocio”.
Fuente: Sap Community
Todas estas ventajas hacen que uno pueda centrarse más en los procesos que en cómo se van a gestionar los datos, ganando mucho tiempo en el desarrollo de aplicaciones.
Por supuesto, también tiene inconvenientes o aspectos a tener en cuenta cuando se utilicen:
La arquitectura de un BOPF está compuesta por una serie de capas cuyo objetivo es simplificar el desarrollo, dejando los procesos más tediosos (procesos transaccionales, buffers, etc.) en manos del propio framework. La arquitectura de un BOPF es la siguiente:
Fuente: Libro BOPF, Business Object Development
Los BOPF están compuestos por un conjunto de nodos (podemos hacer BOPF de un solo nodo) que se relacionan entre sí mediante asociaciones. Un BOPF tiene que tener, al menos, un nodo, que, generalmente, se le llama root, y el resto de nodos cuelgan de él.
A un nodo se le pueden asociar acciones, validaciones, determinaciones, etc, tal como podemos ver en la imagen:
Fuente: SAP Community
Los nodos es donde gira todo alrededor de los BOPF. Hay dos tipos de nodos: persistentes y transitorios. Los persistentes son aquellos cuyos datos se grabarán en base de datos, mientras que los transitorios son aquellos cuyos datos se determinan en tiempo de ejecución. El origen del dato de estos últimos puede venir desde un servicio web o de un fichero plano.
Los nodos se componen en atributos, que pueden ser persistentes, cuyos campos se graban en base de datos y transitorios, cuyos valores se determinan en tiempo de ejecución. Un ejemplo de transitorios serían las descripciones de los campos.
En los atributos persistentes, no se definen campos clave, sino que será el propio BOPF que lo cree cuando se cree la tabla. Si se quiere tener una clave propia, que en ningún momento sustituye a la propia del BOPF, hay que crear una alternative key.
Las determination podemos definirlas como los triggers de base de datos. Se pueden indicar que se lancen antes de grabar, después, en la validación, etc. y en qué momento: creación, actualización o borrado.
Las determinaciones se utilizan para la obtención de descripciones, el relleno de campos (como, por ejemplo, campos de creación o última modificación de un registro) o para informar otros nodos de manera automática (por ejemplo, tablas de logs).
Las validations permiten realizar dos tipos de validaciones en un nodo: validaciones de acciones y de datos. Las validaciones de acciones habilitan según determinadas condiciones que una acción puede ser ejecutada, mientras que las validaciones de datos permiten verificar que los datos pasados son correctos.
Las actions permiten lanzar procesos en base a los datos del nodo. Se pueden utilizar para crear pedidos de venta, lanzar workflows, etc. Permiten el paso de parámetro y devolver datos con el resultado del proceso.
Por defecto, en los nodos se crean dos tipos de consultas: búsqueda por campo clave y búsqueda de elementos. La primera se usa, principalmente, cuando se conoce la clave del nodo de antemano, pero, la segunda, es la que permite buscar por cualquier campo del nodo.
En caso de ser necesario, es posible crear consultas a medida donde se le pasarán unos parámetros de entrada y una tabla de datos de salida. Aunque, si se dispone de base de datos HANA, con la búsqueda por elementos no es necesario crear consultas a medida.
El framework BOPF presenta diversas ventajas y desafíos. Utilizándolo con la tecnología SAP HANA se pueden maximizar sus resultados.
Si quieres comenzar a aplicar esta tecnología en tu empresa para mejorar sus procesos y operaciones, envíanos un mensaje. ¡Estamos preparados para asumir el reto!
Creamos nuevos productos y servicios superiores hibridando la tecnología con los modelos de negocio
