Exploring ABAP Cloud

Throughout the course so far, we have repeatedly mentioned that it has become of paramount importance that companies need flexible applications that can be adapted easily, based on changing customer demands. SAP S/4HANA Cloud is the product that answers this need and clean core extensibility is the principle that enables this flexibility. In the previous lesson, we saw that cloud computing has taken on a central role in becoming a platform for application development and operations. In that lesson, we also saw how cloud computing has led to the evolution of a different approach to application development and maintenance, namely, cloud native. Lastly, in that lesson, we saw that one particular aspect of cloud native, REST APIs, are central to its success.

The emergence of cloud computing, cloud native, and REST, along with the clean core extensibility principle, has necessitated an evolution of the ABAP language and ABAP development models that developers have used over the years. Luckily, ABAP has the ability to evolve based on changing technology and needs. In ABAP's earliest days as a fourth-generation programming language (in the 1980s), it was primarily used to do reports on the SAP R/2 platform. With the emergence of SAP R/3 (in the 1990s), the language was enhanced so that both SAP and customers could use it to create programs and extensions. With service packs to enhancement packs to release upgrades, the ABAP language has continuously evolved to meet the needs of the moment. While admittedly the shift to cloud computing was a fundamental change, nevertheless, SAP's strategy for ABAP is centered around "evolution not revolution", meaning that changes made to ABAP to adapt it to cloud computing were precise, controlled, well thought out and incremental. Most importantly, customer needs were always paramount.

On that point, before looking at changes to ABAP necessitated by cloud computing, it's worth taking a moment to look at a previous situation where ABAP had to evolve based on a paradigm shift. That would be the emergence of object-oriented concepts that reached mainstream usage in the 1990s. Up until that time, the ABAP language was procedural in nature. Once the need for ABAP to support object-oriented concepts became apparent, several keywords were added to the language to allow developers to implement these concepts. These keywords were carefully constructed to evolve the ABAP language while at the same time recognizing and respecting the existing ABAP code in customers systems so that customer disruption was minimized. As a result, an ABAP developer could write both procedural and object-oriented code and had the flexibility to decide the proper balance between the two in any given task. So if, for example, a company set a goal to have 90% of all their ABAP custom code object oriented by a certain date, this could be accomplished at a pace of their choosing as opposed to it being imposed upon them in a "top down" manner. This last point is important. ABAP has always evolved in such a way that it is generally "backwards compatible". This means that changes are usually forward looking only. Existing code does not necessarily need to be adjusted to comply with any new ABAP standards or features. Developers simply use the new features going forward in their project developments.

The emergence and widespread usage of cloud computing, cloud native, and REST have resulted in another need for ABAP to evolve. This need has manifested itself in the ABAP Cloud development model (ABAP Cloud). The various aspects and building blocks of ABAP Cloud has everything that an ABAP developer needs for a cloud-native world. The main features of the ABAP Cloud are as follows:

• A cloud native language: ABAP for Cloud Development – an ABAP language version optimized for the cloud
• Cloud native programming models: The ABAP RESTful application programming model and ABAP analytics
• Platform as a Service (PaaS) features as part of the ABAP platform: Reuse services, identity and access management, and connectivity
• Integrated SAP S/4HANA Cloud features: Business APIs, extension points, and events
• Tools: ABAP development tools for Eclipse as the integrated development environment

At the core of the ABAP Cloud development model is its programming model, which defines the design-time and runtime architecture of all extensions, services, and applications. When talking about the programming model, we generally consider the following three different use cases or scenarios:

• Transactional (OLTP): With ABAP Cloud, you can build business objects and expose them as services, to consume them in UIs and integration scenarios. All standard behavior is supported (create, read, update, delete). Think of the well-known Sales Order business object as an example. These features are achieved by using the ABAP RESTful application programming model.
• Analytical (OLAP): ABAP Cloud is equally equipped for creating services and UIs for data analysis, for drilling down in multiple dimensions, and so on. A prime use case would be integrating the data in SAP Analytics Cloud. This functionality is made possible by using ABAP analytics.
• Integration: Both previous aspects are complemented by strong data and application integration to cater to today's service-oriented environments.

The programming model does not stand on its own – it is accompanied by the following two key differentiators:

• Re-use services and libraries with core business services like number ranges, application jobs, an ABAP-integrated SAP Fiori launchpad and UI repository to deploy SAPUI5 and SAP Fiori elements UIs.
• Built-in qualities offering end-to-end extensibility in the programming model, major cloud qualities like scalability and upgrade stability, and many more.

ABAP Cloud is the result of a number of innovations over the past decade. ABAP development tools for Eclipse was introduced in 2012, giving developers an additional environment to build, debug, test, and run their ABAP code. Shortly thereafter, Core Data Services was introduced, giving developers a declarative way to create data models to be used in building applications optimized for SAP HANA. REST, having emerged as a widely used architectural style, which, as we explored in the previous unit, has led to the development of the ABAP RESTful application programming model, which allows ABAP developers to efficiently create end-to-end ABAP-based REST services for developing transactional SAP Fiori apps and Web APIs.

Each of these innovations individually are worth a lot. But, as it is often said, "The whole is greater than the sum of its parts". The same is true here. ABAP Cloud not only brings all of these innovations together but also adds several additional innovations combining all of them in a holistic manner. As a result, developers can now enjoy efficient end-to-end cloud native development using ABAP. ABAP Cloud can be used to develop custom applications and services, as well as to build extensions to SAP S/4HANA Cloud applications.

ABAP Cloud is available as the default (and only) option in both SAP BTP, ABAP environment and also SAP S/4HANA Cloud Public Edition. For both SAP S/4HANA Cloud Private Edition and also SAP S/4HANA, ABAP Cloud coexists along with ABAP Classic and customers can choose when to use which model, the specifics of which will be discussed in Unit 5, Evaluating Special Considerations for SAP S/4HANA Cloud Private Edition and SAP S/4HANA. Again, evolution not revolution.

Earlier in Unit 2, Lesson 2, Evaluating SAP Build, we explored the difference between the "citizen developer" (namely, a "builder") and the more traditional "developer", in terms of tool support. Builder's need tools that fall primarily into the "low code" category, whereas developers require a more "pro-code"-oriented toolset. ABAP Cloud is oriented towards the developer persona.

Due to its long and rich history, a wide number and variety of ABAP keywords, artifacts, and techniques exist to provide features that are necessary for the development of professional enterprise applications. However, not all of these are compatible with the needs of a cloud native approach, so only a subset of them are used in ABAP Cloud. For example, obsolete keywords like the TABLES statement are prohibited. Dynpros and Web Dynpros are likewise prohibited in lieu of SAP Fiori UIs based off of REST services created using the ABAP RESTful application programming model. SELECT statements directly on SAP tables are prohibited in lieu of using Core Data Services.

To make this difference clear, developers must now assign the language version to development objects when they are created. That language can be either "Standard ABAP" ("ABAP Classic"), "ABAP For Cloud Development" (for ABAP Cloud development) or "ABAP for Key Users" (also for ABAP Cloud development; to be discussed in the next unit). By making an explicit assignment, the appropriate checks can be performed to make sure that the development work is ABAP Cloud compliant.

Traditionally, developers used the ABAP Workbench to create the various artifacts needed for an application, as well as syntax checking and debugging them. As mentioned previously, in 2012 the Eclipse platform along with a special plugin, ABAP development tools for Eclipse was introduced as an alternative "pro-code" environment for ABAP development. ABAP Cloud development is done exclusively using ABAP development tools for Eclipse. ABAP development tools for Eclipse verifies ABAP Cloud compatibility via a combination of ABAP compiler, ABAP runtime, and ABAP test cockpit checks, as appropriate. These capabilities combined with already existing and familiar ABAP development tools for Eclipse features such as code completion, syntax checking, and debugging make the transition to ABAP Cloud development smooth and easy for developers. For more information on enabling a smooth migration from the ABAP Workbench to ABAP development tools for Eclipse, see the FAQs for SE80 Experts Using ADT.