Last year, I began working on a project which was rolling out the new SAP Environment Health and Safety Management (EHSM) module. This module utilizes some of the more cutting edge technologies in the ABAP space: Floorplan Manager, Web Dynpro ABAP, Adobe Interactive Forms, and so on. In addition to these standard technologies, EHSM also utilizes a technology framework that I had not encountered previously: the Business Object Processing Framework (or BOPF).
Whenever I started investigating the BOPF, the first place I went to look was naturally right here at the SDN. However, between SDN and Google, I found very little information to go on when it comes to working with the BOPF. Indeed, about the only useful documentation I found was an enhancement guide entitled BOPF Enhancement Workbench. What I was really looking for though was an in-depth description of the architecture of the BOPF, its API, and most importantly, some examples demonstrating its usage. Short of that, I was left to muddle my way through much of the SAP standard code until I began to understand how the different pieces fit together.
After working with the technology for the better part of a year, I thought I would launch a blog series documenting my findings for others who share a similar plight. This includes other EHSM developers as well as developers working in other new dimension modules such as SAP Transportation Management (TM), etc. I hope you will find it useful.
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
- 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. If you're comfortable with OOP concepts, then this will seem vaguely familiar to modeling classes in the Class Builder tool. (Note:
So far, it seems that this tool is locked down for customer use. This implies that we cannot create new BOs of our own...yet.As per Thea Hillenbrand's comments below, the BOPF has been opened up for general customer use. This happened with SAP Business Suite EHP5 SP11 and SAP Business Suite EHP6 SP05. The related note is 1760610. Thanks Thea!) - Behind the scenes, the BO metadata is stored in such a way that it can be introspected and leveraged by runtime APIs.
- 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.
- 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. If you're comfortable with OOP concepts, then this will seem vaguely familiar to modeling classes in the Class Builder tool. (Note:
- Runtime
- At runtime, BOs are instantiated and controlled via a standard API defined using ABAP Objects classes.
- Transactions are managed by a central transaction manager class.
- Service-level interactions are brokered via a standard service manager class.
- 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.
The figure below illustrates how these different pieces fit together within an application. As you can see, the BOPF architecture utilizes a layered approach:
- Consumer Layer
- 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.
- Frequently, BOPF BOs will be consumed by UI applications such as WDA applications, etc.
- Of course, that's not to say that generic consumers cannot get in on the fun as well.
- Transaction Layer
- 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.
- 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
- 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.
- As you can see in the figure, the BOPF runtime utilizes the BOPF model definitions created at design time as metadata for instantiating BO instances, navigating BO associations, etc.
- Persistence Layer
- One of the nice things about the BOPF is that it is rather flexible at the persistence layer. Though the end goal is normally to store BO data within the database, the framework also supports data buffering via shared memory as well as the definition of transient nodes and attributes that are loaded on demand.
Though the BOPF shares certain similarities to previous business object models (e.g. business objects defined in Transaction SWO1, GENIL, and BOL), it is quite a bit more evolved than any prior business object model defined by SAP. This will become obvious as we delve into specific topics in the upcoming blog entries.
Why do we need the BOPF?
Whenever a new development framework comes out, it is only natural for developers to wonder if the framework is truly needed. Though I will not endeavor to sell anyone on the merits of the BOPF within this blog series, I think it is useful to compare and contrast the scope of a development project with and without the BOPF. Then, you can decide for yourself if the BOPF provides value.
To put this in perspective, let's imagine that we're tasked with developing a new module around some custom-defined business entity. A minimal bill of materials in terms of development objects for this module are as follows:
- The entity data will be stored within a series of ABAP Dictionary tables. If desired, we can use ABAP Object Services to create an ORM wrapper around these table accesses.
- In order to synchronize access to the entity data, we'll need to define one or more lock objects. Plus, we'll need a mechanism to ensure that the lock objects are used to control access to the data.
- To secure access to the entity data, we must create one or more authorization objects so that we can define granular authorization control.
Now, in an an ideal world, we would attempt to encapsulate access to the entity data by creating a series of ABAP Object classes (e.g. entity classes and the like). These classes would offer basic CRUD (Create, Remove, Update, and Display) operations that provide users with a one-stop shop for accessing and updating the entity data.
With these basic components in place, we can then build the core application functionality. Here, we'll find a number of producers/consumers of the entity data:
- UI applications based on WDA, BSP, or even classic Dynpro technology.
- BI extractors used to export the data for reporting purposes
- SAP Business Workflow processes
- Custom accessor modules used to supply data to home grown reports (e.g. ALV), Adobe Interactive Forms, and so on
- Interface and conversion programs (or, in SOA initiatives, Web service wrappers)
- Others as needed
Overall, these kinds of development objects are pretty standard fare for the average ABAP developer. However, within the context of your typical SAP project, these tasks are often distributed across a large development team. Here, it can be difficult to enforce best practices and ensure that each developer accesses the entity data properly. Frequently, this is as a result of developers not understanding how to access the data via a custom API (provided there is one). In short, there's no overarching object model which ensures that business objects are accessed consistently.
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.
Next Steps
Now that you have a basic feel for what the BOPF is all about, we'll move on to some more specific topics of interest. In my next blog, I'll tackle BOs from a design perspective.
- SAP Managed Tags:
15 Comments
