You’ve surely already heard about the new ABAP programming model for building state-of-the-art, intrinsically SAP HANA-optimized Fiori apps in SAP S/4HANA and maybe even played around with it, but you are still be on SAP Business Suite – optimally on SAP HANA. This is the situation for the vast majority of SAP’s customers and partners right now in 2017, but sooner or later they will get in touch with the Digital Core, that is SAP S/4HANA! As a developer or development manager, the questions at this stage are surely about how to best prepare yourself, your team and the new custom application developments for this new world – as this is just a matter of time until you get in touch with the digital core that is SAP S/4HANA. Introduction The new ABAP programming model has been introduced with the ABAP release 7.50 SPS01, first only supporting the development of read-only Fiori apps, and then successively enhanced and improved with the following ABAP releases. The new ABAP programming model is based on proven technologies such as Core Data Services (CDS) for the data modelling and access, OData protocol for the service exposure and the business object processing framework for the transactional processing. The picture below gives an overview of the end-2-end stack: Figure: ABAP Programming Model for SAP Fiori – Big Picture Here are the major deliveries up to date – i.e. until SAP NetWeaver AS ABAP 7.52: AS ABAP 7.50 SPS01 Read-only SAP Fiori apps Starting with this release, the development of read-only SAP Fiori (Elements) apps thru easy OData exposure of CDS-based data models. Such data model can be enrich with domain-specific annotations – e.g. Analytics, search, SAP Gateway and more. AS ABAP 7.50 SPS05 “Batch-input”-like SAP Fiori apps Starting with this release, simple transactional SAP Fiori apps can be built using the CDS-BOPF integration where the CDS-based BOPF framework handles for the transactional processing. AS ABAP 7.51 SPS02 Interactive SAP Fiori apps with draft handling Starting with this release, you can build more complex transactional SAP Fiori apps using the CDS-based BOPF framework for the transactional and draft handling. Different development guides are available on the SAP Help Portal to help you getting started with the development of the different application types. With AS ABAP 7.52, various enhancements and improvements for the different application types – incl. supportability and access control enhancements. But note that the programming model is still evolving and further major deliveries are on their way. Hence it is for important for you to understand where to invest now in order to make yourself ready for the “new world”. Recommendations You may have already seen the slide below somewhere – e.g. at SAP TechEd 2017 session S4H140 The slide above provides a list of recommendations meant to guide you for a best preparation for the future. They are meant for application developments where the new ABAP programming model cannot be used. The reasons for that may be that you’re not yet on SAP S/4HANA or your application requirements cannot be fulfilled with the current function scope of the new programming model – e.g. the use of legacy write APIs. Let me restructure the different recommendations a bit and briefly elaborate on them. YOU SHOULD Follow the programming model and best practices and use… ◈ ABAP Core Data Services (CDS) ABAP CDS provides a powerful data modelling infrastructure enabling advanced view building in the ABAP stack. It is the “Go To” infrastructure for view building in ABAP and plays a central role in SAP S/4HANA – especially for the CDS-based virtual data model and the new ABAP programming model. Availability: ≥ AS ABAP 7.40 SPS 05 ◈ ABAP CDS Access Controls ABAP CDS has its own data control language (DCL) which provides a declarative approach for the access control on CDS entities. Such an authorization access is declared once for a given CDS view and automatically used every time the view is consumed – everywhere. Availability: ≥ AS ABAP 7.50 SPS10 ◈ ABAP CDS Metadata Extension (MDE) CDS MDE are used to enrich CDS-based data models with UI-specific semantics which are UI technology agnostic, i.e. @UI annotation. It offers a separation of matters by separating UI metadata from the back-end relevant metadata. Availability: ≥ AS ABAP 7.51 SPS 02 ◈ Classic Business Object Processing Framework (BOPF) If you’re working on ABAP releases ≤ 7.50, the classic BOPF in transaction BOBX or in the eclipse-based BOPF modelling editor will allow you to modularize your custom business object logic similarly to what is done within the new ABAP programming model using determinations, validations and actions. Note that a lightweight, CDS-based BOPF is used within the new ABAP programming model where the BOPF business objects are automatically generated out of the given CDS-based data models. BOPF concepts like actions, determinations, validations and authorization checks are still valid. Availability: ≥ SAP ERP 6.0 EHP5 (SAP_BS_FND 7.02) ◈ SAP Gateway integration of CDS or BOPF Regarding the code-based implementation of OData service in transaction SEGW, we strongly recommend the use of the mapped data source option in ABAP 7.40 and referenced data source option as of ABAP 7.50, together with CDS entities. For these service implementation options, the SAP Gateway runtime offers generically the read-only OData calls including goodies like sorting, filtering and text search for CDS views out of the box. The reference data source (RDS) option is the option used within the new ABAP Programming models and is also the valid approach for the use of legacy write APIs – like BAdIs/Function modules – when building new SAP Fiori apps since this scenario is not yet supported by the new ABAP programming model. Whenever possible make use of the OData Exposure option which is available as of release 7.50 SP01. Availability: ≥ AS ABAP 7.40 ◈ Floorplan Manager (FPM) Integration of CDS or BOPF In case you have to build new Web Dynpro ABAP-based applications, then use CDS and the FPM SADL integration or the FPM BOPF Integration. Availability of FPM SADL Integration: ≥ AS ABAP 7.40 Availability of FPM BOPF Integration: ≥ SAP EHP 5 for SAP ERP 6.0 (SAP_BS_FND 7.02) DO NOT Implement things that are already solved: ◈Manual implementation of read-only OData calls to Database Instead of implementing yourself the read-only OData calls again and again when building SAP Gateway service in transaction SEGW, use the mapped data source or -better- the referenced data source option instead. The advantages of these two options are already explained in the DO’s section. ◈ Business logic mixed with technical aspects (e.g. locks, authority-check, LUW handling, persistency) This is nothing new, but just the re-emphasizing of a general good development style which is to encapsulate the different business logic paths of a given applications and decouple them from surrounding technical aspects such as locks, authority checks, LUW handling and persistency. For example, BOPF offers dedicated exits for authority checks. By doing this, you’re able to easily reuse your custom business logic at different places with less effort – i.e. in different scenarios/applications. ◈Business logic mixed with protocol specific APIs (e.g. PBO/PAI modules) Similarly to the previous recommendation, when manually implementing your SAP Gateway services in transaction SEGW, do not put your custom business logic directly in the predefined SAP Gateway exits classes (ending with DPC_EXT), but instead decouple it, so it can be reused easily somewhere else. BENEFITS Reuse / Prepare your skillset and custom coding for the future – i.e. SAP S/4HANA ◈Reuse CDS-based data models and access controls in SAP S/4HANA CDS is a cornerstone technology in the Digital Core and offers the basis for the ready-to-use, semantically enriched, CDS-based virtual data model (VDM) on top of which the applications are built in SAP S/4HANA. Thus starting working with CDS – both, the data definition language (DDL) and data control language (DCL) – as soon as possible will be of advantage for you in the “new world”. ◈Easy reuse of modularized and decoupled custom business logic for implementing business object behaviours in different applications and scenarios. ◈Lower TCD for the future: Minimal investment on technical protocol level The RESTful ABAP Programming model will be supporting the OData V4 protocol and applications currently built with OData V2 will be automatically switched to the OData V4 under the hood. Outlook The new ABAP programming model can already be used today to build for building SAP HANA-optimized Fiori apps, but it is still evolving. Thus do expect new deliveries to come with the future ABAP platform releases in order to optimize the total cost of development (TCD) with the goal of providing a RESTful programming model. The main investment areas of the future development are: ◈ Enhancement of the ABAP Language to provide a native support of the business object concepts (BO as first-class ABAP citizens) ◈ Support of typed APIs for default business object implementation tasks ◈ Avoidance of code generation ◈ Support the integration of legacy write APIs ◈ End-to-end OData V4 support ◈ Optimization of the end-to-end development flow ◈ Improvement of testability and supportability ◈ Enablement for the definition of UI semantics in the SAP Web IDE