Varad
SAP Fiori – 8 ABAP Programming Model – Creating Transactional Applications – CRUD Operations with BOPF There are three Composite Interface views derived from our airline data model that we developed. Annotating the composite interface views with semantic business objects is always a smart idea.
The introduction of business object annotations to Composite interface views is necessary since Basic Interface views must also be reused in other applications. We need to add multiple @ObjectModel annotations to the three composite CDS views in order to construct a BOPF business object based on those views.
We need to add the header level annotations in the Airline root view (ZAPF_I_AIRLINE).
Model @ObjectModel.model@ObjectModel.composition Category:#BUSINESS_OBJECTRoot:actual
@ObjectModel.transactionalProcessingAllowed:actual
The object model writes “SCARR” in the ActivePersistence field.Activated: Yes
@ObjectModel.removeActivated: Yes
@ObjectModel.updateActivated: Yes
describe view ZAPF_I_AIRLINE… {…. }
The list of annotations for BOPF Business Objects is shown below.
| # | 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’. |
| 5. | @ObjectModel.createEnabled: true, @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. |
| 6. | /* Associations*/ @ObjectModel.association.type:#TO_COMPOSITION_CHILD _Flight, @ObjectModel.association.type:#TO_COMPOSITION_CHILD _Fsched | 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. |
| 7. | /* Associations*/ @ObjectModel.association.type: [#TO_COMPOSITION_PARENT,#TO_COMPOSITION_ ROOT] _Airline | 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. |
Let’s add the BOPF BO annotations mentioned above to 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
...
@ObjectModel.transactionalProcessingDelegated:true
@ObjectModel.compositionRoot:true
@ObjectModel.createEnabled:true
@ObjectModel.updateEnabled:true
@ObjectModel.deleteEnabled:true
...
define view ZAPF_C_AIRLINE
...
{
...
}We should mark the view as the root view of our hierarchy node structure by introducing @ObjectModel.compositionRoot: true. Additionally, we must enable all transactional operations separately because they are already known from the Interface views. The only new annotation is the @ObjectModel.transactionalProcessingDelegated: true, which indicates that transactional processing is delegated to the transactional runtime of the underlying view. In our case, ZAPF_I_AIRLINE is the business object and view. Moreover, we must also specify the same association type annotations as in the underlying views, from Airline to Flights Info. and vice-versa.
Additionally, we have to add annotations to Flights Info. Consumption view (ZAPF_C_FLIGHTS) and Flight Schedule Consumption view(ZAPF_C_FLI_SCHED), to enable transactional processing delegation.
...
@ObjectModel.transactionalProcessingDelegated:true
@ObjectModel.createEnabled:true
@ObjectModel.updateEnabled:true
@ObjectModel.deleteEnabled:true
...
define view ZAPF_C_FLIGHTS
...
{
...
}
Once all the BOPF BO annotations are added, our Fiori App will look like below.
Let’s insert data with below details in all three views.
| View | Data |
| Airline | Airline code = SQ; Airline Name = Phillipines Airlines Currency Code = SG; URL = – |
| Flights Info. | Airline Code = SQ; Connection No = 0158; Flight Date = 22.03.2020; Airfare = 4000 SGD; Currency = SGD; Max capacity = 300; Occupied seats = 201; Booking Total = 804000 SGD |
| Flight Schedule | Airline Code = SQ; Connection No = 0158; Country From = SG; Departure city = Singapore; Country To = ID; Arrival City = Jakarta |
The results of the save procedure are shown below.
We had no trouble saving entities into the appropriate table thanks to BOPF’s assistance. Let’s go into more detail about the other functions that BOPF offers in the upcoming chapters.
you may be interested in this blog here:-
Safeguarding Your Salesforce Journey: A Comprehensive Guide to Backup and Recovery
