Introducción a BOPF:

Business Object Processing Framework es un marco basado en ABAP OO que proporciona un

conjunto de servicios y funcionalidades genéricas para acelerar, estandarizar y modularizar su
desarrollo.

BOPF controla la lógica empresarial de la aplicación, así como la recuperación de datos del
búfer y la capa de persistencia. Los principales principios de diseño son una separación clara de
la lógica comercial y el almacenamiento en búfer de los datos, así como una estructuración clara
de la lógica comercial en partes pequeñas con una separación clara de cambiar y verificar la
lógica comercial. El enfoque BOPF para implementar objetos comerciales divide la lógica
comercial en los siguientes cuatro conceptos:

● Comportamiento
● Determinaciones
● Validaciones
● Consultas

Transacciones importantes a tener en cuenta al trabajar en BOPF:

/BOBF/CONF_UI: Esta transacción se utiliza para mostrar el modelado de los objetos

comerciales de TM (Transport Management). Esto se llama Herramienta de modelado BOPF.

/BOBF/CUST_UI: Esta transacción se utiliza para iniciar el BOPF Enhancenment Workbench.

Esta transacción se utiliza para mejorar los objetos comerciales estándar y para crear nuevos
objetos comerciales. (DEPRECATED → usar TX BOBX).

/BOBF/TEST_UI: Esta transacción se utiliza como entorno de prueba. Esta transacción ayudaría
al consultor (ya sea funcional o técnico) a ver los datos de una orden de expedición, orden de
flete o reserva de flete en particular.

Caso de uso

A diferencia de ABAP, aquí seguimos un enfoque diferente en BOPF para recuperar los datos de
la base de datos. No vamos a escribir ninguna consulta de selección;

En cambio, los datos se recuperan llamando a los métodos estándar: QUERY, RETRIEVE y
RETRIEVE BY ASSOCIATION, según la relación entre los nodos en un objeto comercial.

Fuente: https://blogs.sap.com/2014/02/21/bopf-overview-and-report-development-with-a-usecase/

La arquitectura BOPF utiliza un enfoque en capas:

Capa de consumidores
 ● En la capa del consumidor, podemos utilizar los métodos de la API de BOPF para crear
nuevos BO, buscar BO existentes, actualizar los BO seleccionados, etc.
● Con frecuencia, los BO de BOPF serán consumidos por aplicaciones de interfaz de
usuario, como aplicaciones WDA, etc.

Capa de transacción

● Las interacciones con los BO dentro de BOPF se negocian a través de una capa de
transacción centralizada que maneja los detalles de manejo de transacciones de bajo
nivel, como el bloqueo de objetos, etc.
● Desde la perspectiva de la capa del consumidor, las interacciones con la capa de
transacción consisten en poco más que un puñado de llamadas API intuitivas.

Capa de tiempo de ejecución BOPF

● El núcleo de la funcionalidad de BOPF se encuentra dentro del tiempo de ejecución de

BOPF. Esta capa contiene toda la funcionalidad necesaria para crear instancias de BO,
activar su funcionalidad, etc.
● Como puede ver en la figura, el tiempo de ejecución de BOPF utiliza las definiciones del
modelo BOPF creadas en el momento del diseño como metadatos para instanciar
instancias de BO, navegar por asociaciones de BO, etc.

Capa de persistencia

● Una de las cosas buenas de BOPF es que es bastante flexible en la capa de

persistencia. Aunque el objetivo final normalmente es almacenar datos de BO dentro de
la base de datos, el marco también admite el almacenamiento en búfer de datos a través
de la memoria compartida, así como la definición de nodos transitorios y atributos que se
cargan a pedido.
Dentro del BOPF todo tiene su sitio. Los datos empresariales se modelan de forma coherente en
nodos y atributos de BO. Los comportamientos se definen como acciones. Las validaciones se
realizan automáticamente a través de módulos de validación. Los activadores se pueden definir
mediante determinaciones. Las relaciones entre los BO se definen estáticamente a través de
asociaciones. Una vez que un desarrollador se siente cómodo con el marco, el BOPF elimina
todas las conjeturas del desarrollo de objetos comerciales. El BO encapsula toda la
funcionalidad y brinda acceso constante a todos los productores/consumidores descritos
anteriormente.

Fuente: https://blogs.sap.com/2013/01/04/navigating-the-bopf-part-1-getting-started/

De acuerdo con la documentación de BOPF Enhancement Workbench de SAP, los objetos

comerciales dentro de BOPF son "una representación de un tipo de entidad comercial
identificable de forma única descrita por un modelo estructural y un modelo de proceso interno".
Esto quiere decir que los objetos de negocio BOPF:

● Tiene un modelo de componentes bien definido.

● Tiene un modelo de proceso bien definido que gobierna el ciclo de vida del objeto
comercial, los comportamientos, etc.
● Se ejecuta dentro de un entorno similar a un contenedor que maneja tareas de bajo nivel
como el almacenamiento en caché, la gestión de transacciones, etc.

Anatomía de un objeto comercial

● Nodos
○ Los nodos se utilizan para modelar los datos de un BO.
○ Los nodos se organizan jerárquicamente para modelar las diversas dimensiones
de los datos de BO. Esta jerarquía está organizada debajo de un solo nodo raíz
(muy parecido a XML). A partir de ahí, la jerarquía se puede anidar
arbitrariamente según los requisitos comerciales.
○ La mayor parte del tiempo se encontrará trabajando con nodos persistentes (por
ejemplo, nodos respaldados por la base de datos). También es posible definir
nodos transitorios cuyos contenidos se cargan bajo demanda en tiempo de
ejecución.
○ Cada nodo consta de uno o más atributos que describen el tipo de datos
almacenados en el nodo:
■ Los atributos vienen en dos variedades distintas: atributos persistentes y
atributos transitorios. Los atributos persistentes representan aquellos
atributos que persistirán cada vez que se guarde el BO. Los atributos
transitorios son atributos volátiles que se cargan bajo demanda.
 ■ Los atributos de un nodo se definen en términos de definiciones de
estructura del Diccionario ABAP.
○ En tiempo de ejecución, un nodo BO es como un contenedor que puede tener
cero, una o muchas filas.
● Comportamiento:
○ Las acciones definen los servicios (o el comportamiento) de un BO.
○ Las acciones se asignan a nodos individuales dentro de un BO.
○ La funcionalidad proporcionada por una acción (generalmente) se define en
términos de una clase de Objetos ABAP que implementa la interfaz
/BOBF/IF_FRW_ACTION.
○ Hasta cierto punto, es apropiado pensar en las acciones como similares a los
métodos de una clase de Objetos ABAP.
● Asociaciones
○ Aunque los BO están diseñados para ser entidades autónomas y
autocontenidas, no tienen que existir de forma aislada. Con las asociaciones
podemos definir una relación directa y unidireccional de un BO a otro.
● Determinaciones
○ De acuerdo con la guía de mejora de BOPF mencionada anteriormente, una
determinación "es un elemento asignado a un nodo de objeto comercial que
describe la lógica comercial interna cambiante en el objeto comercial"
○ En algunos aspectos, las determinaciones son análogas a los disparadores de
bases de datos. En otras palabras, son funciones que se activan siempre que se
cumplan determinadas condiciones de activación. Estas condiciones se
describen en términos de una serie de patrones :
■ "Obtener datos dependientes inmediatamente después de la
modificación"
■ "Obtener datos dependientes antes de guardar"
■ “Rellenar atributos transitorios de nodos persistentes”
■ "Deriva instancias de nodos transitorios"
○ La lógica dentro de una determinación se define a través de una clase de
Objetos ABAP que implementa la interfaz /BOBF/IF_FRW_DETERMINATION.
● Validaciones
○ De acuerdo con la guía de mejora de BOPF, las validaciones son "un elemento
de un nodo de objeto comercial que describe alguna lógica comercial de
verificación interna en el objeto comercial".
○ Validaciones de acciones:

Las validaciones de acciones se utilizan para determinar si una acción en

particular se puede ejecutar o no contra un nodo BO.
 ○ Validaciones de consistencia

Como sugiere el nombre, las validaciones de coherencia se utilizan para

garantizar que un nodo BO sea coherente. Dichas validaciones se llaman en
puntos predefinidos dentro del ciclo de transacción BOPF BO para garantizar
que los nodos BO se mantengan en un estado consistente.

○ La lógica de validación se encapsula dentro de una clase de Objetos ABAP que

implementa la interfaz /BOBF/IF_FRW_VALIDATION.
● Consultas
○ Las consultas son entidades de nodos BO que nos permiten buscar BO
utilizando varios tipos de criterios de búsqueda.
○ Las consultas hacen posible que los consumidores accedan a los BO sin
conocer la clave BO por adelantado.
○ Las consultas también se integran bastante bien con los marcos de búsqueda y
similares.
○ Las consultas vienen en dos variedades:
■ Consultas de atributos de nodo

Las consultas de atributos de nodo son consultas modeladas cuya lógica

se define dentro del tiempo de ejecución de BOPF. Estas consultas
simples se pueden usar siempre que simplemente necesite buscar nodos
BO por sus atributos (por ejemplo, ID = '12345').

■ Consultas personalizadas

Las consultas personalizadas le permiten definir su propia lógica de

consulta conectando una clase de Objetos ABAP que implementa la
interfaz /BOBF/IF_FRW_QUERY.

Fuente: https://blogs.sap.com/2013/01/04/navigating-the-bopf-part-2-business-object-overview/

Descripción general de la API de BOPF

● /BOBF/IF_TRA_TRANSACTION_MGR
○ Esta referencia de objeto proporciona un administrador de transacciones que se
puede usar para administrar cambios transaccionales. Dichas transacciones
podrían contener un solo paso (por ejemplo, actualizar el nodo X) o dividirse en
varios pasos (agregar un nodo, llamar a una acción, etc.).
 ● /BOBF/IF_TRA_SERVICE_MANAGER
○ La referencia del objeto del administrador de servicios nos proporciona los
métodos que necesitamos para buscar nodos BO, actualizar nodos BO,
desencadenar validaciones, realizar acciones, etc.
● /BOBF/IF_FRW_CONFIGURATION
○ Esta referencia de objeto nos proporciona metadatos para un BO en particular.
Exploraremos la utilidad de tener acceso a estos metadatos próximamente.

Ejemplo de clase local que implementa BO:

CLASS lcl_demo DEFINITION CREATE PRIVATE.

PRIVATE SECTION.
DATA mo_txn_mngr TYPE REF TO /bobf/if_tra_transaction_mgr.
DATA mo_svc_mngr TYPE REF TO /bobf/if_tra_service_manager.
DATA mo_bo_conf TYPE REF TO /bobf/if_frw_configuration.
METHODS:

constructor RAISING /bobf/cx_frw.

ENDCLASS.

CLASS lcl_demo IMPLEMENTATION.

 METHOD constructor.

"Obtain a reference to the BOPF transaction manager:

me->mo_txn_mngr =

/bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ).

"Obtain a reference to the BOPF service manager:

me->mo_svc_mngr =

/bobf/cl_tra_serv_mgr_factory=>get_service_manager(

/bobf/if_demo_customer_c=>sc_bo_key ).

"Access the metadata for the /BOBF/DEMO_CUSTOMER BO:

me->mo_bo_conf =
/bobf/cl_frw_factory=>get_configuration(
/bobf/if_demo_customer_c=>sc_bo_key ).
ENDMETHOD. " METHOD constructor
ENDCLASS.

● En este caso if_demo_customer_c es una interfaz de constantes autogenerada al crear

el BO.

Fuente:https://blogs.sap.com/2013/01/16/navigating-the-bopf-part-3-working-with-the-bopf-a
pi/