RAP – RESTFULL ABAP PROGRAMMING:

SAP provides two type programming model for SAP FIORI.

RAP CAP
If inhouse expertise and ABAP run time environment If inhouse expertise in Node.JS then go for CAP
Then go for RAP

With CDS + BOPF lot of artifacts get created and that makes difficult to troubleshoot errors for transactional Fiori apps.
Instead BOPF with business definition it makes it more flexible and lot of errors can be caught during the runtime only with
RAP making the code easier and long lasting for future.

Evolution of ABAP programming model for SAP FIORI:

Youtube: https://www.youtube.com/watch?v=i-
HI6AQZ2WE&list=PLKSPsENL3CxzRehaCAyH_K0yHM8KwLrDz&index=1

RAP Steps:
1. Create table < ZRAP_UXTEAM_5551>
 2. Create an interface view that reads it from this table < Root view: ZI_UXTEAM_5551>
3. Create a consumption view that reads it from this interface view < Root view entity ZC_UXTEAM_5551>
4. Create a metadata extension file : Pkg-> Metadata ext-> < ZC_UXTEAM_5551>
 Metadata can also included in consumption view but it makes very hard to read code. Hence
recommended write separate file. If consumption has metadata extension already then right click -
>source code -> extract metadata and keep it in separate file.
5. Define entities for business object
 Consist of hierarchical nodes which are linked by special kind of association ‘composition’. Root entity
serves as representation of business object which is defined in CDS data definition with key word
ROOT. Basic business object is service agnostic meaning it does not care whether you are going to
OData V2 or V4 service.
 For example, sales order header is root entity then items, schedule lines can be other nodes but root node
sales order is ROOT and they linked by composition.
 We already marked in step 2 which is our ROOT entity i.e business object. And this step is complete.
6. Define behaviour definitions : Right Click on Interface view -> Def. Beh, Definition- .Def- <By Business
Definition language [BDL - ] ZI_UXTEAM_5551> Imp Class: ZBP_I_UXTEAM_5551
 CREATE, UPDATE, DELETE Operations comes free and these are MANAGED SCENARIO’S.
 Validation during CREATE – Age should be greater than 21
 Actions – Active flag is set to true after series of checks are complete
 Determination – when role is changed
 Feature control – Salary is marked as READ only
 One Interface view will have only one Beh. Definition. 1:1 mapping strictly.
7. Implement behaviour definition – By Entity Manipulation Language [EML] - Class: ZBP_I_UXTEAM_5551
implemented
 MODIFY : READ : COMMIT ENTITY statement can be used within EML
8. Define Behaviour projections –Right Click on - Consumption view ZC_UXTEAM_551 – New bev. Definition
 Project all behaviour except DELETE
9. Define service definition -> Core Data services-> New service definition-> Z_EXPOSE_USTEAM_5551
 Expose Consumption view ZC_UXTEAM_5551. We have one only, if multiple you can expose
10. Define service binding -> Business service-> Service binding -> ZUI_UXTEAM_5551-_V2
Select anyone Binding types:
 OData V2 UI + Odata with Web API
 OData V4 UI + Odata V4 with Web API
 InA – UI
Select Service definition = Z_EXPOSE_USTEAM_5551 and publish and preview your ENTITY i.e UXTeam
11. Optionally – add draft handling feature

TESTING - PREVIEW

EML – Entity Manipulation Language:

Below three are the EML and they can be directly consumed within ABAP.
MODIFY Entity:

MODIFY will have CREATE; UPDTAE: DELETE

 FAILED : Error will be in this structure
 MAPPED: Will have result
 REPORTED: Will have additional information
READ Entity:

Failed is not empty means READ is failed.

COMMIT Entity:

Check sy-subrc