Basic Development Concepts

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Describe the application development environments used by SAP HANA Cloud

Choosing an Environment on Business Technology Platform

One of the most important decisions that needs to be made when planning a new application is : Which BTP environment should you choose?

Each environment comes equipped with different tools, technologies, and runtimes that to build applications. SAP BTP is available on different environments to allow for greater flexibility in the development process. Customers can even mix environments. SAP BTP enables the development and running of applications across multiple environments.

Introducing Cloud Foundry

SAP BTP, Cloud Foundry environment is an open Platform-as-a-Service (PaaS) targeted at microservice application development and deployment.

The microservice architecture enables developers to create applications in very small pieces that each provides an individual 'service'. Each service can be integrated with other services to provide a complete application. This support agile development and maintenance.

One of the key strengths of Cloud Foundry environment is the ability to create applications using multiple development languages. Traditionally, application were developed using only one general-purpose language even if that language was not optimal for the function being developed. Now we can choose the optimal language for each piece of the application.

Cloud Foundry makes it faster and easier to build, test, deploy, and scale applications, providing a choice of the underlying infrastructure (including Kubernetes), developer frameworks, and application services.

Cloud Foundry allows your organization to focus on developing and running the applications, and not the platform.

It removes the cost and complexity associated with configuring, managing, and securing infrastructure for your applications.

Cloud Foundry has significant benefits to developers and organizations including:

  • Language independent

    choose any runtime language, and add new languages as needed

  • Administration separation

    administrators and developers can work in parallel

  • Standard Command Line Interface (CLI)

    the same CLI is used by all Cloud Foundry providers, not just SAP so administrators do not have to learn multiple tools

  • Open Source

    continual contributions by many organizations, updates and new features arrive faster 

Introducing SAP Cloud Application Programming Model (CAP)

SAP Cloud Application Programming Model, also referred to as SAP CAP, is a framework of tools, languages, libraries and APIs that combine open-source and SAP provided tools and technologies.

A very important aspect of SAP CAP is that it provides SAP best practices to help developers reduce their coding efforts. SAP CAP provides re-useable code to handle common application features. The idea behind CAP is that it encourages developers to focus on the added value part of the application (the domain) and not on the low value recurring, technical features of an application that can easily be provided by the model and that could change across different environments. This means that the highest value parts of applications are safeguarded in a world of fast changing cloud technologies.

SAP CAP is used for new application developments and also to extend existing SAP applications.

CAP is used to develop applications that are deployed to the SAP BTP, Cloud Foundry environment.

The backbone of CAP is Core Data Services (CDS)

CDS is used to define the core data layer. CDS is a semantically rich data definition language. CDS is used to define the physical data layer (e.g. data types, tables) and also to the virtual data layer (e.g. views)

CDS also includes an advanced querying language called Core Query Language (CQL). It enhances standard SQL with elements to easily query deeply nested object graphs and document structures.

A key concept within CAP is that everything is a service. Services expose a consistent set of APIs that can be consumed by all other services and front ends. Services are defined in CDS and define what should happen and when and to what data.

Everything in CAP happens in response to events. Applications built using CAP can transmit events which can be picked up by other services or front-ends using subscriptions. Application can also receive incoming requests and trigger services. Events are managed using event handlers. The CAP models provides generic handlers for common tasks (e.g. CRUD operations, validations) and these generic handlers take care of most of the tasks and use cases. You can also develop custom logic to extend the generic handlers using Java or Node.js.

With CAP you can also create native HANA Cloud database artifacts such as tables, views and functions and mix them with CDS artifacts.

CAP guides developers on a path that follows SAP best practices for developing cloud applications on the Cloud Foundry environment.

With the CAP approach, SAP recommends extensive use of CDS to define models and services so that you are working at the abstraction layer and not developing technical objects directly. This means, as underlying technologies change, your development is able to adapt.

But CDS cannot handle custom logic. For example a complex validation for a combination of additional input fields that are not part of a standard data model. That is when Java and Node.js are used to provide the custom logic.

The recommended tool for developing CAP applications is Business Application Studio because is provides SAP plug-ins and features that are aligned with the CAP approach.

Hierarchical Structure of Cloud Foundry Applications

Applications run within a fixed two level hierarchical structure made of Organizations and Spaces.

Service Plans

When you provision an SAP HANA Cloud database, you choose a service plan to manage the database artifacts.

SAP HANA Cloud provides a choice of two service plans for managing database artifacts:

  • Schema service plan — Create all database artifacts directly to schemas using SQL. This run-time only option is the approach that has been used for many years with traditional databases and appeals to organizations that only need a database to power their applications and do not require design-time tooling to define the database artifacts as source files. You will manually define schemas to manage your database run-time objects.
  • HANA Deployment Infrastructure (HDI) Shared service plan — Provides a combined database design-time and run-time environment. Database developers, using this plan, define all database objects using source files. The source files are used to generate and deploy the run-time object to the containers. This plan provides tools for the full life-cycle development and deployment of database artifacts. With this plan you don't have to worry about schemas as these are invisible to the developer and managed by the HDI framework. This is known as schema-less development and provides a flexible re-deployment model as database artifacts are not hardwired to schemas.

A service plan will only be available to you if it was already added as a service entitlement which is done at the Business Technology Platform (BTP) global account level.

A service plan is chosen when you create a new Instance. An Instance belongs to a Space

You are not limited to one service plan and you can choose multiple service plans.

Note
HDI should not be confused with XS Advanced. XS Advanced is a run-time that is not used by SAP HANA Cloud as it is not needed. SAP HANA Cloud uses Cloud Foundry and this provides similar application runtime concepts as provided by XS Advanced but is based on open standards that support multi-cloud developments.

Save progress to your learning plan by logging in or creating an account

Login or Register