The Presentation layer and the business logic (Business Layer) are separated in layers so that any user interface (UI) can request data from the business layer. The presentation layer is based on BSP and the business layer is based on two virtual machines which can interpret JAVA and ABAP code at runtime.
The following figure illustrates the relationship of Presentation Layer and Business Layer in IC web client.
The Business Layer is divided into two Sub layers: Business Object Layer (BOL) and Generic Interaction Layer (GENIL). The BOL offers a certain set of objects. There are two main types of objects in the BOL: business objects (entities) and query services. You can use query services to search for specific business objects within the BOL. There are BOL objects for business partner, one order, product master, marketing campaigns, call lists and so on. Each of these BOL objects appears in a tree structure with exactly one root node. The actual attributes of the BOL objects form the leaves of the tree. You can find an overview of the available query services and BOL objects in the BOL browser.
As can be seen from above figure the BOL model consists of business objects and relations between them. The business objects are subdivided into 6 kinds:
Depending on the object kind several actions for an object are allowed or prohibited. For instance, transactional behavior is only supported on root objects, direct read access only for root and access objects, and so on. The model of a component will always start with a root object (in case of a read-only component an access object may also make sense). This root object is then related to one or more, in general, dependent objects. If the related objects are directly accessible (fully key) they might be defined as access objects. Of course the objects of a component can also have relations to root objects of other components.
RelationsWe also distinguish 3 kinds of relations:
The allowed kind of a relation depends also on the related objects. For instance, the relation between a root object and a dependant object must be an aggregation or composition, but the relation between to root objects can only be an association. In addition to the relation kind also the cardinalities of the source and the target object are part of the definition. These are mainly used to distinguish between 1:1 and 1:n relation. All relation is treated as unidirectional with a well defined source object (parent) and target object (child).
The presentation layer and the business layer are linked together, as BOL objects are bound to attributes by context nodes of BSP view controllers. To fill the BOL object, the GENIL accesses its particular data through Application Programming Interfaces (APIs). In this layer, access to different APIs is already implemented, so the BOL gets clearly defined access to the defined structures. The BOL Browser (Transaction GENIL_BOL_BROWSER) can be used to test the query services and BOL objects.
A component of the generic interaction layer is represented as a global ABAP class, which inherits from the abstract base class CL_CRM_GENIL_ABSTR_COMPONENT. From its base class it inherits two interfaces, one for the model retrieval, and one for the interaction with the generic IL core. The base class provides a default implementation for each of the interface methods (in most case an empty implementation). This means only the needed methods must be implemented/redefined.
In my next blog I would outline the steps required to create a BOL Model with an example and also how to create GENIL classes.