Overview

SAP is known as a world leader for vendors of ERP applications and technology platform for large enterprises. However, when it comes to SAP's industry solutions which are tailor made for specific industries, a few people know that some of them are based on the ERP application but some are full blown independent solutions, made for a specific industry/market segment.

The SAP Banking Platform, also known as Banking Services from SAP, is one of those independent industry solutions providing a comprehensive answer for core banking activities (Deposit management, Loan Management and more).

 SAP embraced SOA as a fundamental design paradigm for the company's future products.  Positioning SAP as the first leading business application vendor seriously implements SOA solutions. The Banking Platform is one of the leading SOA designed solutions that one can find in the enterprise application segment.

A lot has been said about the SOA paradigm and concepts, but when really starting to implement a true SOA based solution, one is required to deal with some fundamental terms and to understand these terms in a pragmatic manner as well as a conceptual one. Business Object is one of these familiarly dealt with terms a term that is often misunderstood

In this Blog I aim to take you through the meaning and usage reflections of business object within the SAP Banking platform

The "Terminology syndrome"

When one works in an information system development projects, he finds himself having long discussions on different technologies, business aspects and architectural approaches.

Discussions such as these often raise many questions from various people coming from different areas and backgrounds. The real problems surprisingly arises when dealing with topics where initially there seems to be a clear understanding, because all believe that the term is familiar to them. This is what I shell call the "Terminology syndrome". It seems that only once you dig deep and ask people what their understanding of the term really is; you discover that each person attributes different meanings/understanding to that specific term.

 

I believe that when talking about Business Object we might come across the "Terminology syndrome". Depending on where you come from, whether you are a SAP consultant, an ABAP developer, a java developer or a DBA, you probably expect different things from the SAP business Object.

Here are some generic definitions of Business Object I found on the internet:

"Business objects are objects in an object-oriented computer program that represent the entities in the business domain that the program is designed to support. For example, an order entry program might have business objects to represent each orders, line items, and invoices. ...A business object often encapsulates all of the data and business behavior associated with the entity that it represents"Definition from wikipedia

"Business Object: A concept from the everyday business terminology and vocabulary of the end-users. Each Object corresponds to a selection of data in the relational database, or a calculation or function using this data. " http://planning.ucsc.edu/IRPS/dwh/BOBGLOSS.HTM

"business object is a code structure that corresponds directly to a thing in the actual business the software is meant to represent that encapsulates the data that describes, defines, makes up, is contained by, and or is associated with the thing, and encapsulates the business logic related to the thing." http://swcses.eponym.com/blog/_archives/2006/9/19/2341371.html

As you can see in these 3 examples, the basic definition of a business object is the same but the actual or physical being of the business objects is different. In some cases it is expected to be a programming language object in the memory with all the relevant data and methods related to the business objects, in other cases it is expected to be a unified database structure that contains all the relevant information of a specific BO. These different expectations of what a business object should be might reflect on our basic understanding of what and how we should work with a specific system/software, in our case - the SAP banking application.

SAP Banking definition of Business Object

We now understood that a business object is not a trivial/unified definition. Let us now see how business object are defined in SAP banking and how they reflect on the SAP software delivered to customers.

A business object is a set of entities with common characteristics and common behaviour representing well-defined business semantics. It is described by a structural model, a status and action model (describing the business object's lifecycle), and one or more service interfaces.

Contrary to general notion of an "object" in an object-oriented sense, the term business object is used here to describe the type and not the instance level. Consequently, the business object Bank Account describes the category of all Bank Accounts and not a single Bank Account instance. SAP banking application design is object-based, not object-oriented. It deals with the concepts of business objects, nodes and instances but does not represent these concepts in a one-to-one correspondence with object-oriented classes and instances.

The Business Object physical "being"

If that is the definition, what then is the physical being of a specific business object, if at all? Well, the business object within the banking platform application is not one unified object or table but is:

• The conceptual model that derived from the actual business processes. These conceptual terms are born during the service modeling phase when designing the business functionality required by the application. (e.g. Bank Account BO when designing the "bank account contract processing" process component and its functionality)
• The BO Attributes - the data types and information that a BO is built from. Some of these attributes can be used to represent lifecycle of a BO like "StatusCode" that can be filled with values such as "created, "in process", "valid", "closed" etc' as well as classifying attributes that can decide on the nature of the specific BO like "CurrencyCode" that can determined what kind of account it is in terms of currency (EURO, USD, etc).
• The BO persistence artifacts (Database) - obviously the BO data of a specific instance is at some point persisted into the DB, so there are tables that contains the BO specific data. But again, this structure is not always a 1:1 match to the  BO conceptual model (e.g. if you have Bank Account BO with specific structure in the model it does not mean you will have table called Bank Account with the same DB structure). In SAP this level is never exposed to the customers and it is not allowed to deal directly with the DB level to ensure consistency and supportability of the SAP applications.
• The BO related service operations - The most important physical artifacts derived from BO's are the enterprise services and operations. The main objective of modeling BO's is the identification and implementation of the right business functionality and to expose it as Enterprise Services meant to be used for composing business processes. So each BO has 1 or more enterprise services that represent business operations one can do on the BO or with the BO (e.g. for Bank Account BO you have the Read Bank Account Current Balance Report service operation that enables you to get the bank account current balance).
• The BO related backend code - behind each service operation there are several implementation classes starting with the ES proxy classes and other business implementation classes that are used by these service operations. This code is logically related to the BO's since it implements their related functionality, however it is not mapped to a physical 1 BO class in a 1:1 type of relationship as mentioned before. These classes can be used and enhanced according to SAP's standard guidelines.

Summary

A business object is a term that might confuse some due to the fact that it brings different thinking on its physical being and availability depending on one's personal background. From a customer implementing SAP banking platform perspective, the BO is important in order to get a better understanding of the way SAP views/clusters the business domain but is not a physical entity that directly interacts with. SAP's view as a standard software provider is to enable customers to implement its functionality using a set of a well defined API's (Enterprise Services, BAPI's, other) without having to get into all the internal structures of the software. According to this view the BO is a tricky one; on the one hand it is an object that is important for the business understanding of the software, on the other hand its physical implementation is too complicated and is related to internal software design. That is why SAP provides the high level information on which BO's were identified as part of specific business process component functionality and its related enterprise services and underlying operations, but does not provide information about the internal structure of each BO

All the information about BO and Enterprise Services can be found in the Enterprise Service Workplace.