openSAPIntroduction to Software Development on SAPHANA

WEEK 3, UNIT 1

00:00:13 Welcome to week three of the introduction to Software Development in SAP HANA. Thisweek we will explore SQLScript. In unit one well do an introduction to SQLScript. Wellexplain what SQLScript is and why you need it. And then in subsequent units in this week,well have lots of exercises where we go into the system and we create various types ofSQLScript procedures.

00:00:39 So lets go into the introduction to SQLScript. First of all, what is SQLScript? Well SQLScriptis SAPs interface for applications to access SAP HANA.

00:00:50 And its really an extension of standard ANSI SQL so we started with basic SQL and all of theANSI SQL statements are compatible with and youre able to execute them from withinSQLScript. Well see that in one of our first examples. Well just write some regular SQLinside of SQLScript. But SQLScript also has additional language features that we wantedadded.

00:01:17 And every database vendor does this, they have their vendor-specific extensions because noone wants to break compatibility with SQL. We dont directly add or change things to SQL; weimplement them in an additional language like SQLScript and then this becomes thelanguage for creating stored procedures in a database.

00:01:39 This is no different than what other major database vendors do with their own implementationof stored procedures. So inside a stored procedure with writing SQLScript, you have theability to have any form of declarative logic, which would mean regular SELECT statements,as well as we can call to all of our built-in calculation engine functions.

00:02:05 Well talk a little bit more about what calculation engine functions are in a moment. You canalso have various forms of orchestration logic, so you can have all your Data DefinitionLanguage, your DDL. So you can create catalog objects. You can have your create tables,your create schemas, and you can combine those all up together into a stored procedure.

00:02:28 You can do various data manipulation, or DML. You can have data assignments and,probably most importantly to making SQLScript a full language that you can write businesslogic in as well, we can have imperative logic like IFs and CASEs and EXCEPTIONs and soforth.

00:02:49 So the main goal for SAP in creating SQLScript was really to allow you to execute as much ofthe data-intensive logic inside the database as possible without having to go back to theapplication server. Theres two ways that SQLScript makes this possible.

This document contains a transcript of an openSAP video lecture. It is provided withoutclaim of reliability. If in doubt, refer to the original recording on open.sap.com.

Page 2 Copyright/Trademark

00:03:10 The first is that it means that you dont have to transfer any data back to the applicationserver that would be an intermediate result. It allows us to have data flow from one SQLstatement to another. In the traditional world, we would have to bring the result of every SQLstatement back to the application server and even if we just wanted to feed that in to the nextSQL statement or join the results of two SQL statements.

00:03:36 You couldnt do it in the database as a single SQL statement, even a complex SQL statementwith an inner join or subquery. But if you go beyond that, and many application developerswill do that, theyll bring the data back to the application server layer even if they could usejoins or subqueries because those are harder to write and harder to read.

00:03:56 Its easier just to do data floats. The way our minds think but its not efficient for computersystems. Well, SQLScript gives you the advantage of being able to write the code in a waythat is very familiar to application developers and is very easy for us to think through theprocess.

00:04:14 But at the same time we can optimize it behind the scenes for the best execution that acomputer system like SAP HANA would have. The other thing where we get benefit is that allyour queries are optimized and analyzed both for parallel execution and also just for generaloptimization.

00:04:39 So you might write the SQL statements as two separate SQL statements and useintermediate results between those two, a very common way for application programmers todo this. Were afraid of using joins or its too complicated to use a join or a subquery so wedwrite it as two simpler SELECT statements.

00:04:59 Certainly more readable that way, easier to maintain, easier to write in the first place, but thennot as efficient for the database if its got to perform one SQL statement, store some results,and go back to the database and get a second set of results.

00:05:14 What SQLScript can do is it can analyze those two statements during compilation and say, Ican combine that down and make that a complex inner join or I can make that a SQLstatement with a subquery. It will do that optimization for you so you dont have to writethose more complex statements.

00:05:33 The other thing that it will do is it will analyze all of your statements and it will see which ofthem can be performed in parallel. It will automatically add in this parallelization to your logic.So as an application programmer you dont have to worry about the technical details of howthe parallelization is happening. You dont have to worry about a threading model, or syncpoints, or anything like that.

00:05:59 You write your code. Now theres a couple of things that you probably want to keep in mindbecause there is certain types of statements and operations that can throw you out of parallelmode so you want to be aware of how the system optimizes for parallelization, but you donthave to really directly code, at least technically, for how the parallelization will happen. This isall done for you by the SQLScript compiler.

00:06:20 This really lets us create applications that fully leverage the power of HANA, like keepinglogic in the database but also by taking advantage of the massively parallel processingcapabilities of SAP HANA. So if we compare this to if you were to just write plain SQLstatements what kind advantage does SQLScript have over that?

Page 3 Copyright/Trademark

00:06:45 Well first of all, in a SQL query, you can only have a single result set. With SQLScript we canhave many exporting parameters. So we can have multiple result sets coming back, whichcan be very advantageous. We can bundle all of our logic up, perform multiple SQLstatements even if they are used/combined together and return all of the result sets back tothe application server layer.

00:07:15 This also means that we can take our logic and break it down into smaller chunks. So thismodularization is something all programmers know, we do this in all types of programming,we like to modularize things. It means its easier to understand, it's easier to maintain. Andprobably more importantly, its easier to reuse things if we have a set interface for the inputsand the outputs, we know what that interface is and all the processing than takes place sortof in that black box inside that interface.

00:07:47 Well thats exactly what we can do with SQLScript. We can have a fixed input set ofparameters and an output set of parameters and really encapsulate the logic that takes placeinside there, as opposed to regular SQL statements where you dont have any method forreusability.

00:08:07 So SQLScript also supports the definition of local variables, intermediate variables to eitherhold single values or hold entire result sets. So in the traditional world where wed have tobring those back to an application server because SQL has no language, no semantics to beable to define intermediate variables.

00:08:27 The only thing we can do is write data into temporary tables or other persistent options like aglobally visible view or something like that to store intermediate results. With SQLScript, thisis just like regular programming. We can declare a variable, it will take on its type when weset values into it from a statement, well see this illustrated quite extensively in our examples.

00:08:56 And this lets us program like were used to instead of having to adapt and as applicationdevelopers program quite differently because we're now down at the database. We wantapplication developers to continue to be able to program as they always have. And thenfinally, SQLScript has control logic, conditional logic, and imperative logic that simply isntavailable as part of SQL.

00:09:23 Regular ANSI SQL is what we would call a declarative language. It does block processing,not single-record processing. SQLScript has the ability to do everything that SQL does butalso switch into imperative logic and single-record processing so we can loop over a resultset and an immediate variable, process one record at a time. We can have IF statements andCASE statements. But as youll see a little bit later that comes at a price, because as soon asyou do introduce imperative logic you can no longer have parallel processing.

00:09:57 So just looking at where SQLScript fits into the overall architecture of an application, weveseen this slide a couple times where weve talked about how the presentation logic executescompletely on the client side.

00:10:11 Then we have control flow logic. This is where we have our service enablement as well asour control flow logic. This would be at an application server layer. We did talk earlier abouthow this application server can collapse down into HANA as well, but this diagram is reallygeneric, meaning that control flow logic is in any application server.

00:10:33 And then finally we have our calculation logic or our data-intensive logic. Weve been talkingall along about how we want to push logic down into the database, about how we want our

Page 4 Copyright/Trademark

data-intensive logic to execute in the database. We havent really said how thats done butthe language for doing that is SQLScript.

00:10:50 Now weve finally reached the point where were ready to talk about how we code that data-intensive logic. And how this compares to the traditional model? In the traditional world whatwed have to do is wed have our business logic, our application logic, our control flow logic,all at an application server. This is usually a completely separate piece of hardware. It has tocommunicate to the database server over the network.

00:11:18 And therefore it would issue SQL statements. So it would issue SQL statement number one,get a result set back. That result set has to move across the network and then be stored atthe application server layer. And then, we make another statement, get another result set,then maybe we merge that result set together or we do some filtering, but basically we have alot of data going back and forth.

00:11:43 We can still program that way, even with SAP HANA. So you can still have your jobapplications, your ABAP applications and they just do SQL statements. HANA is 100% SQLcompatible, ANSI SQL compatible, so its perfectly possible that you can take your existingapplications and do that but youre still going to have a bottleneck there.

00:12:04 If youre moving massive amounts of data across the network back up to your applicationserver layer, as soon as you move that data out of HANA, you lose all benefits of in-memoryprocessing, you lose all benefits of the massively parallel processing that HANA is capableof. So therefore if your company is investing in HANA to get the utmost performance, but youdont do anything to change the architecture of your application and just port the databaseover to HANA, then youre not going to get the full benefits of SAP HANA.

00:12:31 Then the more logic that you do at this application server layer, the less benefit youre goingto get out of HANA. Now, on the other side, when we talk about re-architecting, when we talkabout doing code pushdown, what we mean is using views, and using SQLScript, so that wedont have this back and forth from one statement to another between the database serverand the application server.

00:12:56 We can do the data flow from one statement to another completely inside of HANA so thatdata never has to come back up out of the database. So we only transfer the final record set,which is already merged, already filtered, already sorted, aggregated, and that really is therecord set were probably going to display to the end user. Thats a very small data set andonly it is finally returned to the application server layer.

00:13:23 Now a little bit more about parallelization, so this is what I was talking about withparallelization. In this query we have a select from the product table and then we have aselect from the text table and because both those results are reading from two different tablesand are going into two intermediate variables, those can be processed (in this case its doingan inner join) so this diagram actually shows it being processed as two different queries.

00:13:58 What will probably actually happen behind the scenes is that itll be combined together intoone join condition and what we have listed as query one and query two here on the slide,literally written as two separate queries in the code, will actually compress down into onequery when it executes in the database.

00:14:17 Next, we have query three and four. Here were doing a select count for product text andwere doing another select count for a different WHERE condition So even though were

Page 5 Copyright/Trademark

reading from the same table, theres no dependencies between these. Theres no WHEREconditions where its using variables that are dependent upon each other. Were notcombining the two results together in any way. Therefore, these two can be processedcompletely in parallel.

00:14:45 And you see that shown here in the diagram. Now theres nothing in the coding that we didhere to tell the system to do it in parallel. We didnt have to have a sync point after query fourthat says wait for the completion of query 3 in case it takes longer. We dont have to worryabout any of those things, the SQLScript complier, the internal engine inside of SAP HANAtakes care of all those kinds of details for us.

00:15:08 We can simply write the SQL statements in a way that feels comfortable to us and the systemdoes the optimizations for us. So, some of the rules about parallel processing. The systemwill automatically put all SELECT statements in a procedure and execute them parallellyunless any of the following occur.

00:15:31 So if you use a local scalar parameter or other variables inside that procedure, as soon asyou access those local parameters it kicks us out of parallel mode because we cant bechanging the same variable or parameter potentially at multiple different points. We cantmaintain the order of the operations at that point, we could overwrite the variable or theparameter with an older value just because one of the parallel queries took longer than one ofthe other ones.

00:16:09 If you have any write operation, so if you change your procedure so its a read/writeprocedure and inside there you might set read/write procedures because youre doingcreation operations. So DML or DDL, youre creating a table, youre creating a schema orsomething like that, or youre doing dynamic SQL.

00:16:30 So either of these cases require you to create a read/write procedure, its a little flag we seton the creation of the procedure and those can never be executed in parallel because wecouldnt know what side effects might occur by creating things in parallel.

00:16:47 The other thing that will kick us out of parallel mode is imperative logic. As soon as youintroduce some imperative logic, IF statements, CASE statements, or anything like that, wekick out of parallel mode because such statements are inherently not parallelizable. Theyintentionally process one record at a time.

00:17:07 We need the result of one statement to flow into the next so anytime you have imperativelogic youre kicked out of parallel mode. Obviously as youre building your SQLScriptprocedure, you want to make sure if you can, to put imperative logic at the end of theprocedure, that youve already done all of your data selections at the beginning so that theycan be parallelized.

00:17:29 With imperative logic it does mean we drop out of parallel mode as soon as we hit the firstimperative logic statement. So you can have imperative logic mixed into a procedure withother commands and theyll be parallelized. As soon as you hit your first imperative logicstatement then you kick out of parallel mode and you do not kick back into parallel mode,even if you would have more select statements afterwards that could be parallelized we dontgo back into parallel mode.

00:17:59 If you have that situation, what you want to do is you want to pull that logic out, write it as aseparate procedure and then do an inner call procedure to branch out to a different

Page 6 Copyright/Trademark

procedure that will give the system the ability to re-analyze and see if it can go back intoparallel mode at that point.

00:18:17 And then finally, if you have any SQL statements that are not assigned to a variable. So if youjust issue a SQL statement and you don't move it into a variable or parameter, then that willkick you out of parallel mode as well.

00:18:33 The data types that we have in SQL for the declaration of parameters or intermediatevariables is all based upon the SQL-92 type system. So you dont have to worry about typeconversions as you move data from your SQL statement into your intermediate variables.Everything uses the pure SQL type system. This does mean that when we create parameterswe need to declare types. We can create table types so that they can either be locallyavailable, meaning that theyre specific to one particular procedure, or you can declare globaltable types that can be shared across multiple procedures.

00:19:24 But all youre really defining is the structure you want to use in those import or exportparameters of your stored procedure. Here you see two examples, theres a slight differencein the syntax, two variations in the syntax, we can either say CREATE TABLE TYPE orCREATE TYPE AS TABLE.

00:19:44 Then you just list the columns you want in your table type and their data types according tothe SQL-92 type system. Now in the editor itself, how we can do this. The procedure editor(which well see in the next unit once we start creating some procedures) it has a SQLScripttab where you write the source code, but then it has another tab for Local Table Types andthis is where you put in your CREATE TYPE statements and it will generate types.

00:20:19 These will actually show up as objects in the catalog generated from the procedure itself. Therepository object is a procedure and it contains both the script statements and the table typedefinitions. Therefore you could have multiple catalog objects created from a singleprocedure object in the content repository.

00:20:41 Now the syntax for creating a stored procedure that uses SQLScript is pretty simple. You seehere we say CREATE PROCEDURE. We give the procedure a name, then we list our inputand output parameters or we can have parameters defined as in-out, as they come in we canmake changes to them and then theyll come out as well.

00:21:01 Then you have to specify the language. The default language is SQLScript. There is oneother language that we support for customers to use and that is the R language. R is an opensource language and we have inoperability with this language. You have to install an Rserver separately from your HANA server that allows you to write your R code here in aprocedure.

00:21:30 And we will send that code after checking it to the remote server. Its actually executed overin the remote R server and the result set is returned to HANA. This is really an interfacemechanism to an external system. R is really good for statistical processing and other formsof high-end mathematical calculations.

00:21:53 So if you had those kinds of needs you might want to look at the R scenario. We wont talkabout that extensively. Its a bit of a specialized kind of use case and is well-documented inthe SAP HANA developers guide if you want to learn more about that.

00:22:07 We will focus on SQLScript based procedures throughout this week. Next you have to specify

Page 7 Copyright/Trademark

the SQL security mode. This allows you to specify if you want the procedure to execute asthe person who defined the procedure or the person whos invoking the procedure. Manytimes, you want it to be the person whos invoking the procedure. You want all the commandsthat are inside the procedure to run as the user whos executing them, thats the normalmode.

00:22:40 But sometimes you want commands to be executed that you dont want the person executingthe procedure to have the ability to directly do. You dont want user x,y,z to be able to go to acommand prompt and say Delete table, delete records from table But maybe you do, undercertain business conditions that are controlled, want to allow them to call a procedure thatdeletes data from the table.

00:23:09 And you want to encapsulate additional different controls around it. Thats fine. So you canrun it as the definer, the user who defined the procedure, so run it as SYS_REPO in mostcases when we create procedures in the content repository. Then SYS_REPO is the onlyuser that has to have access to actually delete records.

00:23:31 So someone can call the procedure and have records deleted after the proper checks, butthey cant go directly to the SQL Command Console and issue a DELETE statement.

00:23:41 Next we have the READS SQL DATA, and there we specify if this is a read only or read/writeprocedure. And then we have the WITH RESULT set. WITH RESULT set means that it willcreate a view for the output parameter of the table; therefore, you can issue a SELECTstatement against this procedure. This would cause the SQLScript procedure to act verysimilar to a calculation view, which we saw in the previous week.

00:24:20 So we can define parameters, I showed you here on the left side of the screen you see ascreenshot of the new SQLScript procedure. This is a procedure editor that lets you use theteam provider and a file-based approach to editing. This is the new editor and the one werecommend that you use moving forward.

00:24:45 Inside this editor we have the ability to declare our local table types inside the source codeeditor and then wed simply type or parameters inside parentheses inside a CREATEPROCEDURE statement. There is a legacy editor, and I will show you this in the next unitwhen I go into the system and I create a procedure. Ill do it in the new editor but then I willswitch over to the old editor and show you this as well.

00:25:11 The major difference with the old editor is you cant just type the parameters into an editor.You have to use this form-based tool to say New Parameter and then it will pop up a dialogwhere you fill in the fields and their data types.

00:25:29 And then finally, we need to know how to call a SQLScript procedure and its relativelysimple, its the CALL syntax. So CALL is a statement thats part of regular SQL. Its thesyntax that allows us to call a stored procedure regardless of which language itsimplemented in. So you see here an example here where were calling, we give the schemaname, and then we give the procedure name, and then in parentheses we pass in anyimporting or exporting parameters.

00:26:02 And then it shows you some of the logic executing. We will also do this in the following unitswhen we create a procedure. Well go to the SQL Console to test it. Well have to write aCALL PROCEDURE statement in the SQL Console to execute it. But this is also the syntaxthat you would use if you were calling this via JDBC or ODBC. Well see a little bit later, even

Page 8 Copyright/Trademark

from server-side JavaScript, we use the CALL statement via the SQL interface to executeSQLScript stored procedures.

00:26:38 So in this unit weve given you your first introduction to what SQLScript is. Weve talked alittle bit about why you would use it and some of the interface parameters and how we createthem. In the subsequent units in this week, we will spend creating various types of SQLScriptprocedures, testing them, and even seeing the interactive debugger.

Page 9 Copyright/Trademark

WEEK 3, UNIT 2

00:00:13 This is week three, unit two: Create an SQLScript Procedure with SELECT Statement. In thisunit well go into the HANA system and well see what its like to create a simple SQLScriptprocedure. Well focus on using only SELECT statements or just plain SQL. In subsequentunits, well see how we can add in both CE functions and imperative logic.

00:00:42 So maybe just a little bit of a refresher on some basic SQL and some comments on theSELECT statement. I imagine that many of you, as application developers, are probablyalready very familiar with using basic SQL, and the SELECT statement is the most commonof all SQL statements. For most people, this will probably be very much a refresher, but ithelps to still go over things just a bit.

00:01:08 So were going to be using SELECT statements, and the SELECT statement is without adoubt the most important of all SQL commands, the most widely used. Its how we retrievedata from the database.

00:01:21 And with the statement, you can really create a lot of complex logic. By using the WHEREconditions, the GROUP BY conditions, HAVING, and ORDER BY. All these optionalconditions allow us to control how much data and what data is returned from the query fromthe database.

00:01:42 So the SELECT row should contain the columns that you want returned from the database.So we can say SELECT column 1, column 2 or you can say SELECT count and thensome condition you want it to count. Usually you do COUNT* and that returns any recordsthat meet the rest of the criteria in the following condition.

00:02:11 And then of course you need the FROM, telling the system which table or view that you wantto read from. The WHERE condition gives your main filter criteria to narrow down yourselection. GROUP BY would be when you have summation or any other type of aggregationtaking place. You need to tell the system which columns to use grouping in order to performthat aggregation. The HAVING is your group condition. And then you have the ORDER BY,which would control the sort order on your data as it's being returned.

00:02:46 Now one particular point is that you should never really use SELECT* or SELECT SINGLE*. Ithink this is a good point regardless of which database that you have. Developers have atendency to use SELECT* not because they really need every column in the table, but its abit of a lazy pattern. Its easy just to type the * rather than really name off the columns thatyou use. Some developers will say Well, but it protects you from, maybe in the future, youneed additional columns and then you don't have to change the SELECT statement. But itsvery wasteful, and it's particularly wasteful in any columnar-based database like SAP HANAis. Because when youre performing a SELECT*, even a SELECT SINGLE, it means thatyoure having to move all around the data storage, even if its in-memory, to find the variouspieces of that record and reassemble it. So remember, with columnar-based data, we storeeverything in a single column together. In HANAs case it would be in-memory.

00:03:52 As far as you see here, we have all of the IDs of whatever this number is, then all of thecountries, then all of the product types, and then all of the values. And even if youre doing aSELECT*, that means having to read from one array of memory to find the value 457, andthen having to skip over and read a entirely different array of memory to find the country thatcorresponds to that same record. And then so forth for the additional columns. So a lot ofoverhead to doing a SELECT*, even a SELECT SINGLE*.

Page 10 Copyright/Trademark

00:04:28 And you will find that this is probably the number one thing that hurts performance in aHANA/in-memory columnar-based database. Youre reading a lot of extra data. Its one thingto return that to SQLScript as were talking about here, because at least the data is stayinginside the database, but its a whole another thing to return that data to the application server.

00:04:55 So for more general information about any of the HANA SQL syntax, we really recommendthat you go to help.SAP.com. There we have a guide that will talk you through and guide youthrough additional information on all the Hana basic SQL syntax. Were not going to gothrough all the SQL syntax that you could use in this workshop.

00:05:19 Now lets focus in on creating our stored procedure. We already went to the blocks of thesyntax and what each part means in the CREATE procedure in the preceding unit. The keythat were going to want here to create our first procedure is were going to have to create atable type that has all the columns in it that we want to return from our SELECT statement.

00:05:41 So its got to match our SELECT column list and have all those fields along with their datatype definitions. And then in the CREATE procedure statement in the parentheses that followthe name of the procedure, we have to list our input and output parameters.

00:05:57 So were going to take an input parameter of PartnerRole, and then were going to use thatpartner role to look up all partner records that have that particular role. Then well return a listof the partner information, along with the partner addresses that match that information in anoutput parameter.

00:06:18 Now a little bit on the code that were going to write here. Were going to have a SELECT andwere going to do a JOIN between two tables. Were going to join the businessPartner tableand the addresses table. This is similar to what we did earlier in the attribute view, exceptnow were coding it in SQL and putting it inside a stored procedure.

00:06:39 And then well have the syntax we use to test the stored procedure. Well use the CALLsyntax from the SQL Console, and that will cause the execution of the stored procedure andwell see the returned result set displayed in a tabular format.

00:06:56 So lets go into the system and have a look here at how we could create this procedure. So Iwill go to the Project Explorer and we will use the team provider file-based approach to createour procedures. I will show you within this unit what the old modeler-based editor looks like.The two are still supported and the two are both compatible, so we can edit in one editor andthen switch to the other editor and edit there, but we really recommend the usage of thenewer editor, the source code file-based editor that is here in the Project Explorer.

00:07:46 So I will go to my models and get the name of my procedure that I will be creating. So Ill sayNew >File and Ill just put in the file name. I like to put the name of the procedure as myfilename and then .procedure.

00:08:16 Pretty straightforward. That brings up the procedure editor. Its already inserted a bit of atemplate for us with the CREATE PROCEDURE statement and weve got the name of theprocedure taken from the file name, and it sets certain things by default. It says the languageis SQLScript; thats correct, we want it to be SQLScript. SQL SECURITY is the INVOKER.That means whoever executes this, all the statements inside here will run with their databaseuser security. We could change this if we wanted it to be a DEFINER, but we actually want itto be INVOKER so thats fine. And then we have READS SQL DATA AS, and this is a read-only procedure so were all good there.

Page 11 Copyright/Trademark

00:09:01 So next we need to create a table type that matches our output parameters. So Ill come overhere to the Local Table Types tab and Ill go ahead and just cut and paste in that table type. Iuse the statement CREATE TYPE, give it the name of the type AS TABLE. And then I listeach of the columns that Ill be wanting to return from my SELECT statement and their types.

00:09:31 Now Ill go back to the SQLScript editor and lets get the logic for the procedure. So first of all,I need to insert the parameters so Ill come here to a statement right after we have the nameof the procedure and Ill put in the input parameter. I want an input parameter of partner roleand I can declare its type in line because it's a scalar parameter. If it would be a table inputparameter, then I would have to go to the local table types and then declare another tabletype for it. But for scaler parameters, we can just define those in line in the CREATEPROCEDURE statement.

00:10:14 Then I have my output parameter, thats my bp_addresses, and it uses the typett_bp_addresses, so that is the type we just defined right here.

00:10:25 Now we can go where it says to write your procedure logic and lets just put in our SQLstatement. Here we have our SQL statement. Notice that were saying select various fieldsfrom both A and B, A representing an alias for our business partner table so we dont have towrite this whole long string out every time on each of these columns, and B being an alias forour address table.

00:10:59 Were going to say join the two on the address ID field from both tables. And our WHEREcondition is where a. PartnerRole = and this is our input parameter. We always but a colonon the front of it to denote that that is an input parameter. And then the SELECT statement isbeing sent into the results. The resulting variable is bp_addresses. Were putting it directlyinto the output parameter.

00:11:31 A very simple procedure. Lets go ahead and save it. And we will Activate it. Now lets goover to the HANA Systems view and lets look here in the catalog. And if we look intoSYS_BIC and go under Procedures, well see this procedure has been activated here.Theres a catalog representation of this procedure, so its right here:workshop.sessiona00.models/get_bp_addresses_by_role_sql.

00:12:14 And we would also see the table type get generated as well. So here is the table type thatwas declared via the local table types. Now its local table types meaning that the lifecyclemanagement is managed as part of this procedure. If I change the definition here, itregenerates it. Its actually a global table type from its execution, I mean its here anotherprocedure could reference it. If it did reference it, it would have to give it the full namehowever. When we declare these local table types we really recommend that theyre onlyused inside this procedure, the procedure that theyre declared in, otherwise if one procedurechanges it, it might have a downstream effect and break another procedure. We want to becareful there. You really have reusable types that are going to be shared by multiple tabletypes and you would create those directly as an HDB structure in the content repository andlet that generate directly.

00:13:22 So were ready. We could now go test our procedure. So let me grab the syntax to be able totest this. And then we can do our test from the SQL Console. So the SQL Console lets youexecute any SQL statements. It should really only be used for troubleshooting and testingpurposes, though. Ill go here to the SQL Console, which lets me type in any SQL statementsso I dont have to go write another program to be able to test this procedure. I can test it

Page 12 Copyright/Trademark

directly here in the SQL Console.

00:13:59 Notice the CALL statement, thats the SQL syntax for executing a stored procedure. Then Ihave to give it the catalog location, so the catalog schema SYS_BIC. Everything thatsgenerated, all procedures that are generated in the repository are all in SYS_BIC. Then I giveit the package path, workshop.sessiona.00, and then I actually put this in .models, and hereis my get_bp_addresses_by_role_sql, the name of my procedure. Ill pass in partnerrole = 02and Ill get back bp_addresses. Notice it just points to question mark. That means that its anoutput parameter and well just display it in the SQL Console.

00:14:57 So well go ahead and execute this, and weve got a syntax error, invalid name of function. Imust have mistyped something. Ill just check here real quick. Soworkshop.sessiona.00.models. I should have put in .procedure. Doesnt really matter there,but you see if you do name the procedure wrong what ends up happening. Thats easyenough to fix. I changed it and lets just re-execute it. Now it executes correctly and you seethat were seeing all the business partners that have a partner role of 02 and the rest of thedata is displayed here.

00:15:43 One last thing that I want to show you while Im in here. I told you that there was an oldereditor that was tied to the SAP HANA Systems view, so this is what we would call themodeler procedure editor.

00:15:58 If I were to go to my workshop, workshop > sessiona > 00, and then go to models, I wouldsee there is my procedure and I can pull it up in this procedure editor. Now the majordifference here is that its not using the team provider, its not checking out to a local file. Thisis an online editor. Its locked this object for editing and I can only edit it when Im connectedto the system. The other major difference is that we just see the code block here. So we onlysee the part that occurs between the BEGIN and END. Everything else is actually set viaproperties, so we would look here at the properties of this procedure, then we would see thatthe Schema, the Run With, Invoker's Rights, the Access Mode Read Only, the LanguageSQLScript, these are all properties that have to be set via this Properties tab instead of beingwritten in to the CREATE PROCEDURE header.

00:17:01 The other difference being that the output parameters, instead of defining them in text, wehave this editor here. So I would bring up this form-based editor to be able to maintain thisinformation. But as I said, the two are compatible. I could edit the procedure over here nowand activate it from this tool. You just want to be careful if you do make a change in the oldereditor, and then you go back to this editor, I would come here and add another commenthere.

00:17:53 So Ill go ahead and save this and activate it. Of course, even if I come back here andimmediately try to edit this, it doesnt show that new comment. You do have to, if you make achangeif anyone makes a change with the older editorthen you would have to come hereand youd have to do a Team > Checkout in order to get that change. And now I have thatcomment.

00:18:32 So you do want to be a little bit careful using both the editors in parallel, so I would reallyrecommend that you would focus on the new editor. Eventually, the old editor will be maderead-only for backward compatibility only and everyone should be using the new editor, butweve seen a little bit about how the two do coexist currently in HANA 1.0 SP5.

00:18:54 So in this unit weve seen our first introduction to using the SQLScript editor, weve seen how

Page 13 Copyright/Trademark

we can use basic SQL statements inside our SQLScript stored procedures, and how to testour stored procedures.

Page 14 Copyright/Trademark

WEEK 3, UNIT 3

00:00:13 This is week 3, unit 3, Create an SQLScript Procedure with Calculation Engine Functions. Inthis unit, we're going to compare what we did in the previous unit, which is to createSQLScript procedures using only SQL statements to leveraging calculation engine functionsinstead of SQL statements.

00:00:33 So you might be wondering, what are calculation engine functions? We saw them a little bitearlier in the previous week when we created calculation views. We're going to visit themagain, but this time we're going to spend a little more time talking about what they are andwhy they can be advantageous over using SELECT statements themselves.

00:00:56 Basically, the CE, or the calculation engine, is the main engine that processes all SQLScriptstatements. This is the execution engine for either calculation views or SQLScript-basedstored procedures.

00:01:13 SQLScript itself gets parsed and a lot of processing is done to it. I've already spoken abouthow the statements that you write are not necessarily the statements that get executed. Thecompilation process will break down your statements, combining things together. It will takesimple SQL statements and combine them together into inner joins. It will turn on parallelprocessing, and it does all the determination of when things can be parallelized and whenthey can't, and it will turn on all the sync points. So there's a lot of work that the compiler isdoing. And this compilation all takes place inside the calculation engine. We build acalculation model with a data flow graph, and then the optimizer for the execution of that isin the calculation engine. And the executor for that model takes place inside the calculationengine itself. The calculation engine can talk to the database optimizer, and can talk to thescript execution runtime as well.

00:02:21 It's important to note what's going on inside of HANA. So often, we just issue a SQLstatement or access a view. We're not really aware of what is going on deeply inside ofHANA. But as it turns out, there are several engines inside of HANA. There's a calculationengine. That's where calculation views and SQLScript are executed. Then there's an OLAPengine for analytic processing. That's where analytical views are executed. And then there'sa join engine, and that's where attribute views are processed. And all this is within thecolumn store. There's actually a separate row store engine as well. When you combine inrow-based tables, that processing has to be done over in the row store engine. In addition toall these other engines, we have a SQL optimizer. One of the places where you canpotentially run into less-performant operations than what you might expect is when you haveto transfer control and data between multiple engines. In particular, this is what potentiallyhappens here if you have SQL statements inside SQLScript. They have to be handed off tothe SQL optimizer. But if you can stay inside the calculation engine, then you save that tripover to the SQL optimizer for it to have to do some work.

00:03:52 What we've done is we've taken common SQL statements and we've implemented themdirectly inside the calculation engine so that we don't have to go over to the SQL optimizer.The calculation engine can perform the query and return the results directly. And that's whatwe call CE functions, or CE built-in functions. It's all the same thing. It's all implementationsof standard SQL statements. Not all SQL statements, but many of them that you wouldcommonly use, but implemented directly in the calculation engine.

00:04:28 Here are some examples. We saw some of the syntax of the usage of CE functions earlier,when we did calculation views, because we used the CE functions there as well. In thiscase, we have a CE function, CE_CALC_VIEW; that allows us to read data from a view.

Page 15 Copyright/Trademark

Then we have a CE_COLUMN_TABLE; that allows us to read data from a database table.So there are different operations depending upon if you're reading from a view as opposedto a table. In fact, we'll see in a minute there are even different operations depending on ifyou're reading from an attribute view or an analytic view. So you have to know a little bitmore about which object type you're trying to read from. Of course, with a SELECTstatement, you would just say SELECT FROM and then specify the object name. You don'thave get that specific.

00:05:20 You see here we have CE_PROJECTION. That's where we can supply a WHERE conditionor narrow our field selection. We have the JOIN. This would be similar to writing a JOINstatement between two tables or a view and a table. Finally, we're able to select the resultsfrom the intermediate variable. The results, literally the intermediate variable named result,and put that in an output parameter. We also see how queries can take place in parallel,take advantage of massively parallel processing. But the whole path, the data flow graph, isall handled by the SQLScript processor. But in this case, as opposed to the SQL statementsthat we did in the previous unit, none of the processing has to go over to the SQL optimizer.

00:06:12 Basically, this allows us to, using the CE functions, the CE functions will encapsulate all thedata transformation functionality and keep it inside the calculation engine. You can still useSQL statements, but because the CE functions are implemented directly in the calculationengine, you're going to have the potential to see higher performance, better performancewith the calculation engine functions.

00:06:41 I want to go ahead and take this opportunity to point out: You never want to mix CEfunctions and regular SQL statements in the same procedure. Having that mixture meansyou still have to go back and forth between the engines. In fact, you're going to have totransfer over to one engine and then come back to the other. This is a surefire way to havebad performance. Generally, when customers have escalations, have performanceproblems in HANA, this is one of the most common things. They've mixed SQL and CEfunctions in the same procedure. That's an absolute no-no.

00:07:20 Let's look at some of the common CE functions that you might use, so the equivalents todoing this in SQL. The CE_COLUMN_TABLE is the same as doing a regular SELECTstatement against a database table. The difference being that the CE function does not haveto invoke the SQL processor.

00:07:41 A CE_JOIN would perform a JOIN operation between two tables, and we see theequivalents here. The top part of the example is using the CE_JOIN. Actually, we're doing aCE_JOIN on it_pubs, it_books, and then doing a second one with different criteria. We seethe same thing done via a SELECT statement and a JOIN condition down at the bottom ofthe screen.

00:08:12 The same thing with a PROJECTION, a projection applying a WHERE condition. This issemantically the same as a SELECT statement with a WHERE condition in line in theSELECT statement. So you begin to see a pattern that the syntax isn't all that muchdifferent, but because of the performance benefit, it's worthwhile taking the little extra effort,even though most people are probably already very familiar with the SELECT, the SQLstatements. It's worth it to take the time to learn the CE equivalents and to do the little extracoding that it takes to do those because it will keep you in the calculation engine processor.

00:08:55 This table is really just for your reference. I'm not going to sit here and go through every oneof them, but it's a great table to study. It gives you all the most common SQL statements and

Page 16 Copyright/Trademark

then their equivalent CE functions. I might point out what I mentioned earlier, that if you'redoing a SELECT on a column table, that's CE_COLUMN_TABLE. If you're doing a select onan attribute view, that's CE_JOIN_VIEW, and if you're doing a select on an analytic view,then it would be CE_OLAP_VIEW. You have to direct the calculation engine to which otherengine it needs to interact with, either the join engine, the column engine, or the OLAPengine. So you have to be very aware of what type of objects that you are reading from andinteracting with with the CE functions. It's a little extra added bit of complexity, but onceagain, it's worth it in the potential performance that you could gain by using the calculationengine functions.

00:09:53 So now let's go into the system and let's create another procedure. This time, we'll createone that uses calculation engine functions to do the same thing that we did before usingSQL statements. So I'll come here. This time I'll name it get_bp_addresses_by_role_ce.procedure. I misspelled procedure, so you see the impact of giving a file the wrong fileextension. It didn't open in the correct editor, so right away I knew I had done somethingwrong. That's easy enough to correct. This time I'll actually spell procedure right. There weare. I get the right icon and I get the right editor. So once again, reinforcing the importanceof the file extensions when working with development artifacts in HANA.

00:10:47 So I'll switch over here and I will get my table type. It is the same table type that we usedbefore, so just switching from SQL statements to CE functions doesn't impact the table type,nor does it really impact anything in the header of the procedure, so it's the same input-output parameters, the same additional metadata information that we would put here as faras LANGUAGE, SQL INVOKER, READS SQL DATA ASall the same.

00:11:22 So let's now go and get the logic, though. It is a little bit more verbose than if I would use theSQL statements directly, but here we're going to read from a COLUMN_TABLE,businessPartners, and then we have the PROJECTION on that, so that's where we're goingto supply the WHERE condition. So take our input parameter of partnerrole and feed it intothe PROJECTION. Remember, this is the equivalent of a WHERE condition. And onceagain, it's not as though this is really having to do an operation where it literally reads all therecords and then supplies a filter. What we're really doing here is we're telling the calculationengine, point to this table in memory and then retrieve the records with this WHEREcondition, with this filter condition, and these columns.

00:12:17 And then we're doing the same thing with the address, CE_COLUMN_TABLE, read theaddresses. And then we're doing a JOIN on these two intermediate variables, the lt_bp_projand the lt_address.

00:12:33 So let's go ahead and save this procedure. And I'll activate it. Just so you can kind ofcompare the two, I'll pull them up side by side here in a split screen. You'll notice it is a littlebit more verbose, as I said, but the potential performance benefits should be worth it. Maybegive it a try, break with what feels comfortable, with what feels familiar, and give the CEbuilt-in functions a try.

00:13:11 At this point, I can go ahead over to the SAP systems view and I'll open the SQL Consolehere. There it is, SQL Console. And let's cut and paste the test call,workshop.sessona.00.models. Here we're going to call with the same input parameter value,the partnerrole = 02, and then we'll get our BP addresses back. And we see here, data isreturned. And the thing is, even if we were to say run both of these side by side, we havesuch a small amount of data I doubt you would really see a large difference in the test. Imean, I can go ahead and run them both here.

Page 17 Copyright/Trademark

00:14:16 Let's just put the other call in here as well, sessiona.00.models. We can run both of these atonce and you notice I get both results back. So you can confirm that they are identicalresults. And you do get runtime on both of these, but I have a feeling that we have a smallenough amount of data that it's going to be really hard to compare the runtimes between thetwo. This is an exercise that you can perform in your own system if you are curious, if youhave a larger data set and you're trying to maybe squeeze a little more performance out ofsomething, you could write a procedure both ways and then do as I did here: execute themboth and compare the runtimes.

00:15:10 In this unit, we've had a look at how we can go beyond just using SQL statements inSQLScripts or procedures, use the calculation engine built-in functions, and hopefully you'veseen some of the potential value in using the CE functions.

Page 18 Copyright/Trademark

WEEK 3, UNIT 4

00:00:13 This is week three, unit four, Creating an SQLScript Procedure with Imperative Logic. In theprevious two units, we've seen two different ways to create SQLScript procedures, eitherusing SQL statements or using CE functions. In this unit, we want to expand the scope ofwhat we can use to code SQLScript procedures with, and we'll include imperative logic.

00:00:39 Imperative logic, in general, means that we are processing one record at a time. UnlikeSQL or CE functions that perform bulk operations on an entire record set, this is onevariable or one record at a time. This is probably the kind of syntax that most applicationdevelopers are already extremely familiar with. Just some simple examples before we gointo the system and try this out. In SQLScript, we have IF, ELSE, ENDIF logic. It's verystraightforward. IF, and then you have your Boolean condition, then what lines of operationyou want to take place. ELSEIF, another Boolean expression, and then another THEN, andthen you put multiple lines of execution that you want to take place under that condition.Similar to IF constructs in other languages, maybe syntactically a little different. You'reused to Java or JavaScript or ABAP. The syntax is similar. I think it's easy for most anydeveloper to see it and say, Okay, that's how I do an IF, and adjust their logic accordingly.

00:01:54 We also have WHILE statements, so WHILE, and then a Boolean statement, and then aDO, and then multiple lines of processing, and then your END WHILE. This is one form oflooping construct, and I think most developers are probably familiar with the concept of aWHILE. Similarly, we have a FOR loop, which will iterate over a range of numeric valuesand binds the current value for a variable in ascending order. This is a good way to loopover a result set, for instance, and process one record at a time. Those of you that are usedto other programming languages, iterate over an array. Or in the ABAP environment, thiswould be similar to a LOOP AT internal table kind of processing.

00:02:48 And then we have the CASE statement. Similar to an IF, but it can be a little nicer way towrite an IF statement. So we've shown you a few examples of the different syntax. Let's gointo the system and let's create a SQLScript procedure that has some of this imperativelogic in it.

00:03:12 Once again, I'll come here to the Project Explorer, go back to my project that we've beenworking in, and go to the Models folder. I'll just say New > File and I'll give it the name ofmy procedure: get_product_sale_price.procedure. That opens the procedure editor. Let'sgo ahead and put in our table type. So what we're going to want to dothis is a littledifferent than our other two exampleswe're going to want to ultimately return someproduct informationthe product ID, the product category, the base price, which will comeout of the databaseand then we want to calculate the sales price. Of course, in the SQLstatement, we could do a little bit of math to just calculate a sales price if it was fixed. Butwhat we want to do is we want a different multiplier value to get the sale price, basically adifferent discount percentage, based upon which product category that we're dealing with.This is a fairly common type of business requirement, to adjust prices or any kind ofnumeric value based upon some other criteria. Traditionally, we would have just read all thedata back to the application server and then done this calculation looping over the data atthe application server. But this shows you how even something like this, this is pretty purebusiness logic, can be embedded inside the database and execute here rather than at theapplication server layer.

00:04:53 Let's go back to our CREATE PROCEDURE statement, and I will... in my input parameterswe want to put in a particular product ID, and then we'll output the product sale price tablefor that product ID.

Page 19 Copyright/Trademark

00:05:15 Let's get our source code. You'll notice that there's a bit more source code here, but itprovides some interesting learning opportunities. Let's go ahead and put it in here. First ofall, we have the DECLARE statement. This is not something that we've really seen before.All of our intermediate variables up to this point have been taken from either the result setof a SELECT statement or the result set of a CE function, so they automatically take ontheir data type based upon whatever data is being passed into them. So we didn't need todo any sort of data declaration or type information about that variable before its use. In thiscase, we're going to have some variables, traditional variables, that will be used either as ascalar value to perform part of this calculation in our imperative logic. Therefore we do haveto declare them, and we have to give them a data type. So we're going to declare thislv_category. It's going to be a character field, 40 characters long, and we're going to set itinitially to null. Then we're going to declare a discount and it's going to be a decimal 15,with a scale of 2. We're going to set it initially to zero. We go ahead and we have ourSELECT statement here, where we're going to select the product ID, the category, and theprice for a record from the products table where the product ID is equal to our inputparameter. Likewise, we could have used a CE function at this point. It didn't really matter,performance-wise, for this particular procedure. We're returning, realistically, one recordbecause we're passing it a product ID so that's the unique key of the products table, soreturning one record, it's not going to matter much.

00:07:19 Then we're going to select the category into the lv_category from lt_product. This is a littlebit of an interesting concept. In other programming languages, you would probably take thisresult setor, in this case, it's flat, it's one record, so it's like a structureand you wouldprobably try to access a sub-part of that structure. But everything in SQLScript revolvesaround SQL syntax, so we can perform a SELECT statement even on another variable.That's exactly what we're doing here. We're basically telling it okay, lt_products, singlerecord. Let's get the category field from the lt_product structure and put it into this otherintermediate variable so that we can use it in our imperative logic. That's all that we'redoing here.

00:08:14 Now we have our imperative logic, so simple IF statement, IF lv_category is 'Notebooks',THEN make the discount 20%. If it's 'Handhelds', then it's 25%, and 'Flat screens' 30%.Here we have a LIKE statement, so IF lv_category is LIKE 'Printers,' because we've got acouple different types of printers, so we've wildcarded that value, that comparison, and thediscount is 30%. Any other conditions, so just a simple ELSE statement, then there's nodiscount.

00:08:49 Now we can fill the output structure, the product_sale_price. We'll select the ProductID,the Category, and the Price from lt_product. Once again, we're just taking fields fromthat result set, putting it in the output, but then we're also able to calculate the fourthcolumn, which would be the discount. So we'll take Price, minus, and then we cast theresult of price times our discount, and then we have to say as decimal(15,2) to make surethat it keeps it as a decimal, the right type and length. And then we say as SalePrice. Thatwill make sure that it puts it back into the SalePrice column of our output table.

00:09:39 So you've seen some interesting things going on here, both in the form of usage ofimperative logic, but also how we can read parts of the data, read variables, out of resultsetsin this case, we have to do that because we can't use the result set directly in ourimperative logic. We have to do the SELECT to put it back into another intermediate result.

00:10:04 Let's go ahead and Save. And then Activate. It's successful. Now we can test. I'll go back to

Page 20 Copyright/Trademark

the SQL Console in order to test. Let's get our test procedure, sessiona.00.models, andwe're going to pass in HT-1000, that's a certain product. We'll get the product sale price,and that will be returned in the SQL Console. And here we see that HT-1000. It'snotebooks. The price is $956, but the sale price is $764. Maybe just to compare this, that'sa notebook, let's run this now with some of the other products that we have in ourdatabase. Let's just run this with HT-1002. So now we see that they happen to both benotebooks. Let's just check this real quick. Let's get another record so that we can compareand make sure that our calculation is really working correctly. So let's just browse theproduct table. I did the definition...content...there we are. So let's skip ahead. Okay, HT-1030, that will get us...product category...there we are. So execute both of thosestatements once again, and here we see the result of the notebook with its sale price, andthe result of the flat screen with a greater discount amount. You can see how we can testour SQLScript procedure pretty easily. I hope this has broadened your understanding ofwhat we can do in SQLScript procedures and how we can really begin to move not just ourdata logic, but also begin to take some of our business logic and move it down into thedatabase as well through the usage of imperative logic inside of SQLScript.

Page 21 Copyright/Trademark

WEEK 3, UNIT 5

00:00:13 This is week three, unit five: Using the SQLScript Debugger. So far in this week weve seenhow to build SQLScript procedures. Weve seen various syntax approaches both with SQLstatements, CE functions, and imperative logic.

00:00:31 Of course the more logic that you write down in the database in the form of storedprocedures, the more you need a good tool to be able to debug whats going on. Particularlyas you start writing imperative logic and you have intermediate variables, often in order totroubleshoot, you need to see what are the values of those intermediate variables at runtime.

00:00:52 Well luckily, as of HANA 1.0 SP5, we have a full interactive debugger and thats what weregoing to have a look at in this unit. So because HANA studio is based all on Eclipse, runninginside the Eclipse framework, were able to take the standard Eclipse debugger and use thatfor our SQLScript debugger as well.

00:01:16 The standard Eclipse debugger has several parts to it. Up in the top left-hand corner we havethe Debug Session. This shows us which server were connected to and which debugsession were currently in. In the top right-hand corner, we have our Watch area, that wouldhave a listing of our breakpoints and it would show us all of our variables.

00:01:41 And from there well be able to see values inside those variables as well. And in the bottom,we have the Code so we can see which line of code were currently debugging. Now thereare a couple of steps that you need to go through in order to have the proper debugprivileges.

00:02:00 So basically your user either needs a role that has these privileges or they have to begranted directly to you. So youre going to need some access to the SYS_BIC schema soyoure able to access the privileges themselves and execute them. And then youre going toneed the DEBUG (SYS) procedure with EXECUTE privilege.

00:02:21 So let me show you what this looks like. Ill go to my user ID, go to the Security folder, look atthe user ID that Im using for this workshop, and we actually have it in one of the roles. Wedont have anything directly granted to our user ID, well, with the exception of some systemprivileges that I added that werent in any role.

00:02:47 But everything else is done via the roles and its actually here in the admin workshop_userrole. This is a role I created for everyone doing the exercises in this workshop, so it haseverything you need in order to do the workshop. Most importantly, we have access to theSYS_BIC schema and we have the DEBUG (SYS) authorization. You have to have executeto DEBUG (SYS) procedure. So thats what you would need in order to be able to debugSQLScript procedures.

00:03:28 Now the debugging process is pretty straightforward. You pull up your procedure in theprocedure editor and you can double-click in the area next to the line numbering, and that willset a breakpoint. You can also right mouse click and say Set Breakpoint.

00:03:46 Its important to note that this is one of the reasons why you really want to start to use thenew procedure editor, the file-based procedure editor, because you cannot separate points inthe old editor.

00:03:58 So you remember back a few units ago where I showed you that you could createprocedures and edit them in the new source-code-based file editor that sits as part of your

Page 22 Copyright/Trademark

project in the team provider. Or you can create them in what we call the navigator editor, themodeler editor, and thats over in the SAP Systems view.

00:04:19 Well one of the other major differences that I didnt denote earlier because we hadnt talkedabout debugging yet is that you can only separate points in the new editor. And then onceyou start the debugger, you see...we'll go in the system in a minute and see this, see ourservice code down in the bottom left corner and we see the breakpoints.

00:04:42 So you need to create a debug session first so you would choose the little bug icon and thenchoose Debug Configurations and create a SQLScript procedure configuration. Right nowyou only have to do this once, and theres really no configuration that has to be maintainedfor this, so we dont have to maintain ports or anything like that. Its automatically going touse the SQL connection of the HANA studio. Thats how it connects to the server fordebugging purposes as well. Theres no special debug port or anything like that.

00:05:19 One important point that I should make is that currently, we have a limitation that we cannotdebug procedures that have input parameters. So theres nothing, theres no dialog that willcome up and ask you for the input parameters. Therefore, we often have to write a wrapperprocedure around our existing procedure in order to debug it. Well see this in the exercise.

00:05:48 Now once you start the debugger youll see that the debugger stops on any of your chosenbreakpoints. Another limitation that we currently have is that you cannot single step in thedebugger, you can only jump from one breakpoint to another.

00:06:01 Therefore if you think you might want to see the variables at multiple points in the executionof your procedure, you should set multiple breakpoints in advance. Once the execution doesstop on a particular breakpoint, youll see all the variable display and youll see the values forany scaler variables and youll see the number of rows listed for any table variables. You canthen right mouse click on a table variable and it will open an additional screen that will showyou all the record details that are in that variable.

00:06:37 So lets go back to the HANA studio, go to the Project Explorer, and we want to debug one ofour procedures, but first were going to have to create this wrapper procedure.

00:06:50 So lets say debug wrapper, New > File > debug_wrapper.procedure. Well have no inputor output parameters in this procedure, so theres no types that we have to create. We reallyonly need one line here to call our other procedure, so were going to test our procedure thathas imperative logic in it.

00:07:27 So lets adjust this so it points to our procedure, so sessiona.00.models and were going topass in HT-1000. So lets go ahead and save this and I will Activate. Right, so now we canset a breakpoint here in the wrapper. You always have to set a breakpoint in the wrapperbecause thats actually the procedure were going to execute.

00:08:05 Then lets also go into our get_product_sale_price and set one here, and set one here aswell. And like I said, we can also right mouse click and say Toggle Breakpoint, that would setone as well. So now at this point lets switch to the Debug perspective, if you do not see theDebug perspective up here in the corner of your screen like it is in mine, you can always sayOpen Perspective and choose it from here and that will add it to the window.

00:08:39 So well switch to Debug perspective. We can see our breakpoints set here and we can seeboth of our procedures. Now what you want to do is you want to be sure that you have the

Page 23 Copyright/Trademark

debug wrapper procedure highlighted. If I have this procedure highlighted, if the focus is on itand I try to start the debugger, then its going to fail because this one has input parameters.So it doesnt know which one you want to debug other than which one is the selected tab.

00:09:06 So we will debug with this one. Well come up here to the little bug icon and well say DebugConfigurations, Ive never debugged on this system so the first time I have to create a newdebug configuration so Ill just call this SQLScript. Notice there are no parameters, theresnothing to fill out here in this diagram. Eventually, there will be debug configuration. In afuture revision, well add the ability to execute procedures that have input parameters andwhat youll have to do is have a SQLScript procedure debug configuration. And in this debugconfiguration, youll see the input parameters and youll have to fill in a value and save it aspart of the debug configuration. For now Ill just apply this configuration, Ill say Debug, it willconnect, and its running, and we see that weve already stopped here.

00:10:07 Now theres nothing real interesting to see because were just in the initial part here, so wellsay Resume. That will go to the next breakpoint and already we can see our category isnull. Our discount is 0. We have one record in our LT_PRODUCT right now, and if youwant to see the details of that one row you would say Open Data Preview. It opens downhere and we can see the current values as well, so we can already see what values weregetting there.

00:10:40 So lets go ahead to the next breakpoint. Now we can see which discount has beencalculated, so already were beginning to be able to have enough information to debug andmaybe we saw, Oh, its notebooks, but we have the wrong discount coded in the program. Ishouldnt have 20, I should have something else.

00:11:01 This is a simple example but hopefully it demonstrates to you how powerful the SQLScriptdebugger is, particularly with the ability to look at the data values that are in a tableparameter. And youve seen how you can use this to debug your procedures, which thensupports you being able to write more of your business logic down in the database layer.

2013 SAP AG 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 AG. The

information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors

contain proprietary software components of other software vendors.

National product specifications may vary.

These materials are provided by SAP AG and its affiliated companies

("SAP Group") for informational purposes only, without representation or

warranty of any kind, and SAP Group shall not be liable for errors or

omissions with respect to the materials. The only warranties for SAP

Group 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.

SAP and other SAP products and services mentioned herein as well as

their respective logos are trademarks or registered trademarks of SAP

AG in Germany and other countries.

Please see http://www.sap.com/corporate-en/legal/copyright/index.epx

for additional trademark information and notices.

www.sap.com

openSAP_HANA_1_Week_3_Transcripts - CopyLastPage