March 28

Business Object Processing Framework – Introduction & Architecture

BOPF stands for “Business Object Processing Framework”. BOPF is an ABAP OO-based framework that provides a set of generic services and functionalities to speed up, standardize, and modularize your development. BOPF manages the entire life cycle of your business objects and covers all aspects of your business application development. Instead of expending effort for developing an application infrastructure, the developer can focus on the individual business logic.

With BOPF, you have a framework at your disposal with which you can seamlessly integrate different components of business applications. You can use them out-of-the-box. When using BOPF you don’t have to care about the development of adapters or integration layers to consume the following components:


BOPF is a framework for working with business objects (BOs). This framework was designed from the ground up to manage the entire life cycle of BO development, saving you from having
to reinvent the wheel each time you need to develop a new BO. At a high-level, we can organize the services and functionality of the BOPF into two basic categories:

  • Design Time
    At design time, the BOPF provides a series of workbench tools that are
    used to model and construct BOs. Here, graphical editor screens and
    wizards are furnished to guide developers through the various stages of
    the BO development process.
  • Runtime
    At runtime, the BOPF provides a runtime framework which manages
    business object instances. Here, there’s built-in functionality for automatic
    persistence, transaction and life cycle management, caching, and
    much, much more.


As per above screenshot, BOPF application design calls for a layered approach to development:

  • Consumer Layer
    At the consumer layer, clients can utilize the BOPF’s object-oriented API to interface with BOs. Because this API is generic, it’s very easy to develop universal consumer frameworks that sit on top of the BOPF. A couple of the more notable consumer frameworks at the time of this writing include the FPM-BOPF Integration (FBI) and Gateway-BOPF Integration (GBI) frameworks which integrate the BOPF with the Floorplan Manager (FPM) and SAP Gateway toolsets, respectively. These integration
    frameworks make it very easy to develop UI-centric applications using the FPM and SAPUI5 UI frameworks.
  • Transaction Layer
    Client sessions are managed through a centralized transaction layer which handles low-level transaction handling details such as object locking and commit handling.
  • BOPF Run time Layer
    The core of the BOPF functionality exists within the BOPF run time which is implemented via a series of standard-delivered classes provided by SAP. This layer contains all of the functionality needed to instantiate BOs, handle life cycle events, and respond to client-level interactions.
  • Persistence Layer
    As you might expect, the persistence layer provides the low-level functionality
    needed to persist BO instances to the database.

Anatomy of a Business Object

From a modeling perspective, BOs are made up of several different types of entities:

  • Nodes
    • Nodes are used to model a BO’s data.
    • Nodes are arranged hierarchically to model the various dimensions of the BO data. This hierarchy is organized underneath a single root node (much like XML). From there, the hierarchy can be nested arbitrarily deep depending upon business requirements.
    • There are several different node types supported by the BOPF. However, most of the time you’ll find yourself working with persistent nodes (e.g. nodes which are backed by the database). It is also possible to define transient nodes whose contents are loaded on demand at runtime. These types of nodes can come in handy whenever we want to bridge some alternative persistence model (e.g. data obtained via service calls).
    • Each node consists of one or more attributes which describe the type of data stored within the node:
      • Attributes come in two distinct varieties: persistent attributes and transient attributes. Persistent attributes represent those attributes that will be persisted whenever the BO is saved. Transient attributes are volatile attributes which are loaded on demand.
      • A node’s attributes are defined in terms of structure definitions from the ABAP Dictionary.
    • At runtime, a BO node is like a container which may have zero, one, or many rows. If you’re familiar with the concept of controller contexts with the Web Dynpro programming model, then this concept should feel familiar to you. If not, don’t worry; we’ll demonstrate how this works whenever we look at the BOPF API.
  • Actions
    • Actions define the services (or behavior) of a BO.
    • Actions are assigned to individual nodes within a BO.
    • The functionality provided by an action is (usually) defined in terms of an ABAP Objects class that implements the /BOBF/IF_FRW_ACTION interface.
    • To some extent, it is appropriate to think of actions as being similar to the methods of an ABAP Objects class.
  • Associations
    • Though BOs are designed to be self-contained, autonomous entities, they do not have to exist in isolation. With associations, we can define a direct and unidirectional relationship from one BO to another.
    • For example, in just a moment, we’ll take a look at a sample BO called /BOBF/DEMO_SALES_ORDER which is used to model sales orders. Here, we’ll see how the product assignments for sales order items is defined in terms of an association with a product BO called /BOBF/DEMO_PRODUCT. This composition technique makes it possible to not only leverage the product BOs data model, but also its behaviors, etc.
    • Associations allow us to integrate BOs together in complex assemblies à la Legos™.
  • Determinations
    • According to the aforementioned BOPF enhancement guide, a determination “is an element assigned to a business object node that describes internal changing business logic on the business object”.
    • In some respects, determinations are analogous to database triggers. In other words, they are functions that are triggered whenever certain triggering conditions are fulfilled. These conditions are described in terms of a series of patterns:
      • “Derive dependent data immediately after modification”
        • This pattern allows us to react to changes made to a given BO node. For example, we might use this event to go clean up some related data.
      • “Derive dependent data before saving”
        • This pattern allows us to hang some custom logic on a given BO node before it is saved. This could be as simple as using a number range object to assign an ID value to a node attribute or as complex as triggering an interface.
      • “Fill transient attributes of persistent nodes”
        • This pattern is often used in conjunction with UI development. Here, we might want to load labels and descriptive texts into a series of transient attributes to be displayed on the screen.
        • Note: This determination can be bypassed via the API if the lookup process introduces unnecessary overhead.
      • “Derive instances of transient nodes”
        • This pattern allows us to load transient nodes into memory on demand. Here, for example, we might lookup real-time status data from a Web service and load it into the attributes of a transient node from downstream consumption.
    • Determination patterns are described in detail within the aforementioned BOPF enhancement guide.
    • The logic within a determination is defined via an ABAP Objects class that implements the /BOBF/IF_FRW_DETERMINATION interface.
  • Validations
    • According to the BOPF enhancement guide, validations are “an element of a business object node that describes some internal checking business logic on the business object”.
    • Validations come in two distinct forms:
      • Action Validations
        • Action validations are used to determine whether or not a particular action can be executed against a BO node.
      • Consistency Validations
        • As the name suggests, consistency validations are used to ensure that a BO node is consistent. Such validations are called at pre-defined points within the BOPF BO transaction cycle to ensure that BO nodes are persisted in a consistent state.
    • The validation logic is encapsulated within an ABAP Objects class that implements the /BOBF/IF_FRW_VALIDATION interface.
  • Queries
    • Queries are BO node entities which allow us to search for BOs using various types of search criteria.
    • Queries make it possible for consumers to access BOs without knowing the BO key up front.
    • Queries also integrate quite nicely with search frameworks and the like.
    • Queries come in two varieties:
      • Node Attribute Queries
        • Node attribute queries are modeled queries whose logic is defined within the BOPF runtime. These simple queries can be used whenever you simply need to search for BO nodes by their attributes (e.g. ID = ‘12345’).
      • Custom Queries
        • Custom queries allow you define your own query logic by plugging in an ABAP Objects class that implements the /BOBF/IF_FRW_QUERY interface.



Introduction to Business Object Processing Framework (BOPF)

Navigating the BOPF: Part 2 – Business Object Overview

BOPF – SAP Press E-Bite