What is the BOPF?

As the name suggests, the BOPF provides a framework for working with business objects (BOs).
This framework provides tools and services which span the entire BO lifecycle:

 Design Time
o At design time, BOs are modeled using the BOPF Workbench tool (Transaction
/BOBF/CONF_UI). This tool makes it possible to model a BO’s nodes/attributes,
behaviors, associations, and so on.
o Behind the scenes, the BO metadata is stored in such a way that it can be introspected
and leveraged by runtime APIs.
o Customers can enhance existing BOs using the BOPF Enhancement Workbench tool
(Transaction /BOBF/CUST_UI). Here, we have the option of defining new nodes and
attributes, defining additional behaviors, and so on. We’ll see how this works up close in
an upcoming blog entry.
 Runtime
o At runtime, BOs are instantiated and controlled via a standard API defined using ABAP
Objects classes.
o Transactions are managed by a central transaction manager class.
o Service-level interactions are brokered via a standard service manager class.
o To some extent, much of this will feel similar to ABAP Object Services. However, as
you’ll soon see, the BOPF affords us a lot more power.

 Consumer Layer
o At the consumer layer, we can utilize the BOPF API methods to create new BOs, search
for existing BOs, update selected BOs, and so on.
 o Frequently, BOPF BOs will be consumed by UI applications such as WDA applications,
etc.
o Of course, that’s not to say that generic consumers cannot get in on the fun as well.
 Transaction layer :
o Interactions with BOs within the BOPF are brokered through a centralized transaction
layer which handles low-level transaction handling details such as object locking, etc
o From the perspective of the consumer layer, interactions with the transaction layer
consist of little more than a handful of intuitive API calls.
 BOPF Runtime Layer :
o The core of the BOPF functionality lies within the BOPF runtime. This layer contains all
of the functionality required to instantiate BOs, trigger their functionality, and so on.
o the BOPF runtime utilizes the BOPF model definitions created at design time as
metadata for instantiating BO instances, navigating BO associations, etc.
 Persistence Layer
o the framework also supports data buffering via shared memory as well as the definition
of transient nodes and attributes that are loaded on demand.

Why do we need the BOPF?

It is here that the BOPF shines. Within the BOPF, everything has its place. Business data is
modeled consistently in BO nodes and attributes. Behaviors are defined as actions. Validations
are performed automatically via validation modules. Triggers can be defined using
determinations. The relationships between BOs is defined statically via associations. Once a
developer becomes comfortable with the framework, the BOPF takes all of the guessing out of
business object development. The BO encapsulates all of the functionality and provides
consistent access to all of the producers/consumers outlined above.

In time, this sort of consistency can give rise to additional frameworks which sit on top of the
BOPF. An example of this is the Floorplan Manager BOPF Integration (FBI) framework which
simplifies the way that FPM feeder classes access BOPF nodes. Much of this will become clearer
as we move on. For now, suffice it so say that the BOPF provides us with a tremendous
springboard for developing business objects.

Anatomy of a Business Object

 Nodes
 o Nodes are used to model a BO’s data.
o Nodes are arranged hierarchically to model the various dimensions of the BO data.
o 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).
o Each node consists of one or more attributes which describe the type of data stored
within the node:
1. 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.
2. A node’s attributes are defined in terms of structure definitions from the ABAP
Dictionary.
o 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 :
o Actions define the services (or behavior) of a BO.
o Actions are assigned to individual nodes within a BO.
o The functionality provided by an action is (usually) defined in terms of an ABAP Objects
class that implements the /BOBF/IF_FRW_ACTION interface.
o To some extent, it is appropriate to think of actions as being similar to the methods of
an ABAP Objects class.
 Associations :
o With associations, we can define a direct and unidirectional relationship from one BO to
another.
o Associations allow us to integrate BOs together in complex assemblies à la Legos™.
 Determinations :
o is an element assigned to a business object node that describes internal changing
business logic on the business object”.
o determinations are analogous to database triggers
o they are functions that are triggered whenever certain triggering conditions are fulfilled.
1. “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.
2. “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..
 3. “Fill transient attributes of persistent nodes”
o This pattern is often used in conjunction with UI development
o we might want to load labels and descriptive texts into a series of
transient attributes to be displayed on the screen.
o Note: This determination can be bypassed via the API if the lookup
process introduces unnecessary overhead.
4. “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.

The logic within a determination is defined via an ABAP Objects class that implements the
/BOBF/IF_FRW_DETERMINATION interface.

 Validations :
o an element of a business object node that describes some internal checking business
logic on the business object”.
o Validations come in two distinct forms:
(a) Action Validations :
(i) Action validations are used to determine whether or not a particular action can
be executed against a BO node.
(b) Consistency Validations
(i) 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 :

 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:
o Node Attribute Queries:
1) 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’).
o Custom Queries :
1) Custom queries allow you define your own query logic by plugging in
an ABAP Objects class that implements the /BOBF/IF_FRW_QUERY
interface.