Introducing SAP HANA Extended Application Services (XS)

With SAP  HANA  SP5*, SAP  has introduced an exciting new capability called SAP HANA Extended Application Services (sometimes referred to unofficially as XS or XS  Engine).

SAP HANA Extended Application Services

XS is a small-footprint application server, web server, and basis for an application development platform – that lives inside SAP HANA.  To be clear, XS is not a completely separate technology that happens to be installed on the same hardware server as SAP HANA; XS is actually an extension of, and tightly integrated into, the SAP HANA Database. The main idea of SAP HANA XS is to embed a full-featured application server, web server, and development environment within the SAP HANA appliance itself.

The core concept of  XS  Engine is to embed a full-featured application server, Web server, and development environment within the SAP HANA appliance itself. However, this technology isn’t just another piece of software installed on the same hardware as SAP HANA. Instead, SAP has decided to truly integrate this new application services functionality directly into the deepest parts of the SAP HANA database. This architecture will enhance the performance of the app and enable it to access SAP HANA differentiating features that no other application server has.

Before SAP HANA SP5 was introduced, if you wanted to build a lightweight Web page or REST Service that consumes SAP HANA data or logic, you would need another application server in your system landscape.

For example, you might use SAP NetWeaver ABAP or SAP NetWeaver Java to connect to your SAP HANA system via a network connection and use ADBC (ABAP Database Connectivity) or JDBC (Java Database Connectivity) to pass SQL statements to SAP HANA. Because of SAP HANA’s openness, you might also use NET or any number of other environments or languages that support Open Database Connectivity (ODBC) as well. These scenarios are all still perfectly valid. In particular, when you are extending an existing application with new SAP HANA functionality, these approaches are very appealing because you can integrate this SAP HANA functionality into your current architecture easily and with minimal disruption.

When you are building a new SAP HANA-specific application from scratch, however, it makes sense to consider the option of the SAP HANA Extended Application Services. This architecture enables you to build and deploy your application completely self-contained within SAP HANA. This approach can lower your costs of development and ownership while providing performance advantages because the application and control flow logic is located so close to the database.

Applications designed specifically to leverage the power of SAP HANA are frequently designed to push as much of the logic down into the database as possible. It makes sense to place all of your data-intensive logic into SQL, SQLScript Procedures, and SAP HANA Views, because these techniques will leverage SAP HANA’s in-memory, columnar table optimizations as well as massively parallel processing (MPP).

For the end-user experience, we are increasingly targeting HTML5 and mobile-based applications where the complete UI logic is executed on the client-side. Therefore, we need an application server in the middle that is significantly smaller than the traditional application server. This server needs to provide only some basic validation logic and service enablement. The reduced scope of the application server lends further credit to the approach of a lightweight embedded approach like that of the SAP HANA Extended Application Services.

Figure 6 — Paradigm Shift in Runtime Layers

SAP HANA Studio Becomes a Development Workbench

To support developers in creating applications and services directly within SAP HANA Extended Application Services, SAP has enhanced the SAP HANA STUDIO to include all of the necessary tools. The SAP HANA Studio was already based upon Eclipse; therefore, SAP was able to extend the Studio via an Eclipse Team Provider plug-in that sees the SAP HANA Repository as a remote source code repository similar to Git or Perforce. This arrangement empowers the SAP HANA Database to manage the entire lifecycle of all of the development resources (everything from SAP HANA Views, SQLScript Procedures, Roles, Server Side Logic, HTML and JavaScript content, etc.). These management capabilities include versioning, language translation export/import, and software delivery/transport.

SAP HANA Interview Questions for Freshers

The SAP HANA Studio is extended with a new perspective called SAP HANA Development. As Figure 7 illustrates, this new perspective combines existing tools (e.g., the Navigator view from the Modeler perspective) with standard Eclipse tools (e.g., the Project Explorer) and new tools specifically created for SAP HANA Extended Application Services development.

Because SAP HANA Studio is based on Eclipse, SAP can also integrate other Eclipse-based tools into it. For example, the SAP UI Development Toolkit for HTML5 (SAPUI5) is a standard feature in SAP HANA Extended Application Services. SAP HANA 1.0 SP5 comes preloaded with the 1.8 version of the SAPUI5 runtime, and the SAPUI5 development tools are integrated into SAP HANA Studio and managed by the SAP HANA Repository, like all other XS-based artifacts.

Figure 8 — SAP HANA Specific Project Wizards

These features also include team management functionality. All development work is performed based on standard Eclipse projects. The project files are then stored within the SAP HANA Repository along with all the other resources. Team members can utilize the SAP HANA Repository browser view to examine existing projects and import them directly into their local Eclipse workspace. Developers can then work on these projects offline. In addition, multiple developers can work on the same resources at the same time. Upon commit back to the SAP HANA Repository, the tool will detect any conflicts, and developers can access a merge tool to integrate the conflicts back into the Repository.

The SAP HANA Repository also supports the concept of active/inactive workspace objects. This feature allows developers to safely commit their work back to the server and store it there without immediately overwriting the current runtime version. The new runtime version isn’t created until the developer chooses to activate the Repository object.