openSAP Introduction to Software Development on SAP HANA Week 3, Unit 1 00:00:13 Welcome to week three of the introduction to Software Development in SAP HANA. T his week we will explore SQLScript. In unit one we ll do an introduction to SQLScript. We ll explain what SQLScript is and why you need it. And then in subsequent units in t his week, we ll have lots of exercises where we go into the system and we create various typ es of SQLScript procedures. 00:00:39 So let s go into the introduction to SQLScript. First of all, what is SQLScript? W ell SQLScript is SAP s interface for applications to access SAP HANA. 00:00:50 And it s really an extension of standard ANSI SQL so we started with basic SQL and all of the ANSI SQL statements are compatible with and you re able to execute them from withi n SQLScript. We ll see that in one of our first examples. We ll just write some regula r SQL inside of SQLScript. But SQLScript also has additional language features that we wanted added. 00:01:17 And every database vendor does this, they have their vendor-specific extensions because no one wants to break compatibility with SQL. We don t directly add or change things to SQL; we implement them in an additional language like SQLScript and then this becomes the language for creating stored procedures in a database. 00:01:39 This is no different than what other major database vendors do with their own implementation of stored procedures. So inside a stored procedure with writing S QLScript, you have the ability to have any form of declarative logic, which would mean reg ular SELECT statements, as well as we can call to all of our built-in calculation engine fun ctions. 00:02:05 We ll talk a little bit more about what calculation engine functions are in a mome nt. You can also have various forms of orchestration logic, so you can have all your Data De finition Language, 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 pro cedure. 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 business

logic in as well, we can have imperative logic like IFs and CASEs and EXCEPTIONs and so forth. 00:02:49 So the main goal for SAP in creating SQLScript was really to allow you to execut e as much of the data-intensive logic inside the database as possible without having to go ba ck to the application server. There s two ways that SQLScript makes this possible. 00:03:10 The first is that it means that you don t have to transfer any data back to the application server that would be an intermediate result. It allows us to have data flow from one SQL

statement to another. In the traditional world, we would have to bring the resul t of every SQL statement back to the application server and even if we just wanted to feed that in to the next SQL statement or join the results of two SQL statements. to bring the result of every SQL statement back to the application server and even if we just wanted to feed that in to the next SQL statement or join the results of two SQL statements. 00:03:36 You couldn t do it in the database as a single SQL statement, even a complex SQL s tatement with an inner join or subquery. But if you go beyond that, and many application developers will do that, they ll bring the data back to the application server layer even if they could use joins or subqueries because those are harder to write and harder to read. 00:03:56 It s easier just to do data floats. The way our minds think but it s not efficient f or computer systems. Well, SQLScript gives you the advantage of being able to write the code in a way that is very familiar to application developers and is very easy for us to think through the process. 00:04:14 But at the same time we can optimize it behind the scenes for the best execution that a computer system like SAP HANA would have. The other thing where we get benefit i s that all your queries are optimized and analyzed both for parallel execution and also just for general optimization. 00:04:39 So you might write the SQL statements as two separate SQL statements and use intermediate results between those two, a very common way for application progra mmers to do this. We re afraid of using joins or it s too complicated to use a join or a s ubquery so we d write it as two simpler SELECT statements. 00:04:59 Certainly more readable that way, easier to maintain, easier to write in the fir st place, but then not as efficient for the database if it s got to perform one SQL statement, s tore 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, I can combine that down and make that a complex inner join or I can make that a SQ L statement with a subquery. It will do that optimization for you so you don t have t o write those 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 of them can be performed in parallel. It will automatically add in this paralleliza

tion to your logic. So as an application programmer you don t have to worry about the technical details of how the parallelization is happening. You don t have to worry about a threading model, or sync points, or anything like that. 00:05:59 You write your code. Now there s a couple of things that you probably want to keep in mind because there is certain types of statements and operations that can throw you o ut of parallel mode so you want to be aware of how the system optimizes for paralleliz ation, but you don t have to really directly code, at least technically, for how the parallel ization will happen. This is all done for you by the SQLScript compiler. 00:06:20 This really lets us create applications that fully leverage the power of HANA, l ike keeping logic in the database but also by taking advantage of the massively parallel pro cessing capabilities of SAP HANA. So if we compare this to if you were to just write pla in SQL statements what kind advantage does SQLScript have over that? 00:06:45 Well first of all, in a SQL query, you can only have a single result set. With S QLScript we can have many exporting parameters. So we can have multiple result sets coming back, which Page 2 Copyright/Trademark

can be very advantageous. We can bundle all of our logic up, perform multiple SQ L statements even if they are used/combined together and return all of the result sets back to the application server layer. advantageous. We can bundle all of our logic up, perform multiple SQL statements even if they are used/combined together and return all of the result sets back to the application server layer. 00:07:15 This also means that we can take our logic and break it down into smaller chunks . So this modularization is something all programmers know, we do this in all types of pro gramming, we like to modularize things. It means it s easier to understand, it's easier to m aintain. And probably more importantly, it s easier to reuse things if we have a set interface for the inputs and the outputs, we know what that interface is and all the processing th an takes place sort of in that black box inside that interface. 00:07:47 Well that s exactly what we can do with SQLScript. We can have a fixed input set o f parameters and an output set of parameters and really encapsulate the logic that takes place inside there, as opposed to regular SQL statements where you don t have any method for reusability. 00:08:07 So SQLScript also supports the definition of local variables, intermediate varia bles to either hold single values or hold entire result sets. So in the traditional world where we d have to bring those back to an application server because SQL has no language, no semant ics to be able to define intermediate variables. 00:08:27 The only thing we can do is write data into temporary tables or other persistent options like a globally visible view or something like that to store intermediate results. Wi th SQLScript, this is just like regular programming. We can declare a variable, it will take o n its type when we set values into it from a statement, we ll see this illustrated quite extensive ly in our examples. 00:08:56 And this lets us program like we re used to instead of having to adapt and as appl ication developers program quite differently because we're now down at the database. We want application developers to continue to be able to program as they always have. An d then finally, SQLScript has control logic, conditional logic, and imperative logic th at simply isn t available as part of SQL. 00:09:23

Regular ANSI SQL is what we would call a declarative language. It does block pro cessing, not single-record processing. SQLScript has the ability to do everything that SQL do es but also switch into imperative logic and single-record processing so we can loop over a result set and an immediate variable, process one record at a time. We can have IF statemen ts and CASE statements. But as you ll see a little bit later that comes at a price, becau se as soon as you 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 appl ication, we ve seen this slide a couple times where we ve talked about how the presentation logic executes completely on the client side. 00:10:11 Then we have control flow logic. This is where we have our service enablement as well as our control flow logic. This would be at an application server layer. We did tal k earlier about how this application server can collapse down into HANA as well, but this diagra m is really generic, 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. We ve been talking all along about how we want to push logic down into the database, about how we w ant our data-intensive logic to execute in the database. We haven t really said how that s d one but Page 3 Copyright/Trademark

the language for doing that is SQLScript. e for doing that is SQLScript. 00:10:50 Now we ve finally reached the point where we re ready to talk about how we code that data-intensive logic. And how this compares to the traditional model? In the tra ditional world what we d have to do is we d have our business logic, our application logic, o ur control flow logic, all at an application server. This is usually a completely s eparate piece of hardware. It has to communicate to the database server over the network. 00:11:18 And therefore it would issue SQL statements. So it would issue SQL statement num ber one, get a result set back. That result set has to move across the network and then b e stored at the application server layer. And then, we make another statement, get another r esult set, then maybe we merge that result set together or we do some filtering, but basica lly we have a lot 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 jo b applications, your ABAP applications and they just do SQL statements. HANA is 10 0% SQL compatible, ANSI SQL compatible, so it s perfectly possible that you can take your existing applications and do that but you re still going to have a bottleneck there. 00:12:04 If you re moving massive amounts of data across the network back up to your applic ation server layer, as soon as you move that data out of HANA, you lose all benefits o f in-memory processing, you lose all benefits of the massively parallel processing that HANA is capable of. So therefore if your company is investing in HANA to get the utmost performance, but you don t do anything to change the architecture of your application and just port the database over to HANA, then you re 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 benef it you re going to get out of HANA. Now, on the other side, when we talk about re-architecting, when we talk about doing code pushdown, what we mean is using views, and using SQLScript , so that we don t have this back and forth from one statement to another between the databa se server and the application server. 00:12:56 We can do the data flow from one statement to another completely inside of HANA so that data never has to come back up out of the database. So we only transfer the fina l record set, which is already merged, already filtered, already sorted, aggregated, and that really is the

record set we re probably going to display to the end user. That s a very small data set and only 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 with parallelization. In this query we have a select from the product table and then we have a select from the text table and because both those results are reading from two d ifferent tables and are going into two intermediate variables, those can be processed (in this case it s doing an 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 it ll be combined tog ether into one join condition and what we have listed as query one and query two here on th e slide, literally written as two separate queries in the code, will actually compress do wn into one query when it executes in the database. 00:14:17 Next, we have query three and four. Here we re doing a select count for product te xt and we re doing another select count for a different WHERE condition So even though we r e Page 4 Copyright/Trademark

reading from the same table, there s no dependencies between these. There s no WHERE conditions where it s using variables combining the two results together in ssed completely in parallel. between these. There s no WHERE conditions where it s using variables combining the two results together in ssed completely in parallel. that are dependent upon each other. We re not any way. Therefore, these two can be proce

that are dependent upon each other. We re not any way. Therefore, these two can be proce

00:14:45 And you see that shown here in the diagram. Now there s nothing in the coding that we did here to tell the system to do it in parallel. We didn t have to have a sync point after query four that says wait for the completion of query 3 in case it takes longer . We don t have to worry about any of those things, the SQLScript complier, the internal engine ins ide of SAP HANA takes 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 system does the optimizations for us. So, some of the rules about parallel proce ssing. The system will automatically put all SELECT statements in a procedure and execute t hem parallelly unless any of the following occur. 00:15:31 So if you use a local scalar parameter or other variables inside that procedure, as soon as you access those local parameters it kicks us out of parallel mode because we ca n t be changing the same variable or parameter potentially at multiple different points . We can t maintain the order of the operations at that point, we could overwrite the varia ble or the parameter with an older value just because one of the parallel queries took long er than one of the other ones. 00:16:09 If you have any write operation, so if you change your procedure so it s a read/wr ite procedure and inside there you might set read/write procedures because you re doin g creation operations. So DML or DDL, you re creating a table, you re creating a schem a or something like that, or you re doing dynamic SQL. 00:16:30 So either of these cases require you to create a read/write procedure, it s a litt le flag we set on the creation of the procedure and those can never be executed in parallel bec ause we couldn t 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 s oon as you

introduce some imperative logic, IF statements, CASE statements, or anything lik e that, we kick out of parallel mode because such statements are inherently not paralleliza ble. They intentionally 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 im perative logic you re kicked out of parallel mode. Obviously as you re building your SQLScrip t procedure, you want to make sure if you can, to put imperative logic at the end of the procedure, that you ve already done all of your data selections at the beginning s o that they can be parallelized. 00:17:29 With imperative logic it does mean we drop out of parallel mode as soon as we hi t the first imperative logic statement. So you can have imperative logic mixed into a proced ure with other commands and they ll be parallelized. As soon as you hit your first imperati ve logic statement then you kick out of parallel mode and you do not kick back into paral lel mode, even if you would have more select statements afterwards that could be paralleli zed we don t go back into parallel mode. 00:17:59 If you have that situation, what you want to do is you want to pull that logic o ut, write it as a separate procedure and then do an inner call procedure to branch out to a differ ent Page 5 Copyright/Trademark

procedure that will give the system the ability to re-analyze and see if it can go back into parallel mode at that point. ability to re-analyze and see if it can go back into parallel mode at that point. 00:18:17 And then finally, if you have any SQL statements that are not assigned to a vari able. So if you just issue a SQL statement and you don't move it into a variable or parameter, t hen that will kick you out of parallel mode as well. 00:18:33 The data types that we have in SQL for the declaration of parameters or intermed iate variables is all based upon the SQL-92 type system. So you don t have to worry abo ut type conversions as you move data from your SQL statement into your intermediate vari ables. Everything uses the pure SQL type system. This does mean that when we create par ameters we need to declare types. We can create table types so that they can either be l ocally available, meaning that they re specific to one particular procedure, or you can d eclare global table types that can be shared across multiple procedures. 00:19:24 But all you re really defining is the structure you want to use in those import or export parameters of your stored procedure. Here you see two examples, there s a slight d ifference in the syntax, two variations in the syntax, we can either say CREATE TABLE TYPE or CREATE TYPE AS TABLE. 00:19:44 Then you just list the columns you want in your table type and their data types according to the SQL-92 type system. Now in the editor itself, how we can do this. The proced ure editor (which we ll see in the next unit once we start creating some procedures) it has a SQLScript tab where you write the source code, but then it has another tab for Local Table Types and this 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 procedu re itself. The repository object is a procedure and it contains both the script statements and the table type definitions. Therefore you could have multiple catalog objects created from a single procedure object in the content repository. 00:20:41 Now the syntax for creating a stored procedure that uses SQLScript is pretty sim ple. You see here we say CREATE PROCEDURE. We give the procedure a name, then we list our inp ut and output parameters or we can have parameters defined as in-out, as they come in w

e can make changes to them and then they ll come out as well. 00:21:01 Then you have to specify the language. The default language is SQLScript. There is one other language that we support for customers to use and that is the R language. R is a n open source language and we have inoperability with this language. You have to instal l an R server separately from your HANA server that allows you to write your R code her e in a procedure. 00:21:30 And we will send that code after checking it to the remote server. It s actually e xecuted over in the remote R server and the result set is returned to HANA. This is really an interface mechanism to an external system. R is really good for statistical processing and other forms of 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 won t talk about that extensively. It s a bit of a specialized kind of use case and is well-d ocumented in the 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 the SQL security mode. This allows you to specify if you want the proced ure to Page 6 Copyright/Trademark

execute as the person who defined the procedure or the person who s invoking the procedure. Many times, you want it to be the person who s invoking the procedure. You want all the commands that are inside the procedure to run as the user who s execu ting them, that s the normal mode. who defined the procedure or the person who s invoking the procedure. Many times, you want it to be the person who s invoking the procedure. You want all the commands that are inside the procedure to run as the user who s execu ting them, that s the normal mode. 00:22:40 But sometimes you want commands to be executed that you don t want the person executing the procedure to have the ability to directly do. You don t want user x, y,z to be able to go to a command prompt and say Delete table, delete records from table But maybe you do, under certain business conditions that are controlled, want to all ow them to call a procedure that deletes data from the table. 00:23:09 And you want to encapsulate additional different controls around it. That s fine. So you can run it as the definer, the user who defined the procedure, so run it as SYS_REPO in most cases when we create procedures in the content repository. Then SYS_REPO is the only user 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 chec ks, but they can t 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/write procedure. And then we have the WITH RESULT set. WITH RESULT set means that it w ill create a view for the output parameter of the table; therefore, you can issue a SELECT statement against this procedure. This would cause the SQLScript procedure to ac t very similar 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 yo u see a screenshot of the new SQLScript procedure. This is a procedure editor that lets you use the team provider and a file-based approach to editing. This is the new editor and t he one we recommend that you use moving forward. 00:24:45 Inside this editor we have the ability to declare our local table types inside t he source code editor and then we d simply type or parameters inside parentheses inside a CREATE PROCEDURE statement. There is a legacy editor, and I will show you this in the n ext unit when I go into the system and I create a procedure. I ll do it in the new editor b

ut then I will switch over to the old editor and show you this as well. 00:25:11 The major difference with the old editor is you can t just type the parameters int o an editor. You have to use this form-based tool to say New Parameter and then it will pop u p a dialog where 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 it s relat ively simple, it s the CALL syntax. So CALL is a statement that s part of regular SQL. It s the syntax that allows us to call a stored procedure regardless of which language it s implem ented in. So you see here an example here where we re calling, we give the schema name, and then we give the procedure name, and then in parentheses we pass in any importing or exporting parameters. 00:26:02 And then it shows you some of the logic executing. We will also do this in the following units when we create a procedure. We ll go to the SQL Console to test it. We ll have to wr ite a CALL PROCEDURE statement in the SQL Console to execute it. But this is also the syntax that you would use if you were calling this via JDBC or ODBC. We ll see a little bit la ter, even from server-side JavaScript, we use the CALL statement via the SQL interface to execu te SQLScript Page 7 Copyright/Trademark

stored procedures. 00:26:38 So in this unit we ve given you your first introduction to what SQLScript is. We ve talked a little bit about why you would use it and some of the interface parameters and h ow we create them. In the subsequent units in this week, we will spend creating variou s types of SQLScript procedures, testing them, and even seeing the interactive debugger. Page 8 Copyright/Trademark

Week 3, Unit 2 00:00:13 This is week three, unit two: Create an SQLScript Procedure with SELECT Statemen t. In this unit we ll go into the HANA system and we ll see what it s like to create a simple SQL Script procedure. We ll focus on using only SELECT statements or just plain SQL. In subse quent units, we ll 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 the SELECT statement. I imagine that many of you, as application developers, are pro bably already very familiar with using basic SQL, and the SELECT statement is the most common of all SQL statements. For most people, this will probably be very much a refresher , but it helps to still go over things just a bit. 00:01:08 So we re going to be using SELECT statements, and the SELECT statement is without a doubt the most important of all SQL commands, the most widely used. It s how we retrieve data from the database. 00:01:21 And with the statement, you can really create a lot of complex logic. By using t he WHERE conditions, the GROUP BY conditions, HAVING, and ORDER BY. All these optional co nditions allow us to control how much data and what data is returned from the query from the database. 00:01:42 So the SELECT row should contain the columns that you want returned from the dat abase. So we can say SELECT column 1, column 2 or you can say SELECT count and then some condition you want it to count. Usually you do COUNT* and that returns any recor ds that 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 tha t you want to read from. The WHERE condition gives your main filter criteria to narrow down your selection. GROUP BY would be when you have summation or any other type of aggreg ation taking place. You need to tell the system which columns to use grouping in order to perform that aggregation. The HAVING is your group condition. And then you have the ORDE R 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 S INGLE*. I think this is a good point regardless of which database that you have. Developer s have a tendency to use SELECT* not because they really need every column in the table,

but it s a bit of a lazy pattern. It s easy just to type the * rather than really name off th e columns that you use. Some developers will say Well, but it protects you from, maybe in the fu ture, you need additional columns and then you don't have to change the SELECT statement. B ut it s very wasteful, and it's particularly wasteful in any columnar-based database lik e SAP HANA is. Because when you re performing a SELECT*, even a SELECT SINGLE, it means that you re having to move all around the data storage, even if it s in-memory, to find the va rious pieces of that record and reassemble it. So remember, with columnar-based data, we stor e everything in a single column together. In HANA s 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 the countries, then all of the product types, and then all of the values. And even i f you re doing a SELECT*, that means having to read from one array of memory to find the value 457, and then having to skip over and read a entirely different array of memory to find t he country Page 9 Copyright/Trademark

that corresponds to that same record. And then so forth for the additional colum ns. So a lot of overhead to doing a SELECT*, even a SELECT SINGLE*. columns. So a lot of overhead to doing a SELECT*, even a SELECT SINGLE*. 00:04:28 And you will find that this is probably the number one thing that hurts performa nce in a HANA/in-memory columnar-based database. You re reading a lot of extra data. It s one thing to return that to SQLScript as we re talking about here, because at least th e data is staying inside the database, but it s 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 reco mmend that you go to help.SAP.com. There we have a guide that will talk you through an d guide you through additional information on all the Hana basic SQL syntax. We re not going t o go through all the SQL syntax that you could use in this workshop. 00:05:19 Now let s focus in on creating our stored procedure. We already went to the blocks of the syntax and what each part means in the CREATE procedure in the preceding unit. T he key that we re going to want here to create our first procedure is we re going to have t o create a table type that has all the columns in it that we want to return from our SELE CT statement. 00:05:41 So it s got to match our SELECT column list and have all those fields along with t heir data type definitions. And then in the CREATE procedure statement in the parentheses that follow the name of the procedure, we have to list our input and output parameter s. 00:05:57 So we re going to take an input parameter of PartnerRole, and then we re going to us e that partner role to look up all partner records that have that particular role. Then we ll return a list of the partner information, along with the partner addresses that match tha t information in an output parameter. 00:06:18 Now a little bit on the code that we re going to write here. We re going to have a S ELECT and we re going to do a JOIN between two tables. We re going to join the businessPar tner table and the addresses table. This is similar to what we did earlier in the att ribute view, except now we re coding it in SQL and putting it inside a stored procedure. 00:06:39 And then we ll have the syntax we use to test the stored procedure. We ll use the CA

LL syntax from the SQL Console, and that will cause the execution of the stored pro cedure and we ll see the returned result set displayed in a tabular format. 00:06:56 So let s go into the system and have a look here at how we could create this proce dure. So I will go to the Project Explorer and we will use the team provider file-based app roach to create our procedures. I will show you within this unit what the old modeler-bas ed editor looks like. The two are still supported and the two are both compatible, so we c an edit in one editor and then switch to the other editor and edit there, but we really rec ommend the usage of the newer 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 creati ng. So I ll say New >File and I ll just put in the file name. I like to put the name of the procedu re as my filename and then .procedure. 00:08:16 Pretty straightforward. That brings up the procedure editor. It s already inserted a bit of a template for us with the CREATE PROCEDURE statement and we ve got the name of the Page 10 Copyright/Trademark

procedure taken from the file name, and it sets certain things by default. It sa ys the language is SQLScript; that s correct, we want it to be SQLScript. SQL SECURITY is the INVOKER. That means whoever executes this, all the statements inside here will r un with their database user security. We could change this if we wanted it to be a DEFIN ER, but we actually want it to be INVOKER so that s fine. And then we have READS SQL DATA AS, and this is a read-only procedure so we re all good there. taken from the file name, and it sets certain things by default. It says the language is SQLScript; that s correct, we want it to be SQLScript. SQL SECURITY is the INVOKER. That means whoever executes this, all the statements inside here will r un with their database user security. We could change this if we wanted it to be a DEFIN ER, but we actually want it to be INVOKER so that s fine. And then we have READS SQL DATA AS, and this is a read-only procedure so we re all good there. 00:09:01 So next we need to create a table type that matches our output parameters. So I ll come over here to the Local Table Types tab and I ll go ahead and just cut and paste in that table type. I use the statement CREATE TYPE, give it the name of the type AS TABLE. An d then I list each of the columns that I ll be wanting to return from my SELECT statement and th eir types. 00:09:31 Now I ll go back to the SQLScript editor and let s get the logic for the procedure. So first of all, I need to insert the parameters so I ll come here to a statement right after we have the name of the procedure and I ll put in the input parameter. I want an input paramet er of partner role and I can declare its type in line because it's a scalar parameter. If it would be a table input parameter, then I would have to go to the local table types and then declare another table type for it. But for scaler parameters, we can just define those i n line in the CREATE PROCEDURE statement. 00:10:14 Then I have my output parameter, that s my bp_addresses, and it uses the type tt_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 let s just put in our SQL statement. Here we have our SQL statement. Notice that we re saying select various fields from both A and B, A representing an alias for our business partner table so we don t have to write this whole long string out every time on each of these columns, and B b eing an alias for our address table.

00:10:59 We re going to say join the two on the address ID field from both tables. And our WHERE condition is where a. PartnerRole = and this is our input parameter. We always but a colon on the front of it to denote that that is an input parameter. And then the SELEC T statement is being sent into the results. The resulting variable is bp_addresses. We re putt ing it directly into the output parameter. 00:11:31 A very simple procedure. Let s go ahead and save it. And we will Activate it. Now let s go over to the HANA Systems view and let s look here in the catalog. And if we look i nto SYS_BIC and go under Procedures, we ll see this procedure has been activated here. There s a catalog representation of this procedure, so it s 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 that was declared via the local table types. Now it s local table types meaning that the lifecycle management is managed as part of this procedure. If I change the definition here , it regenerates it. It s actually a global table type from its execution, I mean it s he re another procedure could reference it. If it did reference it, it would have to give it t he full name however. When we declare these local table types we really recommend that they re only used inside this procedure, the procedure that they re declared in, otherwise if o ne procedure changes it, it might have a downstream effect and break another proced ure. We want to be careful there. You really have reusable types that are going to be sh ared by multiple table types and you would create those directly as an HDB structure in the content Page 11 Copyright/Trademark

repository and let that generate directly. 00:13:22 So we re ready. We could now go test our procedure. So let me grab the syntax to b e able to test this. And then we can do our test from the SQL Console. So the SQL Console lets you execute any SQL statements. It should really only be used for troubleshooting an d testing purposes, though. I ll go here to the SQL Console, which lets me type in any SQL s tatements so I don t have to go write another program to be able to test this procedure. I c an test it directly here in the SQL Console. 00:13:59 Notice the CALL statement, that s the SQL syntax for executing a stored procedure. Then I have to give it the catalog location, so the catalog schema SYS_BIC. Everything that s generated, all procedures that are generated in the repository are all in SYS_BI C. Then I give it the package path, workshop.sessiona.00, and then I actually put this in .mode ls, and here is my get_bp_addresses_by_role_sql, the name of my procedure. I ll pass in partner role = 02 and I ll get back bp_addresses. Notice it just points to question mark. That means that it s an output parameter and we ll just display it in the SQL Console. 00:14:57 So we ll go ahead and execute this, and we ve got a syntax error, invalid name of fu nction. I must have mistyped something. I ll just check here real quick. So workshop.sessiona.00.models. I should have put in .procedure. Doesn t really matte r there, but you see if you do name the procedure wrong what ends up happening. That s easy enough to fix. I changed it and lets just re-execute it. Now it executes correct ly and you see that we re seeing all the business partners that have a partner role of 02 and the rest of the data is displayed here. 00:15:43 One last thing that I want to show you while I m in here. I told you that there wa s an older editor that was tied to the SAP HANA Systems view, so this is what we would call the modeler procedure editor. 00:15:58 If I were to go to my workshop, workshop > sessiona > 00, and then go to models, I would see there is my procedure and I can pull it up in this procedure editor. Now the major difference here is that it s not using the team provider, it s not checking out to a local file. This is an online editor. It s locked this object for editing and I can only edit it when I m connected to the system. The other major difference is that we just see the code block here. So we only see the part that occurs between the BEGIN and END. Everything else i

s actually set via properties, so we would look here at the properties of this procedure, t hen we would see that the Schema, the Run With, Invoker's Rights, the Access Mode Read Only, the Language SQLScript, these are all properties that have to be set via this Proper ties tab instead of being written in to the CREATE PROCEDURE header. 00:17:01 The other difference being that the output parameters, instead of defining them in text, we have this editor here. So I would bring up this form-based editor to be able to maintain this information. But as I said, the two are compatible. I could edit the procedure o ver here now and activate it from this tool. You just want to be careful if you do make a cha nge in the older editor, and then you go back to this editor, I would come here and add ano ther comment here. 00:17:53 So I ll go ahead and save this and activate it. Of course, even if I come back her e and immediately try to edit this, it doesn t show that new comment. You do have to, if you make a change if anyone makes a change with the older editor then you would have to come here and you d have to do a Team > Checkout in order to get that change. And now I have that comment. Page 12 Copyright/Trademark

00:18:32 So you do want to be a little bit careful using both the editors in parallel, so I would really recommend that you would focus on the new editor. Eventually, the old editor wil l be made read-only for backward compatibility only and everyone should be using the new e ditor, but we ve seen a little bit about how the two do coexist currently in HANA 1.0 SP5. 00:18:54 So in this unit we ve seen our first introduction to using the SQLScript editor, w e ve seen how we can use basic SQL statements inside our SQLScript stored procedures, and how to test our stored procedures. Page 13 Copyright/Trademark

Week 3, Unit 3 00:00:13 This is week 3, unit 3, Create an SQLScript Procedure with Calculation Engine Fu nctions. In this unit, we're going to compare what we did in the previous unit, which is to create SQLScript procedures using only SQL statements to leveraging calculation engine functions instead of SQL statements. 00:00:33 So you might be wondering, what are calculation engine functions? We saw them a little bit earlier in the previous week when we created calculation views. We're going to v isit them again, but this time we're going to spend a little more time talking about what they are and why 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 SQLScript statements. This is the execution engine for either calculation views or SQLScri pt-based stored procedures. 00:01:13 SQLScript itself gets parsed and a lot of processing is done to it. I've already spoken about how the statements that you write are not necessarily the statements that get ex ecuted. The compilation process will break down your statements, combining things togeth er. It will take simple SQL statements and combine them together into inner joins. It w ill turn on parallel processing, and it does all the determination of when things can be par allelized and when they can't, and it will turn on all the sync points. So there's a lot of wo rk that the compiler is doing. And this compilation all takes place inside the calculation e ngine. We build a calculation model with a data flow graph, and then the optimizer for the execution of that is in the calculation engine. And the executor for that model takes plac e inside the calculation engine itself. The calculation engine can talk to the database optim izer, and can talk to the script 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 SQL statement or access a view. We're not really aware of what is going on deeply in side of HANA. But as it turns out, there are several engines inside of HANA. There's a c alculation engine. That's where calculation views and SQLScript are executed. Then there's an OLAP engine for analytic processing. That's where analytical views are executed. And then there's a join engine, and that's where attribute views are processed. And all this is w ithin the

column store. There's actually a separate row store engine as well. When you com bine in row-based tables, that processing has to be done over in the row store engine. I n addition to all these other engines, we have a SQL optimizer. One of the places where you can potentially run into less-performant operations than what you might expect is wh en you have to transfer control and data between multiple engines. In particular, this is what potentially happens here if you have SQL statements inside SQLScript. They have to be handed off to the SQL optimizer. But if you can stay inside the calculation engi ne, then you save that trip over 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 them directly inside the calculation engine so that we don't have to go over to the S QL optimizer. The calculation engine can perform the query and return the results directly. An d that's what we call CE functions, or CE built-in functions. It's all the same thing. It 's all implementations of standard SQL statements. Not all SQL statements, but many of them that you would commonly use, but implemented directly in the calculation engine. Page 14 Copyright/Trademark

00:04:28 Here are some examples. We saw some of the syntax of the usage of CE functions e arlier, when we did calculation views, because we used the CE functions there as well. I n this case, we have a CE function, CE_CALC_VIEW; that allows us to read data from a vi ew. 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 opposed to a table. In fact, we'll see in a minute there are even different operations depend ing on if you're reading from an attribute view or an analytic view. So you have to know a little bit more about which object type you're trying to read from. Of course, with a SELEC T statement, you would just say SELECT FROM and then specify the object name. You don't have get that specific. 00:05:20 You see here we have CE_PROJECTION. That's where we can supply a WHERE condition or narrow our field selection. We have the JOIN. This would be similar to writing a JOIN statement between two tables or a view and a table. Finally, we're able to selec t the results from 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 plac e in parallel, take advantage of massively parallel processing. But the whole path, t he data flow graph, is all handled by the SQLScript processor. But in this case, as opposed t o the SQL statements that we did in the previous unit, none of the processing has to go ov er to the SQL optimizer. 00:06:12 Basically, this allows us to, using the CE functions, the CE functions will enca psulate all the data transformation functionality and keep it inside the calculation engine. You can still use SQL statements, but because the CE functions are implemented directly in the cal culation engine, you're going to have the potential to see higher performance, better per formance with the calculation engine functions. 00:06:41 I want to go ahead and take this opportunity to point out: You never want to mix CE functions and regular SQL statements in the same procedure. Having that mixture means you still have to go back and forth between the engines. In fact, you're going t o have to transfer over to one engine and then come back to the other. This is a surefire way to have bad performance. Generally, when customers have escalations, have performance problems in HANA, this is one of the most common things. They've mixed SQL and C

E functions 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 equival ents to doing this in SQL. The CE_COLUMN_TABLE is the same as doing a regular SELECT sta tement against a database table. The difference being that the CE function does not hav e to invoke the SQL processor. 00:07:41 A CE_JOIN would perform a JOIN operation between two tables, and we see the equivalents here. The top part of the example is using the CE_JOIN. Actually, we 're doing a CE_JOIN on it_pubs, it_books, and then doing a second one with different criteri a. We see the same thing done via a SELECT statement and a JOIN condition down at the bott om of the screen. 00:08:12 The same thing with a PROJECTION, a projection applying a WHERE conditi on. This is semantically the same as a SELECT statement with a WHERE condition in line in th e SELECT statement. So you begin to see a pattern that the syntax isn't all that much dif ferent, but because of the performance benefit, it's worthwhile taking the little extra effo rt, even though most people are probably already very familiar with the SELECT, the SQL Page 15 Copyright/Trademark

statements. It's worth it to take the time to learn the CE equivalents and to do the little extra coding that it takes to do those because it will keep you in the calculati on engine processor. to learn the CE equivalents and to do the little extra coding that it takes to do those because it will keep you in the calculati on engine processor. 00:08:55 This table is really just for your reference. I'm not going to sit here and go t hrough every one of them, but it's a great table to study. It gives you all the most common S QL statements and then their equivalent CE functions. I might point out what I ment ioned earlier, that if you're doing a SELECT on a column table, that's CE_COLUMN_TABLE . If you're doing a select on an attribute view, that's CE_JOIN_VIEW, and if you're d oing a select on an analytic view, then it would be CE_OLAP_VIEW. You have to direct th e calculation engine to which other engine it needs to interact with, either the j oin engine, the column engine, or the OLAP engine. So you have to be very aware of what type of objects that you are reading from and interacting with with the CE functions. It 's a little extra added bit of complexity, but once again, it's worth it in the potential pe rformance that you could gain by using the calculation engine functions. 00:09:53 So now let's go into the system and let's create another procedure. This time, w e'll create one that uses calculation engine functions to do the same thing that we did befo re using SQL statements. So I'll come here. This time I'll name it get_bp_addresses_by_ro le_ce. procedure. I misspelled procedure, so you see the impact of giving a file the wr ong file extension. It didn't open in the correct editor, so right away I knew I had done something wrong. That's easy enough to correct. This time I'll actually spell procedure ri ght. There we are. I get the right icon and I get the right editor. So once again, reinforcing the importance of 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 used before, 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 far as LANGUAGE, SQL INVOKER, READS SQL DATA AS all 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 the SQL 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 going to supply the WHERE condition. So take our input parameter of partnerrole and fe ed it into the PROJECTION. Remember, this is the equivalent of a WHERE condition. And once again, it's not as though this is really having to do an operation where it literally r eads all the records and then supplies a filter. What we're really doing here is we're tellin g the calculation engine, point to this table in memory and then retrieve the records with this WHERE condition, 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 the addresses. And then we're doing a JOIN on these two intermediate variables, the lt_bp_proj and 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 of compare the two, I'll pull them up side by side here in a split screen. You'll n otice it is a little bit more verbose, as I said, but the potential performance benefits shoul d be worth it. Maybe give it a try, break with what feels comfortable, with what feels familiar , and give the CE built-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 Console Page 16 Copyright/Trademark

here. 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 paramet er value, the partnerrole = 02, and then we'll get our BP addresses back. And we se e here, data is returned. And the thing is, even if we were to say run both of these sid e by side, we have such a small amount of data I doubt you would really see a large difference in the test. I mean, I can go ahead and run them both here. the test call, workshop.sessona.00.models. Here we're going to call with the same input paramet er value, the partnerrole = 02, and then we'll get our BP addresses back. And we se e here, data is returned. And the thing is, even if we were to say run both of these sid e by side, we have such a small amount of data I doubt you would really see a large difference in the test. I mean, I can go ahead and run them both here. 00:14:16 Let's just put the other call in here as well, sessiona.00.models. We can run bo th of these at once and you notice I get both results back. So you can confirm that they are id entical results. And you do get runtime on both of these, but I have a feeling that we h ave a small enough amount of data that it's going to be really hard to compare the runtimes between the two. This is an exercise that you can perform in your own system if you are curious, if you have a larger data set and you're trying to maybe squeeze a little more perf ormance out of something, you could write a procedure both ways and then do as I did her e: execute them both 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 in SQLScripts or procedures, use the calculation engine built-in functions, and hop efully you've seen some of the potential value in using the CE functions. Page 17 Copyright/Trademark

Week 3, Unit 4 00:00:13 This is week three, unit four, Creating an SQLScript Procedure with Imperative L ogic. In the previous two units, we've seen two different ways to create SQLScript procedures , either using SQL statements or using CE functions. In this unit, we want to expand the scope of what 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. Unlike SQL or CE functions that perform bulk operations on an entire record set, this i s one variable or one record at a time. This is probably the kind of syntax that most application developers are already extremely familiar with. Just some simple examples before we go into the system and try this out. In SQLScript, we have IF, ELSE, ENDIF logic. I t's very straightforward. IF, and then you have your Boolean condition, then what lines o f operation you want to take place. ELSEIF, another Boolean expression, and then a nother THEN, and then you put multiple lines of execution that you want to take place u nder that condition. Similar to IF constructs in other languages, maybe syntactically a li ttle different. You're used to Java or JavaScript or ABAP. The syntax is similar. I think it's e asy for most any developer to see it and say, Okay, that's how I do an IF , and adjust their log ic accordingly. 00:01:54 We also have WHILE statements, so WHILE, and then a Boolean statement, and then a DO, and then multiple lines of processing, and then your END WHILE. This is one form of looping construct, and I think most developers are probably familiar with the co ncept of a WHILE. Similarly, we have a FOR loop, which will iterate over a range of numeric values and binds the current value for a variable in ascending order. This is a good wa y to loop over a result set, for instance, and process one record at a time. Those of you that are used to other programming languages, iterate over an array. Or in the ABAP envir onment, this would 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 ni cer way to write an IF statement. So we've shown you a few examples of the different syntax . Let's go into the system and let's create a SQLScript procedure that has some of this imp erative logic in it.

00:03:12 Once again, I'll come here to the Project Explorer, go back to my project that w e've been working in, and go to the Models folder. I'll just say New > File and I'll give i t the name of my procedure: get_product_sale_price.procedure. That opens the procedure editor. Let's go ahead and put in our table type. So what we're going to want to do this is a li ttle different than our other two examples we're going to want to ultimately return som e product information the product ID, the product category, the base price, which wi ll come out of the database and then we want to calculate the sales price. Of course, in the SQL statement, we could do a little bit of math to just calculate a sales pr ice if it was fixed. But what we want to do is we want a different multiplier value to get the sale price, basically a different discount percentage, based upon which product category tha t we're dealing with. This is a fairly common type of business requirement, to adjust pr ices or any kind of numeric value based upon some other criteria. Traditionally, we would ha ve just read all the data back to the application server and then done this calculation looping over the data at the application server. But this shows you how even something like t his, this is pretty pure business logic, can be embedded inside the database and execute here rather Page 18 Copyright/Trademark

than at the application server layer. layer. 00:04:53 Let's go back to our CREATE PROCEDURE statement, and I will... in my input param eters we want to put in a particular product ID, and then we'll output the product sal e price table for that product ID. 00:05:15 Let's get our source code. You'll notice that there's a bit more source code her e, but it provides some interesting learning opportunities. Let's go ahead and put it in h ere. First of all, 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 t he result set of a SELECT statement or the result set of a CE function, so they automatica lly take on their data type based upon whatever data is being passed into them. So we didn't need to do any sort of data declaration or type information about that variable before i ts use. In this case, we're going to have some variables, traditional variables, that will be used either as a scalar value to perform part of this calculation in our imperative logic. T herefore we do have to declare them, and we have to give them a data type. So we're going to declare this lv_category. It's going to be a character field, 40 characters long, and we 're going to set it initially 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 our SELECT statement here, where we're going to select the product ID, the category, and the price for a record from the products table where the product ID is equal to our input parameter. Likewise, we could have used a CE function at this point. It didn't r eally matter, performance-wise, for this particular procedure. We're returning, realistically, one record because we're passing it a product ID so that's the unique key of the products t able, so returning 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. Th is is a little bit of an interesting concept. In other programming languages, you would probably take this result set or, in this case, it's flat, it's one record, so it's like a structure and you would probably try to access a sub-part of that structure. But everything in SQLScript revolves around 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,

single record. Let's get the category field from the lt_product structure and pu t it into this other intermediate variable so that we can use it in our imperative logic. That' s all that we're doing here. 00:08:14 Now we have our imperative logic, so simple IF statement, IF lv_category is 'Not ebooks', THEN make the discount 20%. If it's 'Handhelds', then it's 25%, and 'Flat screen s' 30%. Here we have a LIKE statement, so IF lv_category is LIKE 'Printers,' because we' ve got a couple different types of printers, so we've wildcarded that value, that compari son, and the discount is 30%. Any other conditions, so just a simple ELSE statement, then there's no discount. 00:08:49 Now we can fill the output structure, the product_sale_price. We'll select the Pr oductID , the Category , and the Price from lt_product. Once again, we're just taking fields fr om that result set, putting it in the output, but then we're also able to calculate the fourth column, which would be the discount. So we'll take Price , minus, and then we cast the result of price times our discount, and then we have to say as decimal(15,2) to make sure that it keeps it as a decimal, the right type and length. And then we say as Sale Price . That will 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 of Page 19 Copyright/Trademark

imperative logic, but also how we can read parts of the data, read variables, ou t of result sets in this case, we have to do that because we can't use the result set directly in our imperative logic. We have to do the SELECT to put it back into another intermedi ate result. read parts of the data, read variables, out of result sets in this case, we have to do that because we can't use the result set directly in our imperative logic. We have to do the SELECT to put it back into another intermedi ate 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 the SQL Console in order to test. Let's get our test procedure, sessiona.00.mode ls, and we'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's notebooks. The price is $956, but the sale price is $764. Maybe just to compare this, that's a notebook, let's run this now with some of the other products that we have in o ur database. Let's just run this with HT-1002. So now we see that they happen to bo th be notebooks. Let's just check this real quick. Let's get another record so that we can compare and make sure that our calculation is really working correctly. So let's just browse the product 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 bo th of those statements once again, and here we see the result of the notebook with its sale price, and the result of the flat screen with a greater discount amount. You can see how we can test our SQLScript procedure pretty easily. I hope this has broadened your understand ing of what we can do in SQLScript procedures and how we can really begin to move not j ust our data logic, but also begin to take some of our business logic and move it down i nto the database as well through the usage of imperative logic inside of SQLScript. Page 20 Copyright/Trademark

Week 3, Unit 5 00:00:13 This is week three, unit five: Using the SQLScript Debugger. So far in this week we ve seen how to build SQLScript procedures. We ve seen various syntax approaches both with SQL statements, CE functions, and imperative logic. 00:00:31 Of course the more logic that you write down in the database in the form of stor ed procedures, the more you need a good tool to be able to debug what s going on. Particularly as you start writing imperative logic and you have intermediate var iables, often in order to troubleshoot, you need to see what are the values of those intermedi ate variables at runtime. 00:00:52 Well luckily, as of HANA 1.0 SP5, we have a full interactive debugger and that s w hat we re going to have a look at in this unit. So because HANA studio is based all on Ecl ipse, running inside the Eclipse framework, we re able to take the standard Eclipse debugger and use that for our SQLScript debugger as well. 00:01:16 The standard Eclipse debugger has several parts to it. Up in the top left-hand c orner we have the Debug Session. This shows us which server we re connected to and which de bug session we re currently in. In the top right-hand corner, we have our Watch area, that would have a listing of our breakpoints and it would show us all of our variables. 00:01:41 And from there we ll 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 we re currently debugging. Now t here are a couple of steps that you need to go through in order to have the proper de bug privileges. 00:02:00 So basically your user either needs a role that has these privileges or they hav e to be granted directly to you. So you re going to need some access to the SYS_BIC schema so you re able to access the privileges themselves and execute them. And then you re go ing to need the DEBUG (SYS) procedure with EXECUTE privilege. 00:02:21 So let me show you what this looks like. I ll go to my user ID, go to the Security folder, look at the user ID that I m using for this workshop, and we actually have it in one of the roles. We don t have anything directly granted to our user ID, well, with the exception o f some system privileges that I added that weren t in any role. 00:02:47

But everything else is done via the roles and it s actually here in the admin work shop_user role. This is a role I created for everyone doing the exercises in this workshop , so it has everything you need in order to do the workshop. Most importantly, we have acces s to the SYS_BIC schema and we have the DEBUG (SYS) authorization. You have to have execu te to DEBUG (SYS) procedure. So that s what you would need in order to be able to debug SQLScript procedures. 00:03:28 Now the debugging process is pretty straightforward. You pull up your procedure in the procedure editor and you can double-click in the area next to the line numbering , and that will set a breakpoint. You can also right mouse click and say Set Breakpoint. 00:03:46 It s important to note that this is one of the reasons why you really want to star t to use the Page 21 Copyright/Trademark

new procedure editor, the file-based procedure editor, because you cannot separa te points in the old editor. -based procedure editor, because you cannot separate points in the old editor. 00:03:58 So you remember back a few units ago where I showed you that you could create procedures and edit them in the new source-code-based file editor that sits as p art of your project in the team provider. Or you can create them in what we call the navigat or editor, the modeler editor, and that s over in the SAP Systems view. 00:04:19 Well one of the other major differences that I didn t denote earlier because we ha dn t talked about debugging yet is that you can only separate points in the new edito r. And then once you start the debugger, you see...we'll go in the system in a minute and se e this, see our service 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 i con and then choose Debug Configurations and create a SQLScript procedure configuration. Righ t now you only have to do this once, and there s really no configuration that has to be maintained for this, so we don t have to maintain ports or anything like that. It s automatical ly going to use the SQL connection of the HANA studio. That s how it connects to the server fo r debugging purposes as well. There s 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 t hat we cannot debug procedures that have input parameters. So there s nothing, there s no d ialog that will come up and ask you for the input parameters. Therefore, we often have to write a wrapper procedure around our existing procedure in order to debug it. We ll see th is in the exercise. 00:05:48 Now once you start the debugger you ll see that the debugger stops on any of your chosen breakpoints. Another limitation that we currently have is that you cannot single step in the debugger, 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 execution of your procedure, you should set multiple breakpoints in advance. Onc e the execution does stop on a particular breakpoint, you ll see all the variable displa y and you ll see the values for any scaler variables and you ll see the number of rows listed f or any table variables. You can then right mouse click on a table variable and it will open a n additional

screen that will show you all the record details that are in that variable. 00:06:37 So let s go back to the HANA studio, go to the Project Explorer, and we want to de bug one of our procedures, but first we re going to have to create this wrapper procedure. 00:06:50 So let s say debug wrapper, New > File > debug_wrapper.procedure. We ll have no input or output parameters in this procedure, so there s no types that we have to create . We really only need one line here to call our other procedure, so we re going to test our procedure that has imperative logic in it. 00:07:27 So let s adjust this so it points to our procedure, so sessiona.00.models and we re going to pass in HT-1000. So let s go ahead and save this and I will Activate. Right, so no w we can set a breakpoint here in the wrapper. You always have to set a breakpoint in the wra pper because that s actually the procedure we re going to execute. 00:08:05 Then let s also go into our get_product_sale_price and set one here, and set one h ere as well. And like I said, we can also right mouse click and say Toggle Breakpoint, that would set Page 22 Copyright/Trademark

one as well. So now at this point let s switch to the Debug perspective, if you do not see the Debug perspective up here in the corner of your screen like it is in mine, you c an always say Open Perspective and choose it from here and that will add it to the window. as well. So now at this point let s switch to the Debug perspective, if you do not see the Debug perspective up here in the corner of your screen like it is in mine, you c an always say Open Perspective and choose it from here and that will add it to the window. 00:08:39 So we ll switch to Debug perspective. We can see our breakpoints set here and we c an see both of our procedures. Now what you want to do is you want to be sure that you have the debug wrapper procedure highlighted. If I have this procedure highlighted, if th e focus is on it and I try to start the debugger, then it s going to fail because this one has i nput parameters. So it doesn t 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. We ll come up here to the little bug icon and we ll say Debug Configurations, I ve never debugged on this system so the first time I have to cre ate a new debug configuration so I ll just call this SQLScript. Notice there are no paramete rs, there s nothing to fill out here in this diagram. Eventually, there will be debug config uration. In a future revision, we ll add the ability to execute procedures that have input param eters and what you ll have to do is have a SQLScript procedure debug configuration. And in t his debug configuration, you ll see the input parameters and you ll have to fill in a value an d save it as part of the debug configuration. For now I ll just apply this configuration, I ll sa y Debug, it will connect, and it s running, and we see that we ve already stopped here. 00:10:07 Now there s nothing real interesting to see because we re just in the initial part h ere, so we ll say Resume. That will go to the next breakpoint and already we can see our c ategory is null . Our discount is 0 . We have one record in our LT_PRODUCT right now, and if you want to see the details of that one row you would say Open Data Preview. It open s down here and we can see the current values as well, so we can already see what value s we re getting there. 00:10:40 So let s go ahead to the next breakpoint. Now we can see which discount has been calculated, so already we re beginning to be able to have enough information to de bug and maybe we saw, Oh, it s notebooks, but we have the wrong discount coded in the progr am. I shouldn t have 20, I should have something else .

00:11:01 This is a simple example but hopefully it demonstrates to you how powerful the S QLScript debugger is, particularly with the ability to look at the data values that are i n a table parameter. And you ve seen how you can use this to debug your procedures, which th en supports you being able to write more of your business logic down in the databas e layer. Page 23 Copyright/Trademark