HANA Talk – A Simple HANA XS helper
HANA XS Engine. This is intended to help people who are just starting out development on XS Engine and would like a easy place to get their feet wet without having to go through too much trial and error. This is also a great starting point for people involved in events like InnoJam, Hackathons, etc. when POC’s and demos need to developed quickly, but not necessarily perfectly *cough* or securely *cough* 🙂
By providing this tutorial and the HANA Talk download, my hope is that it will encourage more people to consider using XS Engine as a app platform to drive their front end web apps and subsequently, encourage the use and innovation around HANA in general. Anne Hardy had a comment in her blog post regarding the Developer Advisory Board which was along the lines of “Developers want to get it in 5mins max; they want to build real stuff in less than an hour”.
I frequently get discouraged by the amount of learning and effort always needed to learn new technologies and products which companies “get into bed with”. Nearly every one of the apps I develop start out in a POC type phase, where my imagination and reality clash and inevitably produce the equivalent of a 3yr old’s self portrait, often resembling “Unconventional”. While going through these exercises I often wish it was simple to get somethings done, and understanding the cost and willing to accept the trade offs. This is why I developed HANA Talk – to make those unconventional portraits, easier to deliver 🙂
OK – so what does it do?
By adding a HANA Talk js and xsjs file to your project, you can simply write SQL statements in your HTML file and have the results returned synchronously.
Super simple and easy. See below for further details.
1. Download/fork these 2 files – client.js & server.xsjs from Github and add them to your package. The filenames/structure can be changed if you are feeling adventurous. In your HTML file, you will need to reference client.js, this is as simple as adding a tag to you header. For reference, if you are not using SAP UI5 or jQuery – you will need to add this to your HTML header as well.
A Basic Example
var hana = new HanaTalk('SYS'); //The 'SYS' reference is in relation to the Schema. It can be specified here or within your TSQL Statement
3. Call your HanaTalk object with the operation type and SQL you would like execute (see below for additional operations).
var result = hana.executeRecordSet("SELECT 1 FROM DUMMY");
4. We can populate that response into our html (DOM)
document.getElementById("SomeElementID").innerHTML = result;
A few more examples
a.) Insert/Update/Delete a record – use .executeChange, this will execute your code and respond with the records which have been updated
document.getElementById("resp4").innerHTML = /*hana.executeChange("UPDATE/INSERT/DELETE .... ") + */ ' Record Changed';
b.) Return a Table – using .executeRecordSet will return a html formatted table, displaying the select’s record set
document.getElementById("resp2").innerHTML = hana.executeRecordSet("SELECT TOP 5 * FROM M_HOST_INFORMATION");
c.) Return a Object – .executeRecordSetObj allows us to loop through records, and have quite a lot of control of the display of each record and its column name.
document.getElementById("resp3").innerHTML = hana.executeRecordSetObj("SELECT TOP 5 * FROM M_HOST_INFORMATION");
Here are the results of the calls above:
As you can see, making these types of calls is fairly simple and since your files reside directly on the DB app server, responsiveness is not too bad. So what’s so bad about this method?
Security: Because you are passing your SQL text directly from your browser to the backend server, you open yourself up to all kinds of SQL Injection hacks. Technically, we are not parsing URL arguments/parameters into the server side DB request but rather entire statements. In order for us to hack this, we could simply change the URL request to include some devious SQL.
Speed: For simplicity and to avoid AJAX Callbacks, the execution is performed Synchronously (i.e. We wait for the server to completely respond before we continue processing). The good: Code is “inline” and easy to manipulate the response/results from the server. The Bad: if we do a Select * on a massive (read billion) row table, the entire window is locked/hung until it either times out or completes. Not a particularly nice behaving UI.
The usual disclaimer: As mentioned, the intent of this post/download is to encourage simplicity, this comes at a cost, both performance and security are less than perfect – in this case, we will do our best to mitigate some of these. In fact, I expect a snarling comment from Thomas Jung, like a high school math teacher, disappointed that one of his protege openSAP students would even suggest these obscenities 😉
I encourage you to test this out and provide some feedback or makes some changes and share this with the community.