openSAP Software Development on SAP HANA (Delta SPS 09)

WEEK 2, UNIT 1

00:00:09 Hi, welcome back to Week 2, Unit 1. In this unit, we will cover the new features for XSODATA.

00:00:17 So the first new feature is the improved XSODATA ODATA editor in a Web-based Development

Workbench.

00:00:25 This new editor supports syntax highlighting and basic keyword code completion very similar to

the SQLScript editor that we saw last week.

00:00:34 So let's take a look. So I'm in the Web-based Development Workbench.

00:00:40 And I'll go ahead and open up my businessPartners.xsodata file. You can see it's a very basic

editor with various

00:00:51 keyword highlighting. If I wanted to add some code here

00:00:57 I could hit CTRL+SPACE and it would give me a listing of possible keywords

00:01:03 that I could use within this context. It is sensitive to where you are in the code itself,

00:01:11 so if I put my cursor here and do CTRL+SPACE, I have other options to use here.

00:01:19 So pretty helpful when you're coding your XSODATA service. OK.

00:01:27 You can also run this service directly from the Web-based Development Workbench simply by

clicking Run.

00:01:37 So we have my service here. I'll just add BusinessPartners

00:01:47 So I've added the business partners called Business Partner Entity. And another new feature

that we introduced in SP 09 is the

00:01:55 the concept of profiling. So in this case, I'll add

00:02:05 profile=html, and then I get this nice screen that has information like

00:02:13 how many milliseconds the request takes. And then we have it broken down into

00:02:20 for example the retrieve service document from the repository took .016 milliseconds.

00:02:28 Parsing the request, opening the database connection, and so on and so forth. And a nice,

really nice thing that we can see here is of course the actual SQL statement that's generated

underneath.

2

00:02:39 So that's always helpful to see what's actually happening underneath your ODATA service. It's a

very nice, handy tool.

00:02:47 And if I needed this back in JSON as well I can do that simply by changing the parameter here

to JSON.

00:02:55 And I get the same information back in JSON format. OK.

00:03:04 Back to the slides. Another new feature is the

00:03:12 XSODATA Explorer. The roots of this tool come from what we have learned with the SAP River

project.

00:03:21 We'll talk about the future of River next week, but for right now let's explore this new tool, which

we can use to test

00:03:29 an OData service as well as generate data for that same service. We can access this tool by

going directly to the tool URL

00:03:38 or we can launch it from the context menu within the Web-based Development Workbench.

We'll see that in the demo.

00:03:48 So we'll go back to the Workbench here. And I'll right-click on my file and I'll choose Open

OData Explorer.

00:04:01 This application runs and you'll notice that the direct URL is

SAP/hana/ide/editor/plugin/testtools/odataexplorer/index.html

00:04:14 And then it's just a matter of passing in the package hierarchy and the name of the XSOData

service that you want to explore within the OData Explorer.

00:04:27 So we'll select the business partners entity here. And that will automatically do a service call

and bring the results set back into this table.

00:04:39 So it's a real quick and dirty way of testing your OData service and making sure that you're

getting data back. Another handy tool here is the ability to generate data.

00:04:51 So I can click the Generate Data button here. And this gives me several options. I can generate

a random

00:04:59 value for PartnerID. Or I can have a fixed value. So say, for example, I want a fixed value for

PartnerRole.

00:05:06 I can set that to Fixed and make it 02. And I want to generate three records. I'll keep it real

simple.

00:05:15 And all this other information will just be randomly generated. Then say Generate. And then if I

look at the bottom of my service here,

00:05:26 I have three new records down here with, just you know, random data. They all have the partner

role as 02.

3

00:05:38 And then just random data throughout all the other columns. So again a quick and dirty way of

creating data in your tables for testing purposes,

00:05:50 makes the developer much more efficient in testing their services before building the UI on top.

OK, back to the slides.

00:06:02 So some various, other various features that we issue with SPS 09: first one configurable cache

settings for metadata document.

00:06:11 This has to do with the $ metadata option that we currently use to get the metadata of our

OData service. When this is called, the system has to go to the database and determine the

column and column definitions on the fly.

00:06:25 We now have a configurable setting for allowing this information to be cached on the server

side, so that when this call is made, it can read the cache, instead of rebuilding all the data from

scratch.

00:06:37 This is probably something that you would turn on in production, probably not in development.

Next one is E-tag support.

00:06:47 Now this is part of the OData standard. So support for this has been in high demand for quite

some time. This has to do with concurrent updates and deletes.

00:06:59 We don't have application locking in XS today, so we need a way to ensure data consistency

when working with XSO data. We can use e-tags to help manage this.

00:07:09 When using e-tags, you execute the read operation and the system then generates a key with a

timestamp, which is then passed back when doing an update or delete.

00:07:19 The system then uses this key and timestamp to look up if there are any changes have been

made to the data since the initial read.

00:07:28 If there's a conflict in the system, the system will generate an error without trying to resolve the

conflict or merge any changes. This is not proprietary functionality but part of the OData-specific

specification.

00:07:43 Next one is automatic parallelization for GET batch requests. So instead of performing

individual GET requests, you can batch requests as of SP 07.

00:07:56 But all requests within the batch are always executed sequentially. Now as of SP 09, all GET

requests within the batch are automatically parallelized for you. You don't have to do any coding

00:08:12 to parallelize them. And then finally INA search capabilities integrated into OData.

00:08:19 So previously with the INA search, we had a standalone search service for defining restful

services for search. But now it's all built into the XSOData artifact

00:08:30 in the existing OData service framework. Thanks for joining this unit on XSOData. In the next

unit, Tom will talk about the new XSJS database interface.

4

WEEK 2, UNIT 2

00:00:10 Welcome back to Week 2, Unit 2: XSJS New Database Interface So in this unit, we're going to

take a look at this brand new database interface implementation that we have in server-side

JavaScript.

00:00:24 So you might be wondering, well, why would SAP create a whole new database interface? We

already have the $.db interface today.

00:00:35 But we saw that it had some design limitations that we wanted to work around, but also there

was a lot of behind-the-scenes work that we wanted to do on the database interface as well.

00:00:50 So all along, you know, the whole message around XS and its closeness to the database has

always been about performance advantage, you know, not having to move data around.

00:01:06 Yet, we had some things in the old database interface that we didn't like. It was using the

distributed query interface that HANA uses internally to talk between different index server

nodes,

00:01:20 which is fine when you have index servers talking to each other for a distributed query, but not

necessarily optimal for all the ways that we might want to execute SQL or call a server

procedure from an application services layer.

00:01:34 So one of the things we set out to do was to actually decouple the database library out and put

a little bit more separation between XS and the database itself.

00:01:50 But in doing so, in moving it out and not reusing so much of the index server internal libraries,

what we were actually able to do was increase the performance,

00:02:02 because we were able, particularly in scenarios where you have a lot of parallel query activity,

we were able to better distribute the load,

00:02:13 we were able to, particularly in a scale-out scenario when you have multiple HANA server

nodes, we optimized the database interface. For that scenario, we also see a real focus on

reducing the amount of data traffic between the nodes

00:02:32 and between the XS layer and the database layer. We'll see a little bit later some of the

approaches that we used to do that.

00:02:40 How it comes through in the programming model as well. At the same time, we wanted to fix

some of those things that we saw basically as design flaws in the database interface.

00:02:51 The current database interface is very JDBC or ODBC-like, which is fine because that made it

accessible to developers. But what wasn't nice about it was you returned this record-set object.

00:03:06 So that was hard to deal with from JavaScript. We thought it would be much easier if we just

used pure JavaScript concepts. If we just returned JSON objects, instead of this record-set

object that has to be iterated over.

00:03:20 Also, the way that it's structured today, there's a lot of query string building, there's a lot of text

literals used. And these getter and setter parameters, getter and setter function calls

5

00:03:34 that we have to use to get individual columns of data out of a record set. And that didn't really

lend itself well to the way that JavaScript works.

00:03:43 It meant that we had to write a lot of boilerplate code, we had a lot of repeated code, people

were creating reusable libraries to simplify the database interface.

00:03:54 So the idea was well let's just do this ourselves in the core database. So the idea here is that we

can't get rid of the old database interface, the $.db.

00:04:06 We can't just make major structural changes to it because that would cause incompatibility in

the applications that you've already built, that SAP has already built.

00:04:16 Legally we don't do that. So we introduced a new library, we introduced $.hdb that has all this

new functionality and structure inside of it.

00:04:29 The end result I think you'll find is that it's a database interface that's easier to program with. It

requires less coding, less processing of the data after you retrieve it from a query,

00:04:41 but also results in better overall performance. It means that we no longer do any of the SQL

processing in the XS layer itself.

00:04:50 So a clear separation between the layers really sets us up for where want to go with the

architecture in the future

00:04:57 to allow us more scalability and security options at the XS layer, but still optimize and have

really efficient interaction with the database itself.

00:05:10 So let's actually start by looking at the old database interface and some of the common

problems that we have with the old database interface.

00:05:18 This is a good source code example, simple SELECT * FROM a table with a WHERE condition.

Nothing really changes much there. I mean, we build a query in a string.

00:05:33 We can parameterize our query, that's what the question mark is in the WHERE condition. We

then pass that query into a prepareStatement.

00:05:42 And then this is where things get a little not-so-JavaScript-friendly is we can't just pass in

productID into the query.

00:05:49 We have to call this pstmt.setString So this where things are a little cumbersome because we

can't just say "set parameter"

00:06:01 and let the database interface figure out the data type. We actually have different set and get

functions for each major data type. And we have to match them up. So we have to call

setString, we have call setInterger

00:06:13 And that means in your coding, you're having to basically hard-code the data types of the

columns that you're interacting with. And that reduces the amount of flexibility that you have if

you change data types over time.

00:06:25 It introduces risk of getting it wrong, specifying the wrong data type. And then, of course, you

won't get a syntax error, you'll blow up at runtime.

6

00:06:39 Next we see we execute the query and we get this record set object back, or result set object,

you see it called both ways. Kind of an odd object, it's not a JavaScript object. We can't inspect

it in the debugger.

00:06:56 We have to iterate over it, one record at a time, so we have to do while (rs.next) We can only

process one record at a time, we can only move forward through a record set object.

00:07:08 So no direct index access, no going backwards once we've read a record. If you need to move

back in a record set, you have to perform the query again and start over.

00:07:20 So a lot of limitations there with the processing of the record set object. And then you see the

same problem when we need to get data out of that record set.

00:07:27 Even once we have an individual record, once we have positioned on a single instance of a

record inside that record set object, we still have to call for each column that we want to get

data out of,

00:07:40 we have to call these get functions and, once again, they're type-specific. So getDecimal,

getNString, and then we have to give it the position, the column position

00:07:51 that we want to get out of. So you kind of have somewhat unreadable code because you're

passing in column positions, you're like rs.getDecimal(6)

00:08:03 Well, what column is that from my results set? It's difficult to read, it's difficult to maintain. Once

again, we're tied to the data types of the columns that we're reading.

00:08:17 So as I said here, no random access, one loop sequential, not very nice, and type-specific

function calls.

00:08:25 Now, the new database interface $.hdb with the same query SELECT * FROM table WHERE

PRODUCTID, you'll notice we still build up a query string, we still have parameterized

statements,

00:08:38 nothing has change there. But when we execute the query, we don't need that prepared

statement.

00:08:44 We simply pass in the query string, and then if you have parameters that go into that query

string, like the PRODUCTID in this example, we just pass those in to the call itself. So much

more JavaScript-like.

00:08:58 You know the parameters are dynamic and can be passed in like you would any JavaScript

function. Also, very useful, not shown in this particular example, but let's say you needed to

pass in a table.

00:09:10 So, particularly a little bit later, we'll talk about calling stored procedures, and it's common to

pass, have input table parameters. And in the old database interface, it was very cumbersome

to work with any sort of table parameters.

00:09:26 You had to insert them into temporary tables and then reference them. Here we can pass a

JSON object in.

00:09:34 So, we tried to keep everything feeling very JavaScript-native-like. Now, the other big part of

this is the record set object that we get back.

7

00:09:45 It's no longer that funky, unusable, forward-only kind of record set that was very cumbersome.

Now what we get back is what looks like a JSON object.

00:09:59 And we can process it like any other JSON object. We can go directly to any index we want, so

we have direct index access.

00:10:05 We can use a standard JavaScript loop construct. That's what you see here with the for

statement. We're basically just saying while this variable that we've defined that starts at zero is

less than the length,

00:10:18 the number of records that are in the record set, then form this logic once per pass and

increment the counter i.

00:10:27 We're able to directly access, you know we keep that i, and that's how we access a particular

record. So we say record set i. We could have read-from/process multiple records at the same

time.

00:10:41 They could have multiple variables there that reference which record I'm on. And you see here

the columns, no more getter or setter functions. We simple give the column name

00:10:53 that we want. So more readable code because we see the column names referenced here. But

also much more maintainable over time because we don't have the specific types

00:11:04 coming in as well. The other big advantage to this, although it looks like it's a record set object

00:11:15 or this record set object looks like it's a JSON object. You process it just like a JSON object.

00:11:20 You actually don't have to copy all the data into the JavaScript VM. This is a special JavaScript

object if you will.

00:11:29 It really just has a pointer to where the data is still over in the database interface itself, in the C

layer. It doesn't have to be allocated to the JavaScript VM, of course, until in this case we're

building up a body

00:11:44 until you copy it into a JavaScript variable, manipulate it in some way, the data doesn't have to

be materialized, memory allocated for it in the JavaScript VM.

00:11:56 So, not only do we increase the performance, increase the usability, but also, we potentially

lower the memory footprint, particularly if you're just iterating over a large result set

00:12:06 and not actually bringing that data into a lot of JavaScript variables or storing it in a JavaScript

variable. So, the other impact as I said that this has is on the debugging experience.

00:12:21 And I think that this is a great time to switch over into the editor. And let's just have a look at the

impact that this has on the debugging experience.

00:12:33 So I'll go ahead and log in. And, of course, my session has timed out. So let me just refresh.

00:12:42 And I have some examples already prepared here. A little before and after example. This is

basically the same thing that we were looking at in the slides. We were doing a SELECT.

8

00:12:53 What I want to show you here, in particular, is the usability of the old record set object that was

returned and the new one.

00:13:02 I'm going to set a breakpoint here after the query has been performed when I have access to

this rs object. And let's just go ahead and run this. It's stopped in the debugger.

00:13:12 And what you'll see here is we've stopped here on this rs object. And if I come over here to the

debugger, I don't really get anything very usable.

00:13:22 It just says object ResultSet. It tells me what type of object it is. But I can't look at the individual

records that are inside here.

00:13:30 It's not until I iterate over this and I get access to each line and really I can't even see the

individual record then,

00:13:42 it's not until I move the values into a JavaScript variable that I can even see them in the

debugger. So this created a situation where it was difficult to debug. I mean, sometimes you

had to write extra code

00:13:55 in your service just to be able to move intermediate values into a JavaScript variable so that you

could see them in the debugger,

00:14:03 and that's not really something we want to be doing. So I'll go ahead and finish that service.

00:14:11 So let's go over and look at the after. So this is, once again, the same basic source code that

we saw in the slides. We've got a little, you know, output processing and stuff that was in the

slides.

00:14:23 But as far as the processing of the database interface, it's still the same. I'm going to go ahead

and set a breakpoint here before I go into the loop on the result set object.

00:14:35 And let's go ahead and test this. Once again, we stop in the debugger. We come over here. But

now this result set object, if I open this, now it's very usable.

00:14:46 Look, I see all the records that are in the object. I can go into an individual record and I can see

the columns, and I can see the data that's in those columns.

00:14:56 So before I even iterate over the result set object, I have full visibility to all the data that's in that

result set object as though it's just a JavaScript variable.

00:15:09 As I said, we treat it exactly like a JSON object. So, much more usable in the debugger. So this

isn't just about performance, and it isn't just about usability from a source code standpoint.

00:15:21 It's also about the ease of debugging as well. Returning to the slides...

00:15:29 Another benefit of this, because we are returning a JSON object as the record set it's very easy

to then output that.

00:15:37 In the old database interface, you had to iterate over the data and you probably had to move it,

you know, one column at a time into a variable. And you had to build your own JSON output

00:15:49 because, let's face it, quite often we're consuming these services from the user interface and

JSON is probably the most common output format that you want to send down to the client side

9

00:16:01 because it's so easy to consume and use on the client side. So, we're using JSON internally

and because that result set is returning JSON already,

00:16:12 all we have to do is call JSON.stringify to take the JSON object and turn it into its string-based

notation so we can set it into the body of the response object.

00:16:21 So you see how easy it is now, I don't have to iterate over the result set. I don't have to do any

further manipulation to it, I don't have to build my own JSON or output format.

00:16:32 I've just, with one line of code, I've got it in a format that's ready to send down to the client side.

Now…

00:16:43 I hinted earlier that this database interface also simplifies access to stored procedures as well.

And what we see here is, I think this is really nice because stored procedures, let's face it,

00:16:56 used to be in the old database interface a bit of a pain to be able to call from XSJS. It was hard

to structure the call,

00:17:04 your input/output parameters, because they were off in table parameters, were difficult to work

with. You had to create temporary tables and it was all very nasty to be honest.

00:17:17 This new interface allows us to simply say loadProcedure, and then we give it the schema

00:17:24 and the procedure name, including the package path, if it's a repository procedure. And what we

get is a JavaScript object that feels very much like a JavaScript function.

00:17:35 So, basically, at this point it feels like JavaScript code, we call it like JavaScript code, passing in

input parameters, just as we would a JavaScript function,

00:17:45 getting back a result set. We can get, this result set will basically be a JSON object, and you

have multiple output tables

00:17:54 that are just sub-objects inside this result set. Very easy to process the input, very easy to

process the output as well.

00:18:03 So, once again, the simplicity of having JSON or pure JavaScript parameters for the input and

the output makes this feel very JavaScript-like. And that result set is JSON as well.

00:18:18 And, just to close out, I'll show you a couple more examples here of what we were talking about.

Here I'm performing a SELECT from the Employee table.

00:18:30 And I get a single record, and so I'm just getting the first record that's returned. And then I'm

using JSON.stringify. So this shows you how easy it is

00:18:38 to put it into a format that's ready for output. No wild processing or anything going on here. I'm

able to run this. And you see the output that I got in the browser, this is just the JSON that's

been stringified.

00:18:51 And then the browser knows how to present that. I have a little Chrome plugin here that does

some nice formatting on it.

10

00:18:58 But you have this very easy-to-process format on the client side. And then likewise, here,

performing a query, you don't have to process the whole record set,

00:19:12 you don't even have to process a single record. Here I'm just taking a single value. So I'm

saying: first record, EMAILADDRESSES, put it in a variable, and then just put that in the output.

00:19:22 So, once again, here there's now just the text representation of that variable is in the response

body. You can have your services be as simple as that.

00:19:30 And then, finally, just to show you an example from the slides, the last example that we looked

at where we were calling a stored procedure. In this case, I create this getBpAddressesByRole

00:19:43 that really becomes a function proxy for the stored procedure that I specified here. We pass in

the partnerRole, so that's the input parameter, we get back the result set.

00:19:53 And, once again, I'm just doing JSON stringify on the result set. So if I run this, then you see...

00:20:01 if I'd had more than one output parameter, it would just be listed here in the JSON and that

would be the first level of the JSON.

00:20:07 I only have one output parameter EX_BP_ADDRESSESS and then it's just an array of data

inside there. So you see, once again, how simply we were able to process stored procedures

and

00:20:21 handle the JSON output there. So I hope this unit has given you a better idea of both the power

and ease of use of the new database interface.

00:20:32 Please join us for the next unit where my colleague Rich Heilman will go over further details on

even more of the new XSJS APIs.

00:20:41 It isn't just the database interface that got new or enhanced APIs, there's a whole slew of

additional XSJS APIs that we've added. And he'll go through those with you next time.

11

WEEK 2, UNIT 3

00:00:09 Welcome back to Week 2, Unit 3. In this unit, we'll take a close look at the new JavaScript APIs,

which are now available

00:00:17 in SP 09. First, let's take a quick glance at all of the APIs, which we'll look at in this unit.

00:00:25 We'll take a look at sending emails via SMTP, zipping files, XML parsing,

00:00:33 antivirus, Java scheduling, text bundling, text mining, as well as some secure store

00:00:41 access, multipart support, and asynchronous request completion. First, let's take a look at

SMTP.

00:00:49 Support for sending e-mails from HANA have been a must requested feature for

00:00:57 some time. And as of SP 09, we now have this ability. We can access this API via the

00:01:05 $.net.Mail. As you can see, to send a simple e-mail, the code is as simple

00:01:14 as a couple of statements, setting various properties and calling the send function. Of course,

sending simple mail

00:01:22 is not usually the customer's requirement. But instead, sending a mail with some sort of PDF or

other types of documents as attachments.

00:01:30 For this, we have support as well, as we can see in this example. We also have the SMTP

configuration,

00:01:42 which is quite straightforward as shown in this screenshot. You can access this configuration

screen from the XS Admin tool.

00:01:50 So let's flip over to the demo. So firstly let's look at the Admin tool. You can find the

00:02:00 SMTP configuration by clicking this box here and then under

00:02:08 SMTP Configurations here, and you can see the server host and the port and other types of

various

00:02:17 settings for the SMTP configuration. So let's take a look at the mail SMTP.

00:02:28 And I have mail.xsjs here, and you can see here I'm just simply getting a mail object using the

$.net.mail,

00:02:39 passing in the address of the sender, the address of the recipient, being me, with

00:02:47 a subject line, and then the body of the e-mail. In this case, we'll just we'll pass a text string

"Great job on the openSAP course".

00:02:58 So I can select this and run this. And that runs.

00:03:08 And I can go to my inbox and I should get a mail. And here I have my mail. noreply@sap.com

12

00:03:18 I open this up and I have "Great job on the openSAP course". So a very simple API to send e-

mail directly from HANA.

00:03:29 I'll close my Outlook. We'll close this.

00:03:36 So returning to the slides. The next API is the ZIP API. This, of course, allows you to zip up

00:03:44 multiple files and pass to the body of the response object. You can see that it also supports

folder hierarchies

00:03:52 as well. You can also load the ZIP directory from the request object, which allows you to avoid

moving the content

00:04:01 into a JavaScript variable. Similarly, you can directly access the record set object of a query and

pass directly to the ZIP API.

00:04:15 So let's take a look at this example. And that is under my zip folder, and I'll open this up.

00:04:27 So here, very basic building a ZIP object using $.util.Zip. And I'm building a text file under the

folder structure

00:04:42 folder1, and then the file name demo1.txt and then, under the root, a file called demo2.txt.

00:04:51 And when I run this, I'll get a ZIP file. I’ll save.

00:05:00 And I can open it up. And you can see that it, of course, does have the folder structure folder1

with my file and then my other file as well in the root.

00:05:13 Next is XML parsing. So we have an XML parser API which allows you to split up the XML into

its component parts and process them

00:05:23 accordingly. We support parsing from JS string and JS ArrayBuffer with encoding. The

supporting encodings are US ASCII,

00:05:35 UTF8, and UTF16. So let's take a look at this example.

00:05:44 That is under xml. So you can see here that I'm creating a parser object from the

$.util.SAXParser.

00:05:57 And then I basically have an XML document here to that I'm setting up the element handlers

00:06:08 here and here, and then simply calling the parse function here, passing my XML document to it.

And then outputting the results.

00:06:20 So I can run this as well. Nothing too fancy here. It's just simply breaking up the XML nodes and

printing them out to the screen here.

00:06:29 So another very useful function for parsing XML in JavaScript.

00:06:39 Back to the slides. Improved multi-part support. So prior to SPS 09,

00:06:46 there wasn't an API to read the individual parts of a multi-part request. You had to read the raw

request body and then parse the parts yourself.

13

00:06:54 But now there's an API to request the parts one at a time. The result of this API is the entities

object.

00:07:03 Now this entities object is an array with each body part as a member of that array.

00:07:10 It's much easier than having to split the body string looking for a text tab of the part delimiter.

00:07:20 Next we have response callback API, which allows you to run a follow-up job that executes in

the background.

00:07:28 The parameters include the name of the xsjs file, the name of the function to be executed, as

well as any

00:07:36 parameters for that function. The text access API allows you to have much cleaner access

00:07:45 to text bundles within your application. You simply load the bundle and then have access to

each item within it,

00:07:53 simply by calling the getText function, as you can see here, or get all texts by calling the

getTexts function.

00:08:03 Let's take a look at that. I believe this is under textAccess.

00:08:18 So I have this hdbtextbundle here with two values in it - demo and demo2.

00:08:25 You'll notice here demo2 is equal to purchase orders with a placeholder value there. I'll look at

textdemo here.

00:08:34 xsjs. You can see I'm using the API. Again $.import and then sap.hana.xs.I18n and then text.

00:08:50 Then we also have the load bundle function here, where I'm loading up the textAccess.

00:08:58 The demo1 text bundle from this package hierarchy.

00:09:06 And it's just basically saying getText passing in the name of the variable, and then

00:09:14 also for demo2 here, I'm passing in a value for the placeholder. So when I run this,

00:09:22 I get the purchase orders text back with the actual value that I'm passing in to that text

message.

00:09:33 So very useful for issuing messages using the text bundle.

00:09:46 OK, next antivirus. We now support antivirus API to allow you to check the body of a request. Of

course, in order for this to work properly,

00:09:55 you need to have a virus scan adapter installed on the host and configured. You can reference

SAP Note

00:10:03 2081108 for setup and configuration instructions. This uses the SAP-certified

00:10:11 interface NW-VSI 2.00. And for a list of all the antivirus products which are supported,

14

00:10:21 have a look at SAP Note 1494278. Next is the Secure Store API. This API allows you to

00:10:32 have read and write access to the secure store simply by calling the associated function -

whether it be storing or reading.

00:10:40 The Secure Store API can be used to securely store data in name value form.

00:10:48 Applications can define a secure store object file and refer to this design time object in the

application coding.

00:10:56 The XS engine takes care of the encryption and decryption. It also provides the persistency for

the data. There are two visibility

00:11:04 options for this data. Visible application-wide: All users of the application share the same data

and can decrypt or

00:11:12 encrypt the data. For example, passwords for a remote system and the other is

00:11:20 visible application-wide but with separation on user level. So every user of the application can

00:11:28 have its own encrypted data, which can only be decrypted by that user himself, such as a credit

card number, or PIN codes, or something like that.

00:11:36 So real quick on the demo here. Under the secureStore.

00:11:51 So you notice here that I have a file called localStore.xssecurestore and it's basically empty. It's

got a couple of curly brackets in it.

00:12:01 Now this is basically just a placeholder within the secure store so that we have a place within

that encrypted

00:12:09 storage area to put our values. So if we look at the service, you can see here I have a

00:12:17 store function as well as a read function. So based on my URL parameter,

00:12:25 I'll either store data into it or read data from it. So we can go ahead and

00:12:33 run this. I'm actually going to debug this one. So I'll put a breakpoint there and a breakpoint

here.

00:12:42 And we'll run this. And first I'm going to store the value.

00:12:50 So I'll hop back over here. And you can see I'm simply using the $.security.store, giving the

name of the

00:12:58 secure store file that I've already defined, and then calling the store function, passing in

00:13:06 the config object here. So basically the config object has the value pair name and value.

00:13:15 So if I execute this, everything looks good.

15

00:13:23 So we should have values in there. So let's go back and now I'm going to read. We'll go back to

the debugger. And now we're going to retrieve the value

00:13:35 that I've stored in the secure store simply by stepping over the code and watching the value

00:13:43 variable here change when we read the actual configuration. So it should be the word bar.

00:13:51 Yep. So value is now equal to bar so you can see how we are reading the encrypted data back

out of the secure store.

00:14:03 OK. That's about it for the XSJS APIs for Support Package 9.

00:14:11 In the next unit, Tom will be back to talk to you a little bit about XSDS or XS Data Services.

00:14:19 Thanks for joining.

16

WEEK 2, UNIT 4

00:00:09 Welcome back to Week 2, Unit 4, XSDS or XS Data Services.

00:00:15 So in this unit, we're going to take a look at this new library called XS Data Services, and unlike

the other new capabilities that we talked about in the previous units of this week

00:00:26 this one's a little different, mainly in its delivery mechanism. So this is also new functionality

00:00:33 that helps with building queries and particularly with transactionality. We’ll go through all the

details of what it's capable of.

00:00:42 But unlike the previous two units where we talked about the new database interface or the

various new XS JS APIs

00:00:49 this library, or API if you will, is different in that it's delivered as a JavaScript library itself.

00:01:00 So unlike the other APIs that are part of the $ namespace and show up just as, sort of,

JavaScript functions

00:01:08 this is really just a series of XS JS libs. Reusable libraries delivered by SAP as standard content

00:01:17 as a delivery unit that you can import into your HANA system or, in the case of this library, it’s

imported automatically.

00:01:25 Now, that's a little different because that means the entire library is written completely in

JavaScript, so there's no dropping into the C layer

00:01:34 of the XS engine for the implementation. But that also means that we can build it faster at SAP,

00:01:41 we can release new versions or fixes independent of having to get those changes into the

compiled C core

00:01:51 of the HANA engine itself. So this is just JavaScript that can be delivered.

00:01:58 And I think what you'll see is that increasingly in the future SAP will deliver new functionality in

the form of such reusable libraries rather than building so much into the HANA engine itself,

00:02:11 at least for functionality at the XS layer. So let's talk about this specific library, XS Data

Services.

00:02:19 So I think what you'll see is that this is sort of continuing the ideas that we introduced with the

new database interface.

00:02:27 The new database interface is all about simplifying query building, data access. This library

goes even a step further

00:02:35 but is very much in the same idea as to bring just, you know, pure JavaScript concepts as much

as we can

00:02:44 into writing data access logic and transactionality logic. So, what we see here is that we have a

very structured API,

17

00:02:54 particularly when we talk about the managed side of the API, rather than working with the low-

level SQL interface.

00:03:03 So with the new database interface, you know, we did a lot to optimize it technically and to

return JSON objects, but you still had to build that SQL query using just a regular string.

00:03:14 We can parameterize the query, but this library wants to go a step further and really put a lot of

process and structure around how we even build that query up.

00:03:27 The end result, hopefully, is that you have a lot less coding, a lot less boilerplate coding, a lot

less cutting and pasting of similar code,

00:03:38 and you can focus instead on the processing, your business processing in the actual query logic

itself. So, what we see, the other aspect of this library

00:03:50 you know, the new database interface is about issuing SQL statements and calling stored

procedures. But we also have the concepts of CDS.

00:04:01 If you remember back to the previous week, in Week 1 we talked about new features in CDS,

Core Data Services.

00:04:08 And up to this point, Core Data Services, has really been localized, just being able to define

tables and views.

00:04:17 But then all the consumption of those tables and views still had to go back through the catalog,

and we started to use SQL to read from those tables or views.

00:04:25 The idea of XSDS is that we want to extend the definitions of the entities and the associations

that we already built using the CDS syntax

00:04:36 but now bring that into our service layer and our application logic layer. So what this library does

is take those same entity definitions

00:04:48 and associations and expose them as JavaScript objects. So it really helps us reuse the CDS

content, its metadata,

00:04:56 all that work that we did to define the entities and their relationships and use it in another layer

of the programming model.

00:05:07 So there's multiple parts to XSDS. It actually started off inside of SAP as completely separate

libraries.

00:05:16 And we merged them all together into XS Data Services. At the foundation, of course, we have

the existing CDS functionality.

00:05:27 That doesn't really change. We're sitting the XS Data Services on top of the CDS entity

definitions. And the three parts of the library. First we come in, we have an ORM

00:05:41 or an Object Relationship Mapper. And in many environments, what you have to do is you have

to create a little definition file

00:05:50 that says here's my database table and here's my object and how I want it represented and

here's the mapping of column names between the database

18

00:05:57 and how I want the object represented in my application server layer. Well, what we're able to

do is do basically automatic ORM.

00:06:07 We can just read the entity definitions either from the catalog directly or from CDS, and you get

the most value if you read them from CDS,

00:06:17 because we have so much more metadata there about the entities and their relationships. But

what this ORM is responsible for doing is creating JavaScript objects

00:06:28 that look exactly like the underlying entities. So you never have to build a mapper, you never

have to build the relationship.

00:06:35 The entity definition that exists to create the database object is the same one that is used to

create the object in memory at the application server layer.

00:06:44 So there's a lot of benefit there by reusing the entity definition that already exists inside the

database. The other two parts to the library, we have XS relations.

00:06:56 Well, this is once again an extension of CDS. We can, of course, build queries that would read

from the entities, the tables or the views.

00:07:04 We remember CDS also has associations. Associations are a way of linking one or more

entities together.

00:07:14 This allows us to follow links. We think of it probably most commonly as a way of joining two

tables,

00:07:23 but it can also be used when we talk about transactionality and inserting data in the database

making sure that child entities are also inserted or updated at the same time

00:07:34 and really allows us to use these relationships, these associations to form our referential

integrity of transactions.

00:07:46 And then finally, there is a Query Builder interface. We'll see that there's really kind of two

different flavors of this:

00:07:52 One where we're using CDS and managed objects, a very simplified query interface that allows

us to use more of an object relationship approach to accessing the data;

00:08:03 and then there's a full Query Builder that allows you to use JavaScript semantics to build up

complex SQL statements without having to build your own strings

00:08:15 and concatenate together, a much more JavaScript-function-call-friendly kind of approach to

this. Now we're going to look at examples of all these parts of the library.

00:08:28 Maybe before we do, it's important to note that Core Data Services, just to refresh your memory.

Up to this point, we've talked about it a lot in the HANA world

00:08:43 and it's been very focused on the data definition, just creating the entities, creating the views,

maybe using associations only in the views.

19

00:08:51 But now you see how we're beginning to deliver on the promise of Core Data Services. That it's

so much more than just data definition

00:08:58 that it's also a query language, it's also a data manipulation language, it's also a data control

language.

00:09:05 And by extending the concepts, the entity definitions and the association metadata from the

database layer up into the application server programming layer

00:09:16 now bringing into XS, with the XSDS library, you see how we begin to permeate CDS entity

definitions all the way through

00:09:25 the programming model. In the future, we'll hopefully continue to spread this so hopefully we'll

bring entity definitions into the SQLScript world as well.

00:09:35 We've already done this in the ABAP world and we have similar capabilities in the ABAP world

to use CDS

00:09:42 to define advanced views, and in the future, we'll bring CDS capabilities to Java and other

runtimes as well.

00:09:53 Now, when we look at the interaction between CDS and the XSDS library, XSDS is just a

JavaScript library.

00:10:03 You'll see in a few seconds in the code samples how we have to import the XSDS library. It

gives us access to the APIs, that basically give us not just the entity definitions.

00:10:17 You'll see that we can import the entity definition from CDS or from the catalog, but also

exposes the associations, the view building,

00:10:28 but also the query language for being able to write back into the database as well. Now that's a

pretty important distinction. A lot of people ask us, well, we want to create transactional

applications,

00:10:40 what's the best approach to do this? People coming from the ABAP world, they expect this

application level support for this for a lot of parts of transactionality.

00:10:50 And that's really the gap that XSDS begins to fill. Now, let's look at some examples, because I

think the best was to talk about an API,

00:10:58 to learn it, is to look at some source code examples. And what we see here is a simple entity

definition,

00:11:05 so this is just a CDS HDBDD, just setting up what we're going to be working with here where we

defined a user entity, we have a text type, and then we have a post entity

00:11:18 that has associations back to the user and it has associations to itself. So you can have a

parent post, a child post, so we have some fairly complex concepts involved in this sample

entity model.

00:11:36 Now, if we want to get access to a particular entity, all we have to do is use the XSDS library

00:11:44 and we say $ importEntity. We give it the package path to where the HDBDD file exists

20

00:11:52 and then we give it the name of the entity within that file. For instance, here we're going to want

to create a user entity.

00:12:00 And you see the return there, we created this var User. That's a JavaScript object. Now that

JavaScript object will take on the entity definition,

00:12:10 so it'll have properties that match the columns in the underlying database table. But it will also

take on a series of functions that we can call on that as well

00:12:23 to manipulate the data, to query the data or any number of things. Now, during this import entity,

it's important to note that you can override certain aspects.

00:12:37 So maybe you want to, you see here we're adding an association, a backlink association to the

entity definition as it's being loaded into the JavaScript object.

00:12:50 It allows us to either override or enhance the definition as it exists in the HDBDD file. And for

instance, the via backlink, it’s not actually supported yet in the HDBDD artifact in HANA.

00:13:04 It is part of the CDS specification, but it has been implemented at the JavaScript layer and that

allow us to add it at that time.

00:13:15 Now, I want to show you another example, this is very common. Of course, my session has

timed out, let me log back in real quick.

00:13:23 OK, we’ll go here to an example. What I want to show you here is, we'll come back to this

example and look at the transactionality a little bit later.

00:13:37 But I want to show you focusing on the import entity. This is another example of what powerful

override mechanisms we have here.

00:13:45 In the slides, I showed you how you can add an additional association. But in this case, I'm

importing the entity and you see here I have a column.

00:13:55 So I can change the properties of a particular column. This time, I'm saying take the

PARTNERID column

00:14:03 and actually, I'm saying add to the key definition of this column, and what I've added here is a

sequence.

00:14:11 So this is also a nice way of linking different parts. In the traditional approach, when I did the

insert into the database

00:14:20 I would have to add to the SQL statement the sequence "next value". To increment the value,

the sequence would automatically insert that value into the record, and put it into the database.

00:14:34 Here, I'm creating a linkage and I'm saying this entity now should use this sequence

automatically any time there's an insert. And the same way here with the address object, I'm

saying use the ADDRESSID sequence.

00:14:50 And a little bit later, we'll talk more about what's going on here but basically, I'm creating a new

address, I'm creating a new business partner.

21

00:14:57 In neither of these cases do I have to specify the partner ID or the address ID. I simply create a

new instance of that object, that's what I'm doing here,

00:15:06 passing in the particular values, and then I call the save function. And that's going to persist the

data in the database and it also calls the sequence for me automatically.

00:15:17 So just another example of what we can do as we're importing the entity definition. We're not

locked into just what we can define in the HDBDD artifact.

00:15:28 We can go further as these two examples show you. Now, returning to the slides, this import

process can be a little costly,

00:15:40 because we have to go and read all the CDS metadata for the object that we chose. And

sometimes in a service interface, because we're stateless, we're calling that import entity over

and over again.

00:15:54 Maybe we have hundreds of users on our system and they're calling the same services multiple

times per minute and that's a lot of overhead to have to continually re-read that metadata.

00:16:04 If you do have that sort of design scenario, if you know you have that condition and you want to

avoid that overhead, we also have the ability to prebuild a JavaScript library with the entity

definition.

00:16:23 Now, this has the disadvantage that when you change the underlying entity definition, it can't be

dynamic. If you do. $ importEntity, that's always going to be dynamic. You can go change the

HDBDD file

00:16:35 and then run your service - it's going to pick up new change columns right away. But it comes

with that performance overhead of having to read that metadata every time.

00:16:44 On the other hand, we can pre-generate, and that creates an XS JS lib, that we can import into

our project, into our content and then we can directly access that entity. We can create an

instance of that entity

00:17:01 simply by referencing the entity as part of that imported library and not having to call the $

importEntity of the XSDS library itself.

00:17:13 Now, we talked about, from a high level, the Entity Manager, and we've seen what we can do

there with the import entity. But there are also other capabilities that we have here. We have the

Query Builder that we're going to see a little bit later.

00:17:26 But we also have the ability to access those instances of those objects in both a managed and

an unmanaged approach. So, let's take a look at what we mean by each of those two

approaches.

00:17:41 So, first the managed entity, and this is probably the most common way that you would work

particularly when you want transactionality and you're using a base of CDS-based artifacts.

00:17:56 What we have here is, for instance, we import the entity definition, that's our post, and then

when we want to get a particular instance of the object, we don't write "select from post where

pid = 101"

22

00:18:15 we instead use the managed functions, so in this case, $ get. And then we pass in the key for

that.

00:18:23 The XSDS library itself will, of course, generate the necessary SQL statements behind the

scenes, it keeps you from having to mess around with the underlying SQL.

00:18:35 What this means is that you're not building a query string, you're not working with a query object

or the database interface.

00:18:45 Your object itself is a plain JavaScript object. And it means that you can do things like increment

a property, the post.Rating++.

00:18:57 It means that you can embed commands, you can embed the get command inside of another

command.

00:19:04 So it's treated exactly like a pure JavaScript concept at this point. And it really means that you

stick with pure JavaScript concepts.

00:19:17 It also means that, when we talk about transactionality, we get the ability to build up our

transaction

00:19:23 using JavaScript concepts. Here you can see we used $ save to then explicitly write those

changes in the database. So everything up to that point is just working with JavaScript

properties, JavaScript objects.

00:19:35 Maybe I'm just inserting another record into a JavaScript object and it's not until you do the save

that the actual transactions are written into the database.

00:19:44 That really allows you to manipulate your data, to write your transactional logic as you think, as

a person thinks, and not have to worry about a lot of roundtrips to and from the database.

00:20:00 It will batch up the operations in the transaction and only send them all to the database upon the

save command. Now, this gives us the ability to access the managed instance in a couple of

different ways.

00:20:16 We can retrieve by key, that's what the $ get command allows us to do. We can then directly

update an instance, so you can just set a property, that's all the columns in the underlying table

00:20:30 then show up as properties on the object instance. We can just set, for instance, here

Author.Name = "Alice" and then we want to write that back into the database, so that's just $

save.

00:20:40 Likewise, you can create a new instance of the object simply by saying new of the object that

you've already imported. And then you pass in, via a constructor, the base values.

00:20:54 Or you can set them later just like you would when you're updating an instance. It's just

properties, and because that object, when it's imported, has all the properties representing all

the columns in the underlying entity,

00:21:06 you have no problem being able to work with it in either way. And then finally, if you want to

delete an instance after you've got an instance of a particular object,

23

00:21:15 you just say discard, and that will create a delete SQL statement and process that in the

database. So, some of the advantages and disadvantages of doing this managed approach with

instance management.

00:21:31 Well, some of the facts are that each of the instances is basically a singleton object. And it has

personality, that means it has associated functions directly on it.

00:21:41 So it's the instance of the object that you call that get function of or you call the save function or

the discard function.

00:21:50 So, it's a different way of programming than if you're used to pure SQL statements, of course.

All the associated instances are then stored by reference.

00:22:01 So when you do have an association, you have a parent record and you have multiple child

records, we don't store that data multiple times. We have one set of the child data

00:22:12 and then it's linked by reference, so it's not copy by value, it's access by reference not by value.

So, the upsides to this approach, well it means you get a single consistent view

00:22:27 and a single consistent way of working with each instance of a particular object. And we get this

automatic processing of associations.

00:22:36 So when you do have an association, you do a get on the parent object. You're just going to get

in your resulting object, if you were to look at it as JSON, you would see a subobject.

00:22:46 Whatever queries are necessary to read, to join, to read the child objects, it's all generated for

you behind the scenes, you just read the parent object and you're going to get all the child

objects automatically loaded.

00:23:00 So, that's quite beneficial. On the other hand, like with anything, there is overhead. Whenever

you have something being managed for you by the system

00:23:10 you have metadata being preloaded, you have associations automatically being processed.

There's a lot of overhead and you don't necessarily have control over that.

00:23:20 Your ability to limit that or highly optimize in a mass processing scenario is probably not that

great using this approach. The other downside is you have a limited subset of database

commands.

00:23:33 So, we're really focusing on transactionality here, the 80% rule that 20% of the functionality is

used 80% of the time. And that's what you're going to find in this managed approach.

00:23:47 So really good for lower-volume data scenarios and, of course, transactionality but not

necessarily what you want if you want to write complex queries

00:23:58 with all kinds of ranges of SQL processing embedding case statements, and if, and calculations

and stuff like that inside your resulting SQL statement. Also probably not the best approach, as I

said, if you have mass data processing.

00:24:14 But as you see here, this consistent instance view, very beneficial to when we are processing

transactionality. Allows us to update a property directly, like in this case in the child object in the

way we persist.

24

00:24:27 The data is consistently written into the correct database tables. You don't have to worry about

what tables are involved, how to link them.

00:24:34 Is the child object being updated or deleted when the parent object is being processed? The

library takes care of all that for you.

00:24:45 And of course, as I said, when it comes to database and transaction handling it's really quite

useful here. It means that we have automatic cache,

00:25:00 automatic type conversion, even with this minimal runtime. We try to expose - like I said, it's that

80/20 scenario - as much of the database functionality as possible

00:25:11 but with a minimal feature set. So keep it simple, keep it focused on this particular use case but

still expose a lot of the underlying database functionality.

00:25:20 So very nice, as I said, for single database connections with single transactions. So really well

suited for that. Single-threaded per-process request and also has built-in support for auto

commit,

00:25:35 explicit commits, rollbacks, so everything that you would need for transactionality. It also fully

supports anonymous connections, so we can pass in an XS SQL CC object

00:25:47 and use the user management configured in the XS SQL CC automatically and the connection

for XSDS connections as well. Now, on the other side of this, we want to talk about building

queries as well.

00:26:07 This is where we have the access, we have a Query Builder built in, has full access to the

underlying SQL statements, unlike the managed object instances that we talked about

previously.

00:26:20 Now, before we get into the exact details of that, this slide tries to show you why it's not that

nice to build SQL statements by hand as query strings.

00:26:31 Because it does, it results in a lot of redundant code when you define JOIN statements. You've

already built the JOIN definition in the underlying database entity,

00:26:43 particularly when you're using CDS. Why have to repeat that in each of your SQL statements

that utilize that JOIN. The column names are, we're having hard-code column names, when you

have the string-based query interface.

00:26:58 It's hard to build that up dynamically. Hard to make sure that we have consistent

parameterization of the query parameters.

00:27:08 And it means that the result set has to be processed manually as well. This is sort of talking

about the old database interface as well.

00:27:17 So, we also have this Query Builder interface, it allows us to build ad-hoc queries using a

completely JavaScript approach.

00:27:26 What you see here, instead of building a string and saying select from this particular table

where, and building the where condition and then passing in a value into that parameter string

25

00:27:40 using the question mark and replacing that value, what we see here is a much more JavaScript

way of working. First, we start by importing the entity still, whether that's from the catalog

00:27:50 or whether that's from the CDS. So, nowhere do we hard-code the table name or the schema,

or anything like that.

00:28:00 That's all coming from the entity definition. And then you say, we're doing a query so that tells

the XSDS that we want to drop into the Query Builder interface.

00:28:08 And then there are additional functions for the where condition, and the and condition, and the

or condition. So each of these are JavaScript functions and they take input parameters like any

other JavaScript function.

00:28:20 So here we're able to reference column names but not by hard-coding strings. Once again,

we're getting the columns as properties of the entity definition as well.

00:28:32 And you can imagine, today, of course, the JavaScript compiler can't syntax-check this, it

doesn't know the entity definitions. Moving forward, we can even build a checking of the XSDS

definitions into the syntax check

00:28:47 because it's well-formed JavaScript objects here that can be checked. When we execute the

query, what we get back, this result

00:28:57 like the new database interface, actually uses the new database interface behind the scenes we

get a JavaScript object back.

00:29:04 So we get all the same benefits of using the new database interface as well but with the even

more simplified query interface here.

00:29:12 So, some of the things that this supports. It supports incremental query building so we don't

have to build the whole thing up into a single string.

00:29:20 We still have all the core operators that you expect from SQL syntax: the ability to project,

where, matching, and in many of these cases, it's not like one-to-one syntax with the underlying

SQL syntax.

00:29:34 In many cases, we've simplified the syntax and made it more JavaScript-like as well. At the

same time, we still retain full support for CDS and path navigation via associations

00:29:48 which, of course, plain SQL would not have, and we have a whole expression language based

upon the CDS query language that's built into this API as well.

00:30:00 So, just looking at some examples here, if we want to do a projection with a CDS entity that has

navigation built into it, we get the entity definition,

00:30:11 we perform the query, and then the project is telling it what columns that we want to select. So

we're going to select the author column, and the comments column,

00:30:21 and we can even go into child objects of the entity association. When we execute this, a JSON

object is returned

00:30:31 and like the new database interface, this is a JSON object but here it's a more complex JSON

object.

26

00:30:38 Complex meaning that we have the embedded objects. So, it follows the association paths, it

returns the child entity instances as subobjects in the JSON.

00:30:53 It's a little different than the new HDB database interface. There, even if you're doing a JOIN, it

has to flatten the dataset.

00:31:01 So really the most you can get out of that is a one-level JSON object. Here, with the XSDS

library, we still have the advantage of processing in JSON

00:31:12 but this is even more useful JSON, because when you do have entity associations it doesn't

flatten the dataset, it doesn't repeat the data

00:31:20 it uses the hierarchical nature of JSON to represent those subobjects exactly as they are, as

subobjects in the JSON itself.

00:31:31 At the same time, we can build complex where conditions as well. Here, we see an example of

where, the author ID is equal to a particular value being passed in.

00:31:43 But we have access to all the operators equal, not equal, greater than, less than, like, unlike.

We can even escape into pure SQL.

00:31:54 So, with this prefix operation, we break into pure SQL, and in fact, here we're doing square root.

So we're saying, the square root of this value is greater than 2.

00:32:07 So, this allows us full access to the underlying SQL syntax and let's say, some great new SQL

syntax comes out with the next support package, you still have a way to break into it

00:32:20 and access it maybe even before it's been added as a pure JavaScript function in the Query

Builder interface. We can build templates for matching results as well.

00:32:32 Avoids the very complex SQL statement that you might have to build otherwise to do the same

sort of thing. Also important, we can have incremental query construction.

00:32:46 Often you might build up a base query but then later, as it says here, redefine the query. Add an

additional where condition.

00:32:56 Maybe you have some if checks, you know, you build your base query, you've got some if

checks based upon input parameters, then you add more where conditions.

00:33:03 Instead of just concatenating together a string, here, we have this much more formalized

approach to doing it.

00:33:10 And of course, the actual query in the column of the database doesn't happen until the very end

when you execute that query.

00:33:17 So we can build up the query in multiple parts and we don't have to worry about going back and

forth to the database. We also have the ability to use JSON expressions.

00:33:31 You saw this already in some of the previous examples. How when we use the find, we're using

JSON notation when we have complex input parameters.

27

00:33:42 It allows us to process, once again, in a very JavaScript-like, in a very JavaScript-friendly

approach. So with this optimized query construction, we already talked about this a little bit, but

just to further summarize on this,

00:34:00 it really cuts down on the number of round trips as we are able to build up the query in different

parts different encapsulated logic to build that up.

00:34:10 It allows us to share subqueries so if we have a subquery part that's used in multiple queries we

can define it once, parse it once in the database and then use that prebuilt subquery in multiple

parent queries.

00:34:24 And it allows for just-in-time translation into SQL, including JOIN explosion of the associations

and things like that.

00:34:34 Cuts down on the intermediate processing for those sorts of things. And then finally, one last

part to this library is that is also brings the same sort of capabilities to stored procedures as well.

00:34:48 So very similar to what the new database interface, the HDB database interface now exposes

stored procedures as sort of a proxy function. What you see here is we have the same

capabilities in the XSDS library as well.

00:35:07 It has a procedures library, a sublibrary if you will, that allows you to import a procedure and

then you have access to it as a JavaScript function.

00:35:18 We're able to pass in parameters, get a result set back, that is a JSON result set. Works exactly

the same way as the $ HDB interface does.

00:35:32 That really brings us to the end of Week 2. I hope you have enjoyed this look at the service

interface layer and how much new functionality that we have put into it.

00:35:45 I think we'll continue this just a little bit in next week. Next week, the final week of the course,

Week 3, is a little bit of a grab bag of the leftover topics.

00:35:55 We'll continue a little bit with the service layer as we talk about unit testing. But then we'll also

talk about various other topics including the repository rest API,

00:36:08 the predecessor of the river project and, of course, SAP UI5. So I hope you'll join us again next

week for all those topics.

www.sap.com

© 2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.