What we've covered

Well, I think we're about done.

Our journey over the last three hundred pages (or thereabouts) has taken us through most of the development options in SAP HANA.

This book was split up into four main parts:

• Chapters 1 and 2: Introduction and installation

• Chapters 3, 4, 5, and 6: Database development in SAP HANA

• Chapters 7, 8, 9, and 10: Ancillary functions useful to most developments

• Chapter 11: The XS Engine for website development

Let's take a quick moment to see what we learned together.

In Chapter 1, So, What Is This SAP HANA Thing Anyways?, we looked at the architecture of SAP HANA. We saw that it is a massively parallel, in-memory database which uses column-based storage and data compression. We noted that SAP only sells SAP HANA as an appliance, meaning a software/hardware bundle, helping to guarantee performance levels since the software is running on certified hardware combinations.

We did a couple of tests on a large dataset (140 million lines), comparing performance of SAP HANA and MySQL using simple SQL statements. Rather unsurprisingly, we saw that SAP HANA could satisfy our example queries up to 160 times faster than the venerable MySQL database.

In Chapter 2, SAP HANA Studio – Installation and First Look, we started looking at SAP HANA from the inside.

We saw that accessing SAP HANA is relatively easy, either by purchasing a license, creating a virtual machine at a cloud hosting service, or by asking SAP for a free trial of the system.

Next we started a tour of the SAP HANA Studio , the modeling software used to work with the SAP HANA server. We saw the different perspectives (groups of windows) and panels available, and how to use them.

Finally, we imported some sample data, had a look at its structure, and checked that everything was correctly present in our system, using the Data Preview feature.

Our development journey proper started in Chapter 3, Your First SAP HANA Development – An Attribute View. We created a Delivery Unit and a Package to contain our future developments, then went on to create an attribute view , permitting the display of master data (non-numeric data).

Our attribute view started by exposing only some fields of a base table, then we improved it, adding a second table to show a customer's name alongside their ID.

Filtering on the Client field allowed us to automatically exclude certain rows from the view's output.

Junctions between tables, as well as joins, according to the user's connection language to display textual descriptions were explained also (text join).

Analytic views were what we discovered in Chapter 4, Painting with Numbers – An Analytic View. We saw that analytic views are views on base tables, allowing us to work with numeric data (measures) as well as nonnumeric data (attributes).

Measures allowed us to define the default aggregation of fields, such as SUM, MIN, or MAX, and after adding an attribute view to our analytic view, we were able to benefit from all the work we had already done, making the best use of these reusable objects.

We also learned about restricted and calculated columns, and how they could help us do low-level calculations automatically in the view, making the results available everywhere the view is used.

Lastly in Chapter 4, Painting with Numbers – An Analytic View, we created an input parameter , allowing user input in our view (a projected revenue increase). We used the input parameter in a calculated column, making the result of our view dynamic at runtime.

Chapters 5, Let's Get Graphical – Graphical Calculation Views, and Chapter 6, You Talking to Me? – Scripted Calculation Views, introduced the notion of calculation views , both graphical and scripted using SQL Script . We learned that calculation views allow us to extract data from two or more analytic views or tables at once, group the data together, and display one vision to the user. We used this notion to combine real data from one analytic view and projected data we created using our input parameter to another, together in one view with the aid of projections and a union.

In order to show that calculation views could be built either using the graphical designer available in the Studio, or in SQL Script, we built the same view using both methods.

Chapter 7, Hey! That's My Data! – Authorizations in SAP HANA, started the section on helper functions rather than pure database development, introducing the notion of authorizations in SAP HANA.

We saw that we could restrict access to database objects at the SQL level (tables and schemas), which defines who can work with an object but doesn't consider the object's contents, or at an analytic level, allowing limiting by field values. System privileges allowed access to certain system functions for our users.

We created a role, allowing us to ensure that attribution of privileges to users was done coherently across the system, and then created a test user having the role we'd just created. We were then able to connect to the SAP HANA system using our test user and do some tests, confirming that our restrictions worked as expected.

When we moved on to Chapter 8, On Another Level – Hierarchies in SAP HANA, we discovered hierarchies and how they could help presentation of data, especially for calculation of subtotals according to the data being displayed. We discovered that unfortunately, many reporting systems are unable to use the hierarchies we develop in SAP HANA, and we were only able to see the results of our development in Microsoft Excel.

Chapter 9, Deploying Your Reporting Application to Reporting Software, allowed us to look at SAP HANA from a user's viewpoint, discussing the relative merits of some of the more prominent reporting software compatible with SAP HANA. We examined SAP's Visual Intelligence tool, Microsoft Excel and Tableau, showing how each of these tools could be used to display the contents of the data models we'd developed together.

We saw that some tools (especially those developed by third-parties) require that we install SAP's SAP HANA Client software in order to be able to use them, while others (those made by SAP, unsurprisingly) don't require extra drivers to connect natively to SAP HANA.

For those pieces of software requiring the Client drivers, we had to make sure that the correct version (32-bit or 64-bit) was installed, depending on our Windows version, and whether the tool itself was 32-bit or 64-bit.

In Chapter 10, Data Provisioning with Data Services, we took a while to look at exactly how we could load our SAP HANA database with our datasets sometimes totaling millions of lines. We created a datastore (connection to our SAP HANA instance, using an ODBC connection), a format (flat file definition), a data flow , a job, and a project to perform the data load of a CSV file of five million lines. We saw that a template table in BODS was able to create a table automatically in SAP HANA, before loading the table with data.

The fourth and final section of the book, website development, was covered in Chapter 11, Application development with the XS Engine. We spent a little time examining the XS Engine, then went on to write a simple two-liner, the Hello, World! application, seeing that the XS Engine is JavaScript-based on the server side.

We used application descriptor files, .xsapp and .xsaccess to enable our users to see and call up our application, and had a look at the different configuration options available to us as application developers.

We then added database access to our sample application, reading data from the attribute view we created back in Chapter 3, Your First SAP HANA Development – An Attribute View, and displaying it on the output webpage.

Finally, we took a look at the SAPUI5 user interface framework, first creating a static webpage showcasing some of the functions of SAPUI5 then integrating the static webpage with our database accesses in order to create a pleasing user interface for our users displaying data from our SAP HANA database. A second webpage allowed us to pass parameters from one page to another securely, using placeholder replacement in our SQL query to protect our application against malicious users.