From our data model of Airline which we have created, there are three Composite Interface views. It is always good practice to add semantic business object annotations to the composite interface views. Because Basic Interface views has to be reused in other applications as well, so we apply business object annotations on Composite interface views. To generate a BOPF business object based on the three composite CDS views, we must add several @ObjectModel annotations to the views.
In the Airline root view (ZAPF_I_AIRLINE), we must add the annotations on the header level.
define view ZAPF_I_AIRLINE
Below is the list of BOPF Business Object annotations.
|#||BOPF BO Annotations||Purpose/Relevance|
|1.||@ObjectModel.modelCategory: #BUSINESS_OBJECT||Indicates that the CDS view represents a BOPF business object.|
|2.||@ObjectModel.compositionRoot: true||A business object is represented as a hierarchical tree of nodes, and by adding this annotation, a view is characterized as the root view of the node hierarchy.|
|3.||@ObjectModel.writeActivePersistence: ‘SCARR’||This annotation specifies where created or updated data must be stored or deleted from.|
|4.||@ObjectModel.transactionalProcessingEnabled: true||To enable the transactional run-time for the view, this annotation is used. This annotation can only be added to Root view of BOPF hierarchy. Also, this annotation has to be added along with @ObjectModel.writeActivePersistence: ‘SCARR’.|
@ObjectModel.deleteEnabled: true, and @ObjectModel.updateEnabled: true
|With these annotations, we specify which operations will be supported by the transactional runtime. When we set everything to true, then all operations are supported by our Airline root node.|
|To build up the business object node hierarchy, we must also annotate the association to Flight Info. and Flight schedule views as a child association.|
|Views that don’t represent the root node of the hierarchy must also specify their root node association, which, in our case, is equivalent to the parent association.|
Lets apply the above BOPF BO annotations in our Airline model.
On activation of the transactional or business object views, the BOPF runtime will generate a business object together with several structures and table types based on the CDS view field structures. The generated BOPF object has the same name as the
root CDS view, in our case, ZAPF_I_AIRLINE.
To enable our existing consumption views for transactional processing via the generated BOPF business object, we must add some of the @ObjectModel annotations on the header level. To the Airline Consumption view (ZAPF_C_AIRLINE), we must add the annotations given as below