You’ve surely already heard about the ABAP programming model for building state-of-the-art, intrinsically SAP HANA-optimized Fiori apps in SAP S/4HANA [If not, then get started here] and maybe even played around with it, but you are still 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.
The ABAP programming model for SAP Fiori 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 ABAP programming model for SAP Fiori 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 enriched 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 (incl. locks).
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 have been delivered. But note that the programming model is still evolving and further major deliveries are on their way. Read more on this in the Outlook section of this blog.
Hence it is important for you to understand where to invest now in order to make yourself ready for the “new world”.
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 ABAP programming model for SAP Fiori 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 ABAP programming model – e.g. the use of legacy write APIs.
Let me restructure the different recommendations a bit and briefly elaborate on them.
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 ABAP programming model for SAP Fiori.
ABAP CDS Access Controls
ABAP CDS Metadata Extension (MDE)
It offers a separation of matters by separating UI metadata from the back-end relevant metadata.
Classic Business Object Processing Framework (BOPF)
Note that a lightweight, CDS-based BOPF is used within the ABAP programming model for SAP Fiori 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.
SAP Gateway integration of CDS or BOPF
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 ABAP Programming model for SAP Fiori 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 ABAP programming model. This option is also to be used for cross BO scenarios.
Whenever possible make use of the SEGW RDS together with CDS.
Floorplan Manager (FPM) Integration of CDS or BOPF
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
Business logic mixed with protocol specific APIs
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 extensions classes (ending with DPC_EXT), but instead decouple it, so it can be reused easily somewhere else.
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. [Read more in this blog about VDM] 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
Lower TCD for the future: Minimal investment on technical protocol level
The ABAP programming model can already be used today to build 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 the ABAP 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
For more road map details, check out the recording of session S4H140 at SAP TechEd 2017.
You may also be interested in general recommendations about what you can do today to prepare your custom ABAP code for SAP S/4HANA. Find this information here.