A variety of Business Objects
This is my very first blog post on SCN, so please keep that in mind when providing feedback 🙂
I find it quite confusing how SAP provides different kinds of so-called “Business Objects”. More specifically, what the term Business Object (in short, BO) might represent in totally different SAP areas.
So, here’s my list of BOs (which I have encountered so far in my two years of ABAP development) and my perception of them in their different use cases:
1. Business Objects in SPI
I chose to put this one first, because I feel most comfortable around this topic. The SPI (Service Provider Infrastructure) is a DMZ-enabled framework used to modularize an application in different layers. (For more details see SPI Wiki )
In this case, a Business Object (BO) is represented by an ABAP class, used as a link between the database and the Service Provider (SP) class from the application model. This class is basically an implementation of the active record pattern (see Wiki definition ) in ABAP with some additional features:
a. As an interjacent agent in the application model, it is recommended that the BO is implemented as a Singleton in order to ensure data consistency.
b. The BO acts as a data buffer by minimizing the database interactions. A special property of this buffer is that, besides having the same structure as the underlying database table, it also has an extra control field (type DBOP) which stores the last operation performed on a particular entry.
c. Fundamentally, the BO is a persistent storage. This means it implements the four basic CRUD functions. Although it is advised to use the same names as the SPI methods:
2. Business Objects in BOPF
Second on my list is the BOPF (Business Objects Processing Framework). I only had some small contact with this one as part of a stand-alone application project where my team and I wanted to try an alternative to the SPI (see 1.). We chose this approach because the business requirements were not clearly defined and we needed to have an easy to modify application model. I suggested the usage of BOPF over SPI as the first also provides flexible tools (transactions BOB, BOBT, BOBX) for generating the business logic, while in the SPI everything needs to be hard coded.
I should also mention that both BOPF and SPI support FPM (Floorplan Manager) integration, so it’s fairly easy to create Web Dynpro UIs with very little or without writing any coding at all.
3. Business Objects in BOR
With R/3 Release 3.0, SAP introduces the Business Object Repository (BOR). Transaction code SWO1 (Business Object Builder, pretty much the same description as Tcode BOB but with a completely different context) is used in to creat new business object types. As I see things, the purpose of these BOs is to prevent developers from accessing directly the database and in turn, provide an interface to particular business areas. BOs are in essence a composition of Interfaces, Key fields, Attributes, Methods and Events.
Object type MDMMARA disposes access to Material data, having methods like:
MDM_MATERIAL.Create (Create Object)
MDM_MATERIAL.Display (Display Object)
and Key fields (Data elements):
MDM_MATERIAL.Material (Material Number)
R/3 application functions are accessed using methods, which are in fact BAPIs.
As this is a relatively old technology, I will not go into more details and allow you to further deepen into this topic. I consider these class of BOs obsolete, yet knowing where the history of BOs began will allow you to better understand where they are heading.
4. BusinessObjects in BI
SAP BusinessObjects (a.k.a. BO, BOBJ) is actually a software company specialized in business intelligence (BI), which was acquired by SAP back in 2007. This has nothing to do with the BOs above, but I thought it brings even more confusion to the term Business Object in the context of SAP.
Hope you enjoyed my very first post,
PS: Feel free to join the discussion!