Business Object Repository ( B O R )
SAP's Business Object Repository gives you an improved way to integrate business processes with external partners -- an increasingly necessary ability in the burgeoning e-marketplace economy.
The age of e has had a profound effect on the IT industry. Not only has it changed our way of life, but it has also forced systems such as SAP to embrace a new era of openness. Marketplace demands for flexible automation of inter-business workflow and intelligent data exchange have forced formerly very proprietary ERP systems to begin helping customers integrate with other companies and with e-marketplaces data formats. For the first time, companies must expose their business processes to the outside world.
In order to achieve this openness, SAP provides a technical infrastructure for the R/3 product, the Business Object Repository (BOR), which provides a simple yet powerful mechanism for external systems to trigger core business processes (such as placing an order) without concern for the underlying data structure. This level of abstraction is beneficial because it decouples R/3 from the external system. Either system is therefore free to change its internal business processes without affecting the other. SAP provides this technical infrastructure using a component-based view of its system. Each component or object provides a view of the data and the business processes that interact with that data. External systems can access this data via BAPI methods, which in turn access the underlying data structures of the system. It is the responsibility of the object and the BAPI to ensure the integrity of the data. This encapsulation of the data not only lends itself to external interfaces, but by using objects from within SAP, you can greatly reduce implementation, testing, and maintenance effort via the promotion of code reuse.
Business Objects
A business object is a problem-domain entity that you model in the SAP system, such as SalesOrder, BillingDocument, and Employee. The BOR stores all the objects in the R/3 system. The repository is a group of all the objects in the R/3 system. If the focus of objects is to model atomic business processes then it can be said that the BOR provides an enterprisewide view of business processes. By designing your ABAP code to fit your business processes you increase the ability of that code to flex when those processes are altered or integrated with external systems. This had made the object-oriented approach, which the BOR provides, essential to developing inter-business or e-business functionality.
Attributes
A business object is primarily represented by its attributes. You perform actions, such as create, update, or delete on the attributes by calling the methods of the object.
Attribute NetValue of Object BUS2032 (SalesOrder).
The majority of attributes are data-dictionary fields (for example, the NetValue attribute is defined by VBAK-NETWR). When you access an attribute of an object, you execute a SQL statement that retrieves the corresponding field in the database.
Definition of attribute NetValue.
You can also define attributes that do not exist in the data dictionary. These attributes are called virtual attributes. For example, a business partner has an attribute called BirthDate that is stored in the data dictionary. You can add a virtual attribute to the BusinessPartner object called Age. The age of a business partner is not stored in the database, but you can calculate it using the current date and the birth date of the business partner. If you implement the ABAP code that calculates Age, every time you access the Age attribute, the code executes and returns the business partners age.
Definition of virtual attribute Age.
This is an excellent example of one of the tools that a component-based approach provides. The external system does not need to concern itself with how to gather the data that it requires. The calling program needs only to access the attribute for the data to be returned. This is how business objects decouple the calling program (whether it be in R/3 or external to R/3) from the internals of R/3.
The BOR lets you define multi-line attributes. These attributes define one-to-many relationships between an object and other fields. These objects can be defined in the data dictionary or can also be virtual attributes.
An attribute that uniquely defines an object in the system is called a key attribute. In the case of a SalesOrder, the key attribute is VBAK-VBELN (the TableName and FieldName). It is not uncommon for an object to have several key fields. An example of this is object is the SalesArea (BUS000603) object type which has SalesOrganization (TVTA-VKORG), DistributionChannel (TVTA-VTWEG) and Division (TVTA-SPARTE) as key fields.
Methods
As mentioned earlier, the methods of an object represent the actions you take with objects attributes. An action in this example would include retrieving the status of one or more sales orders based on specific criteria. Methods are analogous to function modules in that they have importing and exporting parameters as well as exceptions, which you view by selecting a method and clicking on the toolbar button. This allows external systems (or internal developments) to pass and accept parameters from these methods just as if they were using function modules -- allowing external systems to call methods.
In Figure 4, the methods shown with the green LED are BAPIs that are called specifically from external systems. They can, however, be called from within the system itself. The method shown with the stop sign is obsolete, but retained for backward compatibility, and should not be used in new developments.
Methods of SalesOrder.
Delegation and Subtyping
One of the most complex concepts in object-oriented development is that of inheritance. This concept lets you extend core functionality by creating a child of the parent object that inherits all of its attributes and methods. For example, a Manager object is a subtype (child) of the Employee object. The Manager object has all the attributes of an Employee object (such as EmployeeID or Name) but also has some extra attributes (such as CompanyCar or ParkingSpace). SAP has not implemented inheritance in the BOR. However, it has provided subtyping and delegation, which offer an alternative way to extend R/3 functionality.
Subtyping
A subtype of an object is another object whose creation is based upon a parent object (see the preceding manager/employee example). The subtype maintains references to all the attributes and methods of its parent object. This means that any methods and attributes defined on the parent can be executed and accessed on the child object. I have often heard less-experienced developers refer to subtyping as copying the parent object. Although the effects can be similar, in order to achieve an understanding of some of the more advanced concepts, such as interface inheritance, it is important to realize that this is not accurate.
If a subtype object were merely a copy of its parent, then all the code contained within the parent would be physically copied to the child. This is not the case. The subtype simply maintains references to its parents methods and attributes. The real difference is that the subtype lets you redefine these methods and attributes. You can easily add your own business rules to the parent methods by redefining the subtypes method. In the following example, I will show why this distinction is so important.
Subtyping Case Study
As an ABAP developer at Acme Tyres Pty. Ltd., you have been given the task of implementing some security measures for the companys online store. The requirement is simple: The password must be at least six characters long.
Modifying SAP code leads to costly and complicated upgrades due to the modified code being overwritten by the newly delivered SAP code. Therefore, The challenge is finding a way of implementing the business logic without modifying SAP code.
After some investigation, you realize that the method CHANGEPASSWORD (in BAPI) on the object KNA1 (Customer) is called when customers change their passwords. All you need to do is create a subtype of KNA1 and then redefine the CHANGEPASSWORD method adding the ABAP code to ensure that the password is a minimum of six characters long. It is of course not wise to change SAP code even assuming you have the passwords, which can be provided only be SAP. After the method is redefined, you just need to implement the business rules in ABAP.
FIGURE 5 Redefinition of ChangePassword method.
It is imperative that once you redefine the method it still behaves in a similar manner. You are allowed to add extra business logic, but the method must still change the password rather than do something unexpected, like delete a customer. This is particularly important when SAP is being accessed from external systems. The external system will expect a method to provide certain functionality. The developer should take care to ensure that this expectation is met.
Delegation
Now that you have implemented a new CHANGEPASSWORD method, you need to tell the SAP system to use the redefined version of CHANGEPASSWORD and not the version that was delivered on the KNA1 object. This is similar to object-oriented inheritance but the two concepts do have fundamental differences.
Delegation for objects.
By making an entry in the delegation table, you tell R/3 that before executing a method on KNA1, it should first check if that method has been redefined on the subtype. If it has, then the system executes the redefined method . If it hasn't, then the system executes the original method. Figure 7 illustrates this process.
Execution flow for methods with delegation.
This delegation is powerful because it lets you implement your own business logic without modifying any SAP code. As long as the objects are properly delegated, your method will be executed.
Responsibility
So far I have shown you two major components of an object, its attributes and methods. The difficulty in SAP is that it has traditionally been a data-driven, procedural-development approach. The BOR is not well understood by developers and managers and thus it is shunned by those that stand to gain the most from it. If managers and developers alike would take a formalized approach to development using business objects, significant savings in the development, testing, and maintenance phases would be achieved. This is due to the high level of re-use that business objects encourage.
Having said this, when a powerful tool is put into the hands of an inexperienced person, chaos can (and usually does) ensue. If object-oriented design principals are not adhered to, then the resulting code has poor reusability and maintainability. Although an in-depth discussion of design issues is beyond the scope of this article, I will introduce in the following section one of the more fundamental design aspects of BOR programming: Responsibility.
When you are given the task of creating a method or attribute on an object, one of the most important questions you should ask is, Does this attribute or method belong on this object? This question is fundamental to an object-oriented design and the answer can make a world of difference. Answering this question incorrectly has detrimental effects on the development effort resulting in methods and attributes strewn across myriad objects, with no coherent structure. If the methods and attributes were strewn across several objects, it would be more difficult to provide a uniform interface to external systems. If an external system wants to execute a particular business process in R/3, it may need to access several business objects, thus increasing coupling and reducing the layer of abstraction between R/3 and the external system.
Lets take, for example, the requirement to be able to update a sales order. This is a common requirement and one that SAP usually implements for you. For the sake of the example, lets assume that SAP has not implemented this method. You will need to implement your own UPDATE method on one of the business objects. The question here is: Which object? This question is what I term as defining responsibility. Which object is responsible for having the UPDATE method on it? As shown in Figure 4, the answer in this cases is BUS2032 (SalesOrder). If you put it on any other object then you run the risk of no one else knowing of its existence. Next time there is a requirement to update a sales order, the developer will develop an additional method. You would then have two separate pieces of code that implement the same functionality. This duplication doubles development, testing, and maintenance requirements. On large projects, this can become a real problem and a maintenance and testing nightmare.
SAP recognizes the challenges facing developers in the e-business era. It is aware that if it wants to take R/3 to the next phase, it needs to continue evolving the ABAP language and ensure that powerful development tools are available to SAP developers.
Rising to the challenge, SAP has begun developing extensions to the ABAP language called ABAP objects (see "Introducing ABAP Objects," in the IntelligentERP feature archive for an excellent introductory article to ABAP objects by Jürgen Heymann and Horst Keller). These extensions will provide ABAP developers with a full range of object-oriented tools. Eventually, these new extensions will make BOR obsolete. However, the use of object-oriented development is sure to be an integral part of future SAP developments, regardless of where the world of e takes us.
BOR
