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.
BOPF: Una evolución del pasado
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.
BOPF es la respuesta a la llegada de la programación orientada a objetos
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.
Tipos de gestión del modelo de programación orientada a objetos
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.
Primera clase: con todos los métodos de actualización
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).
Segunda clase: principalmente es para consultas
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.
Desafíos: tareas que continúan siendo manuales
A pesar de todas estas ventajas, sigue habiendo tareas que se siguen teniendo que hacer manualmente:
- Cacheo de información: Hay que implementar manualmente en qué consultas queremos guardar la información para evitar tener que ir constantemente a la base de datos.
- Actualización de datos: Esta es la parte que se puede ir variando, en algún proyecto, por ejemplo, con los parámetros de entrada de las BAPI, donde tenemos una tabla con los campos con los valores y su equivalente, donde se indica los campos a actualizar. En otros casos, se puede optar por métodos específicos para actualizar determinada información.
- Datos complementarios: Un caso es el de las descripciones, pero, puede ser cualquier tipo de campo calculado. Aunque se tengan métodos generales de lectura de los textos, siempre tienen que ser llamados en cada consulta que se implemente.
- Validaciones: Esta parte es muy subjetiva, porque las validaciones se pueden realizar en el proceso que llama a las clases del modelo de datos o pueden ser implementadas en las propias clases. Para el último caso, el funcionamiento será parecido a los datos complementarios, que, aunque, se tenga un método general de validaciones, habrá que ponerlo en cada método que actualiza el modelo de datos.
La aparición de los BOPF
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:
¿Qué es exactamente BOPF?
“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
Ventajas de utilizar los BOPF
- No pensar en cachear información: el BOPF se encarga de todo, ya sea cuando se leen datos o se actualizan.
- Poder determinar una sola vez los valores de campos, como, por ejemplo, las descripciones, y poder indicar cuándo queremos que se ejecuten: antes de modificar, después, en la creación, actualización, etc..
- Indicar qué campos se quieren modificar, tal solo indicándose por parámetro.
- Definir propiedades de los campos para que solo sean de lectura, obligatorios, etc..
- Definir acciones para que lancen procesos con los datos del BOPF, como, por ejemplo, una acción que llame a la BAPI de creación de pedidos de venta.
- Realizar consultas filtrando por cualquier campo y obtener todos los valores sin necesidad de búsquedas adicionales.
- Las asociaciones permiten leer datos de otros nodos muy fácilmente, ya que todos los nodos se relacionan de arriba a abajo a través de claves propias del BOPF.
- Los BOPF tienen un gestor centralizado de mensajes donde se van acumulando mensajes en validaciones, acciones, etc.
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.
Desafíos de los BOPF
Por supuesto, también tiene inconvenientes o aspectos a tener en cuenta cuando se utilicen:
- No es posible definir la clave que tendrá la tabla donde se guardarán los datos, ya que la proporciona el propio BOPF. Este inconveniente lo suple las claves alternativas que permiten indicar si se permite duplicidad por determinados campos.
En las determinaciones, no es posible indicarle, en tiempo de ejecución, que no se lance.
Dentro de un nodo (determinación, acción, etc.) se puede actualizar datos de cualquier otro nodo, pero no es posible realizar la grabación. Esto siempre se tiene que hacer fuera del BOPF. - Debido al usuario de memoria compartida para cachear los datos, no se debe buscar o actualizar los datos fuera del ecosistema de los BOPF para evitar inconsistencias en los datos.
- Por defecto, por cada nodo que se genera en los BOPF, se crea una consulta para buscar por cualquier campo. En sistemas SAP con base de datos HANA no hay mayor problema, pero, en sistemas con base de datos como Oracle, hay que tenerlo en cuenta, porque los campos se buscan por temas de rendimiento, aunque se pueda crear consultas a medida para suplir este problema.
Arquitectura de un BOPF
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
Capa de la arquitectura BOPF
- La primera capa es la Consumer Layer, que proporciona la API del BOPF que estandariza el acceso a los objetos de negocio. Esta capa puede ser desde un Report, pasando por una Webdynpro hasta un CDS que se publica desde el Cloud de SAP.
- La segunda capa es la Transaction Layer. Es la capa que gestiona las peticiones al más bajo nivel (como gestión de bloqueos, grabaciones, etc.) y cuya API son unos pocos métodos bastante intuitivos.
- La tercera capa es la BOPF Runtime Layer, y es el core de los BOPF. Contiene toda la funcionalidad necesaria para acceder a los nodos, ejecutar validaciones, acceder a las asociaciones, y más.
- La capa final es la Persistence Layer, que se encarga no solo grabar los datos en la base de datos, también se encarga de la gestión del buffer (en la memoria compartida) y la definición de los nodos transitorios o persistentes que se informarán en tiempo de ejecución.
Composición de los BOPF
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
Tipos de nodos
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.
Atributos de los nodos
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.
Algunos conceptos relacionados a los BOPF
Determinaciones
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).
Validaciones
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.
Acciones
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.
Consultas
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.
Conclusión sobre el framework BOPF
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!
