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 unoﬃcially as XS or XS Engine).
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-speciﬁc 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 ﬂow logic are located so close to the database.
Applications designed speciﬁcally 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 signiﬁcantly 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
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 speciﬁcally 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 ﬁles 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 oﬄine. 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 conﬂicts, and developers can access a merge tool to integrate the conﬂicts 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.