openSAP Introduction to Software Development on SAP HANA

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

WEEK 4, UNIT 1 00:00:13 Welcome to week four of introduction to software development on SAP HANA. In this week, well focus on building services using the built-in OData generation framework, and also how we can consume those services from the user interface. So well actually see a mixture of layers. Well introduce the user interface technology and go through it just enough so once we generate some services well immediately be able to consume those in the user interface. Now starting of week four, in unit one well discuss the architecture of both exposing and consuming data from SAP HANA. So maybe it helps to look at the traditional SAP architecture so we can compare and contrast that to the architecture that we have with SAP HANA. In the traditional architecture, both the NetWeaver Java and NetWeaver ABAP architecture, although what we show in the slide is primarily the ABAP architecture, you have the traditional three-tiered approach to scalability where you have the database layer, the application server layer, and a client layer. Now in this scenario we didnt do much down in the database so we tended to treat the database as just a data storage - a bucket, if you will. We didnt do stored procedures in the database. We didnt take advantage of any particular database-specific functionality. We would have SQL statements of course, but ABAP developers tended not to use much in the way of advanced SQL capabilities. A tendency not to use JOINs and SELECT sums and instead bring large amounts of data back to the application server and loop over it at the application server level. Because thats where all of our business logic was contained, and even in the ABAP world they have a data dictionary layer at the application server as well, which applies additional semantics on top of the data, requiring most of this data to be brought back to the application server layer. Now this application server layer, in addition to having been very large because it had to buffer a lot of data, needed most of the CPU, meaning that we did most of our scalability at the application server layer by either adding more or larger application servers. In this approach, we also did most of our UI rendering on the server side as well. We had this and we had something we call the SAP GUI as our client on our client device on the desktop and we use proprietary communication protocols to send data down to that SAP GUI device. But most of the user interface rendering had to be done on the server and all user interface events had to be sent back to the server for processing. This created a situation where the application server was very large. It was the focus of the programming model and it was really the focus of system administrators and developers who spent most of their time

00:00:31

00:00:44

00:01:08

00:01:29

00:01:50

00:02:10

00:02:25

00:02:44

00:03:04

working at this application server layer. 00:03:30 Now we compare that to the SAP HANA architecture, particularly the HANA architecture when we are using native application development, meaning HANA Extended Application Services, as we talked about back in week one. And just a little refresher about how the HANA Extended Application Services architecture works. In this situation, the application server is shrunk down, meaning the XS really stands for extra small and it runs inside the database itself. And this means we can better take advantage of specific database features that we are able to use more code pushdown so we are able to put more data-intensive logic deeply down inside the database itself. And we will leverage database-specific features here. We want to re-write some of our business logic in the form of SQLScript procedures, as weve seen in previous weeks. And if we do that, if we write most of our business logic down in the database layer, then that doesnt leave much for the application server to need to do. Because weve also taken all of the UI rendering and weve moved it out to the client. As client devices have gotten more powerful, even phones and tablets we can do the complete UI rendering even on the client side. And this follows with the paradigm of creating HTML5-based applications. So well heavily write HTML and JavaScript and well send those HTML and JavaScript files down the client side with the complete UI rendering, and all the user interface events will be taken care of on the client side. That leaves a minimal role for this application server layer and that primarily is to service enable the business logic and data that exist down in the lowest layers of the database. Thats probably the most important function that the XS application server layer serves. In addition to being the Web server, it has the ability to do some procedural logic. But the service enablement is really key. Thats how we can expose the data to the user interface, and when events in the user interface need additional data or need to process some logic on the server side, theyll call these REST-based services that are exposed by the XS services layer. Now in this week, we will see one approach for creating these REST-based services, but well also see how the user interface running completely on the client side can interact and consume those services. Now just a little bit more about the architecture, whats going on inside HANA when we have this sort of communication. So of course the client devicewhether thats laptop, PC, mobile device of any sortits making an HTTP connection to the HANA server. So Web browser or any other client device that can communicate with HTTP or HTTPS, secure HTTP, can communicate to HANA. And when that communication comes into the HANA server and inside the HANA server, we have three processes involved at the operating system level. The first process is called the ICM, which stands for Internet Communication Manager. And this is the Web server itself. Those of you who already may be familiar with some of SAPs classical architecture, you may recognize the ICM. The ICM is actually the Web server that we use in the NetWeaver ABAP and the NetWeaver Java environment. So its an application server thats been around for a number of years, already has a lot of robust capabilities, and is well-suited to the kinds of communication with the rest of the processes that we have here. So we have this Web server and then the Web server communicates to the XS Engine process. So this is the application server of HANA so its just another process to the

00:03:44

00:04:03

00:04:20

00:04:36

00:04:54

00:05:20

00:05:51

00:06:13

00:06:35

00:06:53

00:07:19

Page 2

Copyright/Trademark

operating system level and it has special connectivity to this ICM process. Now at the lowest level inside of HANA, we have the index server process. 00:07:43 The index server is if you would think of HANA the database itself and you had to classify it down to one operating system process, the index server would be the most important of those operating system processes. Its the main core of HANA, of the database itself. And when we talk about the Iin-memory store where all the database data is stored in memory, at the operating system level that memory is allocated to this index server process so you see how its so central to what is HANA itself. Now the XS Engine process is actually an extended type of index server, and that means that the XS Engine process actually thinks its an index server. It knows how the index server works because it really is just aweve taken the index server and added more functionality to it. And because of that, the HANA Extended Application Services has capabilities that no other application server would have. It understands the HANA native data types. It understands how the index server processes SQL statements. So the XS Engine can actually pre-process the SQL statements before it passes them over to the index server. And because of this close relationship, in the future well be able to do more advanced capabilities such as the XS Engine being able to have shared memory semaphores with the index server so data doesnt have to be copied inner process at the operating system level. But even today where we have to move data between the index server and the XS Engine process, its very efficient. This is an inner-process communication at the operating system level and were able to use our internal HANA APIs. Therefore, we dont have to transform the data to other data types. It doesnt have to go through some process of preparing the data for moving it, and it doesnt necessarily have to move across the network either, so this is part of the technical advantages of the HANA Extended Application Services. This hopefully gives you some idea of the base architecture that well be working with. Of course, as an application developer you dont necessarily know which process does what, but I think it helps to have this fundamental understanding and then in the following units in this week, well look at the development processes of how we create a RESTbased service in the XS Engine thats exposed by the ICM and well see how the client device consumes that service.

00:08:00

00:08:16

00:08:35

00:08:56

00:09:14

00:09:32

00:09:55

Page 3

Copyright/Trademark

WEEK 4, UNIT 2 00:00:13 This is week four, unit two, SAPUI5. Now although this week is centered on exposing and consuming services, before we really get into creating the services and then consuming them I think it makes sense to take a few minutes and expose the user interface technology itself independent on how were going to use it or how we use it to consume services. Itll give us a nice foundation that when we have created our services well be ready to immediately consume those in the user interface. Therefore, in this unit well look at SAPUI5, which is SAPs UI development kit for building HTML5based applications. Now I should stress that SAP does not require you to develop in SAPUI5. SAP HANA native application development is really open to allow you to use any clientside JavaScript rendering or any UI technology that can consume REST-based services. Sometimes inside our own prototypes and projects internally, well use other third-party UI libraries as well, such as jQuery, jQuery mobile, Sencha, Sencha Touch, or PhoneGap. Theres nothing wrong with that, but what SAP has done is weve built an HTML5based library and as youll see, its based upon jQuery, its based upon an open source library. But where weve gone in and added certain features we felt were necessary for enterprisebased applications. Therefore, this UI library is delivered with applications and it is part of every HANA system as of HANA 1.0 SP5 And therefore you have a library and you dont have to go out and get a third-party library and I think youll find that weve done a nice job of integrating it into our development environment and the rest of the development process. So now, maybe just a little bit of an overview about what SAPUI5 is. So first of all it just is a series of JavaScript libraries and cascading style sheets. So theres nothing terribly proprietary about the core technology on which weve built. We want this to be able to run in any browser thats designed for HTML5 capabilities. Therefore, this is a standard JavaScript-type rendering library. It does follow the paradigm of completely client-side user interface. There is no server-side component to SAPUI5 at all. Thats part of how weve been able to deliver SAPUI5 for all of SAPs existing platforms, including SAP HANA. Its just a matter of adding these client-side libraries in some form of a repositoryin our case, the SAP HANA content repositoryand then being able to serve them out via the embedded Web server. We also wanted SAPUI5 to be built upon really open standards. So we didnt write a complete UI rendering library from scratch. We started with jQuery, a very common, very popular open source JavaScript-based UI library. And we let the jQuery do as much as possible, so the browser detection, the drag-and-drop library, these sorts of things are all provided by jQuery core. We only added our functionality where it added additional value. So for instance, we dont use jQuerys UI elements. Weve introduced our own UI elements so that they would have a common style and theming capability as the rest of SAPs UI technology. Now this does mean that for the Web developer or the application developer whos building the user interface, that you have to have certain skill sets. You have to understand basic HTML. You have to understand cascading style sheets, and you also have to have a very strong understanding of JavaScript. JavaScript being the majority language that youll use when coding the user interfaces. It actually works out that every UI element type is represented as a JavaScript class and every instance of a UI element, say a button, an input field, or so forth, is a JavaScript object instance. So well see this in the next unit when we start creating some SAPUI5based applications. The other thing that SAP wanted to add was we wanted extensibility and theming capabilities. So we wanted to make it easy for you, the developer, to add your own UI

00:00:39

00:01:03

00:01:30

00:02:02

00:02:28

00:02:56

00:03:21

00:03:48

00:04:45

Page 4

Copyright/Trademark

00:05:07

elements, so this is not a closed rendering framework by any means. You can subclass our UI elements and extend them and add additional properties and events to them, or you can create your own UI elements that just use our rendering classes so that they render correctly inside the rest of the framework. We also have a theming framework built in. We do not use the jQuery theming because we wanted the SAP UIs themes to be compatible with SAPs existing theming technology thats used in the NetWeaver portal. But we also wanted you to easily extend the look and feel without having to build an entire custom theme. Therefore you can simply override the CSS, cascading style sheets properties, on a particular UI element. So you can attach these properties directly in code with JavaScript. And then finally we wanted to make it very easy for you as the developer to also integrate other existing JavaScript libraries. Maybe from one of the other major HTML5based libraries such as Sencha, Sencha Touch, jQuery, jQuery mobile, just to name a few. But it also very easy to take an existing JavaScript library for a special purpose and drop it in, use it inside your SAPUI5 application. And then we want the applications you build in UI5 to be able to target multiple devices. This means the desktop and laptop, as well as smartphones and tablets. And the core rendering as youll see when you create an application initially you have to choose between desktop and mobile, but thats not to say if you choose desktop it does not also run on the mobile device. The desktop rendering will render correctly on a mobile device but it still does not have the mobile-specific look and feel Nor does it have mobile multi-touch events. So you can code one application that runs on multiple devices, desktop and mobile devices, but you wont necessarily get mobile optimizations. You also have the ability to choose mobile rendering and then you get a special rendering mode that will sense the client device and use one of three themes, either an iOS theme, an Android theme, or a BlackBerry theme. And then this mobile rendering mode also has special touch events built into it. On the other hand, the mobile rendering has less UI elements than the desktop mode, so you kind of have to choosedo you want to highly optimize for the mobile experience but then have fewer UI elements in which to express your user interface and create a user interface that probably isnt optimal for the desktop, so youll be truly targeting only the mobile device. Or do you want to create a desktop experience that is also compatible with rendering on the mobile device? Now just a little bit more background as far as some of the technologies we use inside of SAPUI5. First of all, HTML5, So weve leveraged new capabilities in the HTML5 capabilities. And HTML5 is sort of an umbrella term. Its not as though its one single technology. Actually it means extensions to the JavaScript language, improvements in the just-in-time compilation of JavaScript, new extensions to cascading style sheets, and things like the canvas tag, and we take advantage of that in various ways, such as all our charts and graphs are rendered using HTML5 and dont need additional plug-in technologies. We also have used jQuery. I already mentioned that we started with jQuery as really the core of the SAPUI5 library and therefore if you already understand how to use jQuery or youre familiar with that technology, youre going to take to SAPUI5 very quickly because it follows many of the same patterns because it uses jQuery internally. And even some of the operations that youll see much later when we begin consuming some REST-based services, we'll even use the jQuery/Ajax libraries to be able to call those services. Of course, we have cascading style sheets 3 for the style and layout. We heavily leverage OData. Now, well talk about OData more extensively later this week when we start building our services. But OData is an open specification. SAP sits on the specification board along with other

00:05:37

00:06:37

00:07:06

00:07:40

00:08:15

00:08:30

00:08:58

00:09:20

00:09:46

Page 5

Copyright/Trademark

companies such as Microsoft. Some people have described OData as ODBC for the Web. It is an open and easily consumable way of accessing data and business logic over HTTP using standard HTTP concepts. So you dont have to have a special envelope or a special header, therefore its very easy to consume. 00:10:18 Weve baked OData consumption directly into SAPUI5. Thats one of the core capabilities, one of the core reasons why you would choose SAPUI5 as opposed to a thirdparty HTML5 rendering library, because our UI elements are designed in such a way that theyre readily able to consume OData services and directly bind to them. Youll see this extensively once we start consuming some OData services just how easily the UI elements interact with the OData services. We have OpenAjax for inoperability, that is an open standard for when you have multiply widgets and parts in a page coming from different servers or applications to be able to exchange data and events within that page using client-side JavaScript. We use the LESS library for themes, D3.js for our data-driven documents meaning the charts and graphs and preparing the data for going into the charting libraries. We use the ARIA library for accessibility, and then we built our own learning SDK, which Ill show you in a few minutes. So you see SAPUI5 is really a combination of open standards, some third-party open source libraries such as jQuery, the OpenAjax, and D3.js, and some SAP self-created technology. A little bit about the really deep inner architecture. I already mentioned how we have both a desktop and mobile version of the controls and the themes. When you first create a new project, you do have to choose right away whether you want desktop or mobile because thats going to control which of these libraries are loaded on startup of the application. Then inside the SAP UI core we of course have jQuery at the heart and then we have certain SAP-written jQuery plug-ins. So these are the SAP extensions but written in such a way that they conform to the jQuery plug-in standard and integrate nicely into jQuery. So all the eventing, resource management, device detection, other utilities and login capabilities are SAP-provided jQuery extensions. Then you do have jQuery mobile and jQuery UI delivered as part of SAPUI5. Its there for you to use if you choose, although in our examples and our SDK well primarily focus on our UI libraries because they have the built-in data binding to the OData services and the rendering manager integrates with our theming. Therefore our control libraries are designed for our UI framework, not the jQuery UI framework. And then finally on the server side the only thing you might have is a resource handler, something to be able to serve out this content, these JavaScript libraries, this HTML content, really acting as a static Web server. And in our case, theres nothing special built into HANA for this. Were storing all the SAPUI5 content, even the pages you develop. Theyre all stored in the SAP HANA content repository like all the other development artifacts weve seen so far and theyre served out via the ICM Web server. Heres a little example of what an SAPUI5 application might look like Youll notice in this case this uses the new lanes concept for presentation of large amounts of data and disparate types of data, so this would be like a launch or welcome screen and then the lanes help the user navigate deeper into the information thats presented here. So this gives you an idea of some of the rich, unique visualizations that you can have with SAPUI5. I would also show you, once again weve looked at this earlier, but this is the end result of what were building up to in this workshop is going to combine all of our data-intensive logic, our data models, and our service enablement, and this is the user interface that weve put on top of this to interact with the purchase order information weve been working

00:10:43

00:11:11

00:11:53

00:12:15

00:12:45

00:13:17

00:13:33

00:13:58

00:14:26

Page 6

Copyright/Trademark

with. 00:14:52 And you see some of the core capabilities of SAPUI5 coming through here in the search field, I just begin typing and immediately I get some response so its a very Google-like search particularly in that its gone back to the server and searched across many different fields in many different tables. So instead of the traditional paradigm of several different fields, we really wanted a more intuitive search capability. And were able to do this very quickly because were using client-side events to capture the typing and were making an asynchronous call to the server to execute the REST service to bring back the results. So we also see here the nice table control and we have built-in capabilities such as sorting and filtering and we dont have to bring all the records down to the client side. This isnt a terribly large amount of records now that Ive filtered, but you notice that when I scroll a little bit father theres another asynchronous call to the server to fetch another batch of data and then its cached on the client side. So we have this rich table control with lots of functionality, yet we dont need any kind of server-side UI framework to enable it. And then finally we have charting capabilities, nice animated charts, so when I choose a category to display we can see the information breakdown here and I can drill into the data as well. So you see the nice animated HTML5-based charting capabilities. So this gives you some idea of the typical capabilities of an SAPUI5 application. Now theres lots of information available for you to learn SAPUI5. We have the SAP Community Network that we saw earlier on in week one. In addition, in the developer center there was HANA information. Theres also a dedicated section for user interface, meaning SAPUI5. We also deliver a UI development kitan SDK if you willthat is embedded inside every server that has SAPUI5 and Ill go into the system in a second and show you this. We also deliver tutorials that you can study and theres an SAP service note listed here with more information about how to install and how to configure SAPUI5. Let me show you the SDK. Now this SDK is available on all HANA systems SP5 and higher, you just need to put in the URL sap/ui5/1/sdk/index.html and that will take you to the SDK. The beginning, the overview, just gives you a little basic information. The developer guide is something that even before you start developing youll probably want to read through the majority of this. This is sort of the how to getting started guide, as well as some really deep information like how to write your own UI elements, how to subclass our UI elements, how to use the different model binding capabilities to OData or to JSON. So conceptually, the major things that youre going to need to know are all written about here in the developer guide and the developer guide has lots of source code examples built into it as well. Now we have the Controls gallery, and I really like this as a learning tool. Lets take a simple UI control like a button, I can come here and see representations of different styles, different properties set on the button. But what I really like is that I can see the source code that generated this example and I can even come in here and I can change the source code. So if I want to see the impact of what changing the text property has on this UI element, I can change it inline, I can hit Apply and I can test that UI element. This is a great learning tool. It means that you dont have to create dummy applications just to be able to try out a couple of pieces of code; you can try it out here inline. Next we have the API Reference. Where the Control gallery is really nice for getting an overview of the general capabilities, sometimes you really need that documentation of every property and every event for each UI element. Theyre all represented here, every UI

00:15:20

00:15:46

00:16:10

00:16:39

00:17:00

00:17:25

00:17:57

00:18:26

00:18:50

00:19:12

Page 7

Copyright/Trademark

element is in the tree on the left-hand side and then as you choose the UI elements it gives you the complete breakdown of all the events, all the methods, all the properties that are exposed in this UI element. 00:19:40 And then finally we have the Test Suite, which is similar to the Control gallery but in here youll get more composite UI elements as well. So it might put together two or three concepts, in this case how to embed other native non-SAPUI5 HTML inside the SAPUI5 render. Weve got examples of the different forms of data binding, so this goes beyond looking at what just a single UI element can do and sometimes look at how various UI elements interact with one another. Now, the overall positioning of SAPUI5. If youre familiar with SAP core technologies outside of HANA, we have other UI technologies, we have a UI technology called Web Dynpro, its the primary other UI technology. For the business suite its important to position this correctly, SAPUI5 is a new addition to our UI strategy and the traditional Web Dynpro technology is still used in the business suite, particularly for the expert users and for the very complex transactional user interfaces. SAPUI5, on the other hand, inside the business suite, is largely centered on the occasional users, the managers, the self-service scenarios, the limited transactional capabilities. We use it heavily in the analytics when we need to display charts and graphs, collaborations and feeds, these types of applications. But I should remark thats for the business suite in SAP HANA native applications because this is a new platform and we built it with SAPUI5 from the beginning and SAPUI5 is the only technology that SAP delivers for HANA native applications. Therefore you would use it for all types of applications, whether its an expert user or a casual user, when youre building new SAP HANA native applications. And then some of the core features weve seen here, we really want to focus on delighting the user so we want this user experience to do that by allowing them to run the same application on any device. So even if you do the desktop rendering, it renders just as well on the users laptop as when theyre accessing the same application from their phone. We really want to build in cutting edge controls with powerful theming so the user is delighted by the user interface. It has a consumer look and feel. Therefore the users going to be attracted to it and at the same time we want to make sure that theres efficiency and good performance behind there so its not just about looking nice and being easy to use but making sure that its responsive as well. On the other hand, we wanted SAPUI5 to really be centered on fostering innovation so we wanted extensibility. Very easy, very open extensibility but at the same time we wanted developers to have a high level of productivity. Therefore we built in things like the OData service consumption directly into the UI elements. That also lends itself well to a concept that SAP executives like to call timeless software, Timeless SAP Data Consumption. By having that layer of abstraction, by calling the data access via REST-based services, that allows us to change the service implementation over time and not impact the user interface. And then finally we have very fast release cycle.s SAPUI5 is not tied to any one SAP technology. Its not tied to the release cycles of SAP HANA, theyre working independently and they have new SAPUI5 releases that might come in a HANA revision. And then finally we wanted to embrace open standards, so all the design tools are all based in Eclipse. We wanted at the same time to have enterprise readiness like language translation, accessibility support, all these sorts of things that we need in the enterprise built in, and we wanted to be able to use open standards to do that. We wanted it to be based on standards also that make it easy to learn. As I said, if you know jQuery, if you know JavaScript, then youre going to take to SAPUI5 very easily.

00:20:19

00:21:00

00:21:22

00:21:55

00:22:19

00:22:45

00:23:05

00:23:28

00:23:53

Page 8

Copyright/Trademark

00:24:18

And this also means were flexible and were open, we can reuse third-party libraries inside of SAPUI5 and even write your own libraries. And then the development tools themselves, as well see in the next unit when we begin to use them, but all the development tools install into Eclipse. Theyre all Eclipse-based. That means you install them into your SAP HANA studio and youll have one development environment to do your user interface development and all your other HANA development. Its very easy. We have an update site that is available. You configure that update site into your HANA studio update sites and then you say Install New Software. And then it will bring the SAPUI5 additional tools and wizards into your HANA studio. And once you have it inside your HANA studio, youll see that we do have wizards, that we have code completion on the SAPUI5 UI elements. We have built-in help documentation on the UI framework so this makes it feel really, really comfortable because its integrated into your SAP HANA studio. If youre already familiar with Eclipse-based tools, its going to also feel very familiar. If youve done other Eclipse-based Web development, it follows all those standard Eclipse paradigms, which means that if youre already a Web developer, if youre already working with HTML and JavaScript, its going to be a very small learning curve for you to get up to speed on SAPUI5. We have some templates that weve included in here as well. We have support for other SAP-based development environments. We said that SAPUI5 installs into HANA studio. It also installs into ABAP development tools and the NetWeaver Developer Studio. And a little outlook to the future is that in the near future well have a WYSIWYG screen designer. Currently today you hand-code all the UI elements. There are some wizards to help with that, but still all the UI elements are coded either in HTML, XML, or JavaScript. But we will have a graphical screen designer in the near future. And we will also have a Web-based IDE for you to build SAPUI5-based applications. So I hope this unit has given you a nice overview of what SAPUI5 is, how it fits into SAPs UI strategy, and particularly how it fits in to building user interfaces in SAP HANA native applications.

00:24:44

00:25:33

00:25:41

00:26:02

00:26:20

00:26:54

Page 9

Copyright/Trademark

WEEK 4, UNIT 3 00:00:13 This is week four, unit three: Creating a User Interface with SAPUI5. In this unit well really continue the discussion from the previous unit where we introduced the concepts of SAPUI5. What we want to do now is go into the system, use the SAPUI5 development tools and build a simple little Hello World application. Thisll help really give a concrete idea to some of the concepts we discussed in the previous unit, as well as see the beginnings of how we can build a simple application. The idea is that after studying this unit is we wouldnt have complete understanding of everything about SAPUI5 and be able to create any kind of application. We just want to have enough of a foundation that when we move on and begin to talk about services and then the service consumption that were able to build some user interfaces that will consume our REST-based services running on SAP HANA. So what do we want to do in this unit? We want to build a simple application. Well go into HANA studio and use the New Project wizard. Youll see a screen similar to this where well have to choose the Eclipse project that we want to place this in, and well give it a name and this name will be used to build both the controller and the view. And we choose our target type as well. We choose whether we want desktop or mobile rendering. Well use desktop rendering for all our examples in this workshop. And what this wizard will generate, youll see it create both an index HTML fileand thats really the bootstrap that will load the core SAPUI5 libraries. Its where we define our theme and really start our processing, but we dont put any additional content in this index.html. Then youll notice that theres a WebContent folder thats been created and all of the SAPUI5 objects go into this folder. The wizard will also have generated a controller and a view. So the controller is where we put all of our event processing or any other logic we might need. If we have a reusable utility or a formatter, wed put that in the controller. And also if we have a UI element that throws an event, say a button that has a press event, then you can put the event handler in the controller to separate that out from the UI rendering itself, which would all be in the view. So the view, thats basically where we build our UI elements and render them into the page. Wed do nothing else inside the view. Youll notice both the controller and the view are .js files so even the MVC model is really implemented in JavaScript so the view becomes a JavaScript object, the controller becomes a JavaScript object, and the model is a little bit of a hybrid in SAPUI5. Your model is often just a proxy object pointing to a remote service. Well see that later once we get into consuming our services. What were going to build is a little Hello Worldbased application so were going to need to render a button and on that button were going to change the text so it says Hello World. And then well put a little event so that when somebody presses the button it actually fades away and disappears. Not the most incredible user interface ever by any means, but a typical starting point. It will show us how to create the project, how to set up the bootstrap HTML file, and how to render UI elements in the view. So lets switch over to the system. Im in my SAP HANA studio and Ive already gone ahead and installed the SAPUI5 tools into HANA studio. You didnt necessarily want to watch an installation and a bunch of file progress bars go across, but Ill show you where I did the setup to make this possible. Ive gone into the preferences and Ive gone to Install/Update and then Available Software Sites. And Ive added another software site here for SAPUI5 and Ive filled in a URL. Now this is not the URL that you necessarily use, but an SAP-internal URL. Since Im here inside of SAP at our offices I was able to use this internal build.

00:00:37

00:01:13

00:01:38 00:01:52

00:02:31

00:02:57

00:03:25

00:03:48

00:04:12

00:04:35

Page 10

Copyright/Trademark

00:04:59

You would use a URL either from the SAP public update site, which is documented in the online helpor your company may have downloaded the SAPUI5 installation from the SAP Service Marketplace or from the SAP Community Networkand then you can setup a local update site. So for the exact URL for your situation, you may have to talk to your system administrators and see if they have something available. Otherwise use the SAP public update site. Once youve configured this in the system preferences then youre able to come to simply come to Help>Install New Software. From here you would choose which update site you would want to install the software from. Im going to install from SAPUI5 and its going out, its scanning to see what software is available on that update site. Then it comes back and it gives me a list. Now, I already have installed this so the installation process consists of simply checking the SAPUI5 development kit and, if you want, server connectivity if you would also want to do development with an ABAP system thats an optional piece. You really only need the UI development kit for HTML5. Now if I went farther it would simply tell me that I have already have this installed but even if I didnt it would simply bring up a progress bar and start the installation, nothing too interesting about that. Now that I have SAPUI5 installed into my studio, I can begin by creating a new project in my project explorer. So here I will come and say New and Other and then youll see that we have SAPUI5 development, we have an application project. So you also have the ability to create new controls, new UI elements, new libraries, lots of functionality. But we want to start with an application project. Here Ill give it a simple name. So a new project, Exercises_UI. I want desktop rendering and I do want the wizard to create my initial view. Ill go ahead and leave it in the default Eclipse workspace because when we share it to the HANA repository we can also copy it to our HANA-specific workspace. Now Ill give it the name of the views I want to create. So Ill say HelloWorld and Ill use the JavaScript rendering. This is just a confirmation screen. Ill go ahead and say Yes and Ill stay in the perspective that Im in. And its already created the project. It's created the WebContent folder. I have my index.html and its also created empty view and controller objects for me as well. Now so far this isnt even associated with a HANA system, I can do SAPUI5 development and deploy it to any Web server. I can also connect this project to an ABAP or a Java system. At this point Im independent of any back-end system and actually I can do most of my development here without going to any particular system. We wont even send it to a system until were ready to test it. But at this point I need to make just a couple of changes. So Ill go to my exercises. So one thing I need to do is that I need to change the source of the main library in the bootstrap, so its sap/ui5/1. The wizard doesnt know that were running on SAP HANA and the SAP UI libraries are stored in different places depending upon if youre running this from an ABAP server, a Java server or a HANA server. Therefore the wizard can only put in part of the path and well have to fill in the rest based on what kind of system were connected to. We dont have to make any other change to the bootstrapthe wizards done everything for us. Its loaded the commons UI libraries. If we wanted additional UI elements like we wanted the charts, the table control, we would have to add additional libraries here. It set the default theme, its also loaded the view in the controller. Thats whats happening. At this point its saying, All the views and controllers, all the local resources will come from a subdirectory called exercises_ui, which was generated right here. And it will create a view and this is how the view is initiated.

00:05:31

00:05:51

00:06:15

00:06:38

00:07:12

00:07:41

00:08:14

00:08:37

00:09:23

00:09:49

Page 11

Copyright/Trademark

00:10:13

Youll notice that the view also references the controller, so this is the link between the view and the controller and in this very simple case that we have here we dont even really need a controller because we dont have any event handling per se. We only have the one event and thats going to be on the button press so well just inline that event because its so simple. So here in the source code that Ive insertedyou can see what Im doingIm creating a button. And remember, all of the UI elements are represented as JavaScript libraries; therefore a button UI element is sap.ui.commons.Button. Then we created an instance of that UI element we the ID btn so we can refer to it later as its ID if we need to. But then we have this JavaScript object that really represents that button on the screen. So were able to set properties. So we set the text that we want to appear on the button and we attach the press event to that button and anytime the user presses that button then we call, this is actually a jQuery-provided function, the fade out is provided by jQuery. Were going to attach that standard fade out jQuery user interaction, the fact that the button will fade away when we attach it to our button control, and that will fire the fade-out event. And then what we have to do at the end of our CreateContent or our view, we have to return either a single UI element or, if we have a block of UI elements, we have to group them in something, a tray, a panel, or some grouping UI element. We return whatever our group UI element is or our single UI element and thats how it will render into the page. So we dont really have any direct interaction with the HTML div that this is placed in. And we dont interact directly with the DOM, the document object model, in this case. We really treat everything as JavaScript objects and then we return them to out of the view and then they return to the renderer. Its actually the SAPUI5 renderer that will do all the insertion into the DOM and the HTML generation. So at this point my project looks pretty good so Ill go ahead and save all my files. Now I need only share this to the HANA repository so Ill say Team> Share Project and Ill choose the SAP HANA Repository as the repository that I want to share it to. Youll remember were using standard Eclipse team provider plug-in so theres other repositories that we could send our projects to. At this point Ill say I want to send it to this particular HANA system with this user ID, but we want to choose the package we place it in. We actually want to nest it inside our workshop sessiona, 00, and Ive created a UI folder so Ill nest this project inside our other project so that our UI project becomes a child project of our overall workshop project. Say Ok. Say Finish. And the project is being shared to the server. At this point we can then commit all of our resources to the server and now we can activate everything. And now that its active I can go back to the server browser, the HANA Repository browser, and I can go into my UI package and youll see it all represented here So we know that its checked in, that its active. Its good, its ready to run from the server, and we can begin testing it now. To test it, well just put in the package path, workshop/sessiona/00/ui/Exercises_UI, which was the name of our UI project, and /WebContent and then /index.html, our bootstrap. And there you see it rendered: Hello World. And if I click on the Hello World it fades away, so we know our rendering is correct and that we have some interaction there. Now this was a very simple example, but hopefully its given you a good understanding of how the SAPUI5s tools work, how its integrated into the SAP HANA Repository, and given a basis for us now to be able to build a little more complex user interfaces that will consume our REST-based services.

00:10:33

00:10:59

00:11:21

00:11:49

00:12:05

00:12:19

00:12:47

00:13:16

00:13:50

00:14:35

00:14:48

Page 12

Copyright/Trademark

WEEK 4, UNIT 4 00:00:13 Week four, unit four: OData Services. In this unit well cover some of the fundamental concepts of what an OData service is. This will help us in preparation for the next unit, when we will begin building our OData services in SAP HANA. So first of all, some of the basics. What is an OData service? 00:00:36 Well, OData is an open specification. SAP sits on the board of OData specification along with other companies, including Microsoft. The idea of OData at its heart was to define an open but very easy-to-consume standard for interopting with data over the Web. This sort of grew out of the idea of enterprise services, Web services. 00:01:05 Now, whereas Web services use SOAP as the body format and have a rather complex format for envelopes and communicating the service definition in the form of WSDL documents, OData on the other hand embraces REST-based architecture. This is lighter weight, HTTP-based, and will use the HTTP verbs as the actions in our OData service. And we really embrace the request and the response object of the HTTP as the communication means of any REST service. 00:01:44 So this being a simpler protocol, a little bit lower-level protocol, its obviously a much more interoperable protocol and something that doesnt require a lot of programming on the client side in order to consume. 00:02:01 The parts of an OData service, well youd have an OData data model. So somewhere, well define basically which entities we want to make up our service and what are the relationships between those entities. In the SAP HANA world, youll see that our OData service generator works off of tables and views. Therefore, we can use any existing HANA table or any view type, including attribute views, analytic views, and calculation views as the source of our entities. And well literally create a one-to-one entity for each table or view that we want to be part of our service. We'll also be able to define the relationships between those tables or views at this entity relationship level. 00:02:49 Next, wed have the OData protocol. So this is the communication protocol and, as I said, its all REST-based. 00:02:58 It supports CREATE, READ, UPDATE, and DELETE operations by using the HTTP verbs. And then we have a specification for how we define the query language, the query parameters that we add on to the URL as part of the request. So we all have the ability to say, Build a dynamic SQL statement off of any OData query, where we can build in dynamic WHERE conditions and GROUP BY conditions and SUM conditionsall off of the specifications provided in the URL parameters of the OData service. 00:03:37 Next, another part of OData in general is the OData client libraries. So these are prebuilt libraries that help with the consumption of OData services. Now were going to focus on consumption from the Web browser in the form of HTML5 and in that case there arent really separate OData client libraries; its all built into SAPUI5. 00:04:05 The OData consumption is built in to such a level that UI elements have a binding property. And for that binding property, we give it the URL of our OData service and the UI element will do the rest. Well call the service, well introspect the service interface and get the metadata from the service, and even some UI elements like the table UI element have a lot of events built in where they can build the query string properly to recall the OData service. Well see lots of examples of this as we begin to consume our OData services. 00:04:40 And then finally, we have the OData service itself. This means the HTTP end point thats exposed from the Web server, in our case exposed directly from SAP HANA. It allows an external system or any external client or system that can speak HTTP to call the service or consume the data that is part of the OData service model. 00:05:06 So some of the core OData capabilities which weve implemented in SAP HANA via our generic OData service framework. First of all we have aggregation, so you have the ability

Page 13

Copyright/Trademark

to specify that you want to aggregate the values in a particular column. So we can build dynamic SELECT SUM, SELECT AVERAGE, SELECT MIN, SELECT MAX into the OData query specification. 00:05:31 We also have the ability to build associations, thats how we express the relationships between multiple entities. Well see this in a later unit when we build a more complex OData example. Youll have the option of course, if you have multiple tables, you can build a view and build those relationships between those tables and a view and then have a single entity in your OData service that maps to that view. 00:05:58 But that means that the relationships are always processed, meaning if you select a thousand records from the OData sevice its going to have to read all the corresponding related tables and pull their records in and basically process the JOIN condition. If you instead do two separate tables, or even two separate views, and define the relationship between those two at the entity level in the OData service, its processed a little differently because the OData will process only the parent object, will turn all the records from the parent object and inside there generate a URL which points to the records of the child object in the relationship. So it basically allows you to do lazy loading of the related records in a relationship. 00:06:54 You really have to decide on what works best for your scenario. If you're wanting to display say, all the parent records, all the item records inline in a single table, youre better off doing a JOIN and having a single entity in your OData service. On the other hand, if you want drill-in capabilities, if you want to display one table with the parent records and then only load the children for a selected parent record one at a time, then thats much better done via entity relationships in the associations in your OData service. 00:07:27 You also have to supply the keys. Every record in an OData service has to have a unique URL. And in order to have a unique URL, we have to know what are the unique keys of any set of data. Now if youre building your OData service off a table then you dont have to specify the keys. Every table has to have a primary key, and therefore the OData service generator will automatically read the primary keys from the table definition and utilize those. 00:08:01 Now when you have views, you dont have to define key fields for your views. Therefore you either have towith the attribute view and the analytic viewyoull probably just have to specify which columns are your keys. 00:08:17 We also have the ability to generate a key inside the OData service. So this generation will just generate a unique number for each record. Therefore we have our uniqueness and can build a URL. Thats particularly useful for calculation views, which many times dont clearly have a key field. 00:08:40 Next we have parameter entity sets. So as we saw in our earlier week when we were building attribute views, analytic views, and calculation views, we can have input parameters. So this is different than from say, a WHERE condition or a FILTER condition. This is literally a piece of data that is brought in and then has some effect inside the view. It could be used in a formula inside a calculation. It could be used to filter the view, we dont know exactly how its used from the outside we just know its a value we have to pass in. Therefore we cant just use the query string of the OData service. We have to have a special way of supplying the input parameter values and we do this as part of the entity set. So its part of the base URL before we get it into the query string of the OData service. 00:09:34 And then finally we have property projection. Basically what this means is we dont have to expose every column of our underlying table or view. We can reduce the number of columns so we can build a projection if you will, with a smaller number of columns which are actually exposed to the OData service. 00:09:55 And even when youre calling the OData service, there are URL query parameters that would allow you to specify which columns you want, so you can even further reduce it at runtime if you need fewer columns then whats defined in the OData service definition itself.

Page 14

Copyright/Trademark

00:10:12 And then finally, the general development process for OData services. You have to choose an end point, so this generally means choosing which table you want to be the source of your OData service or building a view to represent the relationships of the data and maybe the calculations you need as part of your OData service. So thats your starting point: either a table or one of your HANA view types. 00:10:40 Then you have to build the OData service definition itself. This is going to be another development artifact similar to the ones weve created. It will have the file extension .xsodata. The service definition is a fairly simple file format that you simply supply the names of the entities and their corresponding database object, whether thats a table or a view. And then you have the ability to add other optional parameters, such as entity relations, associations, key generation, and other such parameters. 00:11:22 Finally we need some user interface to be able to consume that OData service. In our case, in the workshop, were going to build SAPUI5 applications and use some of the UI5 UI elements that are especially designed for consuming OData services. For instance well build a table control that will visualize the returned records from the OData service. And well use the built-in filter and sorting capabilities of the table control and see how they map to the OData URL parameters like $orderby or $filter. 00:12:00 Well also see how you can test your OData service from the Web browser by directly typing in the URL. Theres even some nice add-ins into Chrome. I tend to use Chrome and the Chrome extensions. But there are some nice Chrome extensions that format the return dataeither the XML or the JSON return dataand allow you to easily test your service even before you begin building your user interface. 00:12:31 And these are the steps that we will walk through in the subsequent units in this week.

Page 15

Copyright/Trademark

WEEK 4, UNIT 5 00:00:13 This is week four, unit 5: Creating a Simple OData Service. So far in the previous weeks, weve seen how weve built up to our OData service. We have built our base data model, our logic on top of that, and now were ready to begin service enabling everything weve built up to this point. And in the previous unit, we covered a lot of the theoretical concepts around OData services. 00:00:41 I think now its time to go into the system and actually see how we build that service definition and do a little execution within the Web browser to give you an idea what the data looks like and what the URL parameters look like when we consume an OData service. So what were going to do in this unit is were going to build this .xsodata file. 00:01:07 This is the service definition file, and you see in the screen here a small example of what this looks like. Basically we have to supply a namespace. This is mostly for documentation purposes. Dont confuse this with the namespace concept that we get from the package. Most developers however, do supply the namespace of the package hierarchy that they put the OData service into. 00:01:35 Next, in this case we have a table schema and then the name of a table. In this first simple OData service were just going to use tables. A little bit later well see more complex examples that just use views. But for now, we just put in the schema name, the table name and then we say as BusinessPartners. That as BusinessPartners is the name of the entity. Thats how this table will be represented in the OData service definition so nobody will see the long table name, theyll see this entity name when consuming the service. 00:02:16 So the basic development steps that we would need up to this point. We would have had to already created this database table, which we did in an earlier week. We have to grant any privileges to this table or view, which we also did in an earlier week when we built our role and assigned it to our user. So we have all the prerequisites that we need to begin to service enable the data in this table. 00:02:42 Well go to our project. Well add an .xsodata file, which is just a simple flat file. Well use a plain text editor to build the service definition. And the service definition will tell the system what to expose, how to expose it, and to whom to expose it by basically defining which table were going to use as our source and what the entity name of that table will be. 00:03:10 Then well activate this object and then well have a URL that basically points directly to the .xsodata document itself. We can then use the Web browser as a test tool to be able to see the content and pass in different URL parameters and test different capabilities of our OData service. For instance, we might use the $metadata option. That will do an introspection of the service and show us the service interface so all fields and their data types are exposed in each of the entities. 00:03:50 Our we might use $filter. That allows us to basically build a dynamic WHERE condition. The $orderby controls the sort order and $select allows us to narrow the field selection so we can have less fields then what are defined in the OData service. 00:04:10 And then finally, we have the option to specify the format that we get back in the response of the OData service. We can either receive Atom XML back or JSON back. Youll see that Atom XML is the default format and is pretty widely used by SAP in our applications. It has really good compatibility, particularly in non-JavaScript consumption scenarios. Particularly, the Microsoft tools consume Atom very well. But on the other hand, the JSON format is lightweight, less verbose. Theres less overhead to the formatting of the tags and so forth so it takes a little less network bandwidth to transmit and if you are consuming the OData service in JavaScript, JSON processes much faster in JavaScript than Atom XML would be to parse. 00:05:13 So at this point, lets go into the system and lets create our OData service. So I go to the Project Explorer and Im just going to reopen the project that I had been working in earlier. This is where all my data models were built and where we modeled our views. Im going to

Page 16

Copyright/Trademark

the services package. Remember its not required. to have several packages. This is something I do and many other developers do to simply separate out the different types of development objects to better help with the organization. And as a developer I can look at the project and know right where to go if I want to edit the services. 00:05:56 But inside the service Ill say New>File and Ill name my service businessPartners.xsodata. You see it opens in a plain text editor, theres no specialized editor, no wizards involved in the OData service generation. Thats largely because the syntax is really very simple. 00:06:23 So Ill cut and paste in our syntax, you have to start with service, namespace and then Ive supplied a namespace and youll notice that it doesnt actually match my package hierarchy. It isnt technically required to match the package hierarchy. Many developers inside SAP will do that simply as a documentation purpose so you can track back the service definition location on the server. But for this case Im just going to put a simplified namespace. 00:06:54 Next I put the schema and the table name that we want to use as the source of this OData service. So if I were to go back to my HANA Systems view, go into the catalog, heres the schema SAP_HANA_EPM_DEMO and then were going to use the businessPartner table as the source of our OData service. 00:07:16 So it would be right here if you want to look at the content thats in here, we see that we hav PartnerId, thats going to be our primary key, PartnerRole, EmailAddress, PhoneNumber some basic information about the business partner. 00:07:32 So this is what we can expect to see exposed through our data service. And then finally I say as BusinessPartners. And this will be the entity name, this is how it will appear in the OData service and this is a very simple service. We dont have any associations, any relationships, there are no multiple entities, so its a little bit like adding the entity is kind of redundant. Well have the service definition named BusinessPartners and well have an entity inside there named BusinessPartners. But this will make more sense once we start having multiple entities in our single OData service. 00:08:06 At this point Ill go ahead and save that file and I will commit it and then Ill activate it. And upon activation we now have a runnable service end point. Theres nothing more that I have to do at this point so youve seen how with just a couple of lines of code I very quickly have my OData service running here. 00:08:36 So Ill just put in the package path: workshop/sessiona/00 and then the subpackage /Services and then literally just the name of the service definition, businessPartners.xsodata. And Ill just run that. And if I execute the service definition document itself URL, Ill get back a very simple document that just lists the entities. 00:09:12 And youll notice that the only entity listed here is BusinessPartners, very simple. Now if I add a URL parameter here of $metadata, actually I just messed up the..$metadata, then I get introspection of the service. So Im seeing the service interface basically, what in this entity is the key field, the partner ID, what are all the properties, what are their data types, the lengths. 00:09:56 So this is everything that another development environment would need to know about how to call this service. So we dont have any (unlike SOAP-based web services) we dont have a separate (like they do) WSDL, a Web Services Description Language document. We dont have a separate end point or document to be able to see the service interface 00:10:20 We can always just add the $metadata and well get the introspection. At this point I could even go and change my underlying table and reactivate my service and then Id see the new fields here in this metadata. So its a great way, as I said, for another programming language or UI element, say a table UI element, could call this metadata and it would know all the columns in the OData service, be able to build columns dynamically. Theres lots of

Page 17

Copyright/Trademark

uses for calling this metadata parameter at runtime. 00:10:50 Now if I change this metadata, I take it off and I add the entity here. So if I add BusinessPartners, thats literally how we build calls to the service. Everything is done via the URL. So its the service definition and then we add on the entity name as part of the URL. If we need input parameters they get added after the entity name and then all the other query parameters are added as URL query parameters. So if I were to run this right now with just BusinessPartners, itll actually return every record in the business partner table. And thats exactly what were seeing here, every record is returned, every record has a unique URL. 00:11:40 So see how it adds the key field value, the business partner ID in parenthesis behind the business partners, so that would be a unique URL to that particular record. So for navigation purposes or even hyperlinking or saving it as a favorite, every record has a URL that can be accessed. So you see how we also can do navigation using basic HTTP navigation concepts. This is part of the power and the advantages of using REST-based services as well. 00:12:15 If you scroll through here you see multiple records represented. Now what I might do here is add a query parameter. Lets add the $format=json, just to give you an idea of the difference between Atom XML which is what we were seeing before and the JSON format. The JSON format is a little lighter weight, theres less overhead, less tags. Theres basically a lot less overhead to the content thats being transmitted. Therefore, as I said, if youre going to consume the service in JavaScript this might be a better option, but it makes no difference to the server side, it really makes no difference to the programmer unless theyre going to manually parse the OData service which format that its in. Youll see later the SAPUI5 UI elements dont care they support both the JSON format and the Atom XML format. I actually find if Im troubleshooting Ill use the JSON format simply because I find it a little easier to read, particularly using these Chrome plug-ins. 00:13:34 Now you might notice that Im getting a really nice formatted display here with both the JSON format and the Atom XML. This is because Ive added two Chrome plug-ins. If I switch to the source, this is what it looks like normally. Its the same information, just that the Web browser isnt trying to format it nicely for me. I find that for troubleshooting and development of OData services, its really handy to have this couple of Chrome plug-ins. 00:14:05 I added them just a few minutes ago. I added the JSONView extension and the XML Tree extension. Now thats just two examples, Im sure there are other extensions both for Chrome and other browsers that do similar things. These are the ones that I found that are very helpful and therefore Im using them in the demo so if you go to repeat and try to do the same sort of situation in your system, and if it looks really nasty when you test it you know why, you simply dont have these extensions. You can either get the extensions that Im using here or find other similar extensions for whatever browser you prefer to use. 00:14:48 And one last thing that I want to show you here in our OData service. I added the query parameter for the format but theres many other query parameters that we could add. For instance I might add $top=2. What this will do is it now only returned the top two records so this is how we can limit the amount of data that comes back and, for instance, the SAPUI5 table controller uses this to only read a 100 records at a time. And as you scroll it gets the next 100 records. But in order for that to work, we have to be able to tell it where to position in the wuery results. 00:15:32 So we can say give me two records but then add another query parameter here $skip=10 So now Im saying give me two records but skip the first 10 records. Youll notice that it brought back partner ID number 10, so we know that it skipped ahead in the data. And as I said, this is how were able to do that very efficient scrolling even through extremely large amounts of data on the client side, as well just cache small amounts of data well go back to the server and well retrieve the next set of results. And because HANA is an in-memory database, and because it has massively parallel processing, we can rerun that query in real time. Other databases would probably have to cache the results set and then skip around in

Page 18

Copyright/Trademark

that cache results set. 00:16:27 We dont have to do that in HANA even if it were you know, millions of records, and we were doing a skip to record number 500,000 and retrieve the next 100, that query is going to execute very fast each time. This feature of OData, to be able to skip around in the data set, is very well utilized in the HANA world and can help you create responsive user interfaces where you have nice table controls that have the possibility to sort and filter, aggregate, and scroll through extremely large data sets. Thats not a problem for HANA to be able to handle at all. 00:17:03 Now in this unit youve seen how easy it is to create an OData service definition and hopefully youve gotten some idea of what it is like to execute an OData service from the Web browser. 00:17:16 I want to stress that this is not what we would give to the end user to be able to execute this service. Running the service directly from the Web browser is simply something that the developer would use to test this service. 00:17:27 In subsequent units, we will begin to consume this OData service in our user interface and obviously, a finished user interface that simply uses the OData services as the model will be what we, in turn, give to the users.

Page 19

Copyright/Trademark

WEEK 4, UNIT 6 00:00:13 This is week four, unit six: Creating a Complex OData Service. In this unit well continue the exercise from the previous unit and well build upon the existing OData service. Well add an additional table, which will be a second entity. This will allow us to demonstrate how to build associations between entities and how that impacts the OData service at runtime. 00:00:39 So what were going to want to do is take the businessPartners.xsodata file that we had previously and now were going to add a second entity to it. So itll be another table, so you see here that weve added the Addresses table and then weve said as entity BPAddresses. Then we also need to define the relationship between these two entities. We do that by building an association, and you notice that the association here is that the addresses has a principle of BusinessPartners and there is a multiplicity 1:1 between the two. So were saying there is a one-to-one relationship and that the business partner table is the principle, is the parent in this case, and that the key that joins the two tables together, if you will, is AddressId in each of those. so we see BusinessPartners (AddressId) and BPAddress(AddressI). Thats where were telling the OData service which key to join the fields upon. 00:01:49 And when we execute this service, well see that now when we run the base definition, well have two entities. Well also see in a moment once were able to execute this, what exactly it does to the data output. So lets go back to the system and here is our BusinessPartners.xsodata that we had previously. Now lets just change this. 00:02:22 And weve added to it our Addresses table with BPAddresses and weve created the one-toone relationship on the AddressId. Just going back to our basic table, we can see when we look at our data, this is our business partner ID. Inside the Business Partner ID table, there is an address ID, so we dont have to store the address ID directly in the Business Partner table, but weve got a foreign key relationship here. 00:02:54 We look in the Addresses table. We have a series of address IDs and then the associated address. So these could be addresses for business partners, they could be addresses for employees. We have one central address table that services all types of addresses that we need. So now that weve extended our OData service, lets go ahead and save that change and we will reactivate it. 00:03:26 Now we can run our service definition again. So once again, lets just put in our package path: sessiona/00services/businessPartners.xsodata. And now when I access the service definition itself you see two entities. Likewise, when I look at the metadata then we see both the metadata for the Business Partner table and the metadata for the Address table. 00:04:04 So thats one advantage of structuring your OData services this way with multiple entities, is with a single metadata call you get all the introspection of the complete service interface, all the entities. And we also see the entity relationships defined here as well, so this is done in a format that can also be consumed by the client side. And youll see later in SAPUI5 how we can even use these relationships between two entities in a single OData with two table controls. We combine each of the table controls to the same OData service, but then tell it the specific entity that it represents. Then when the lead selection in the parent table changes, it will automatically change the child data that is displayed in the subsequent table control. 00:04:58 Now this does change a little bit how we can access the data. For instance, if we look at the BusinessPartners entity...lets just go ahead and look at them all again. Theres a few too many there. Lets look at just the top two. Now what we see here is that we have additional URLs generated. We have this URL that points to the related data, which would be the BPAddress. 00:05:30 So now we can see if we want the address data for this particular business partner, we can call the URL for this business partner and add BPAddress to the end of it. So for instance, we might come here and we say we want the addresses for just business partner 0100000000. And youve got to take that colon of the end. And now we have the address

Page 20

Copyright/Trademark

data. 00:06:03 So you see how the child data is only available when we drill into the details of the parent. This way we dont have to load all the addresses from all the business partners if we look up just the business partner data. Likewise we cant just go and call this service and look up the business partners. 00:06:23 So if I would come here and try to access just the addresses directly, I have a few too many, once again ?$top=2, and there we have a listing of each of the addresses. Though it doesnt make a whole lot of sense without the link back to the business partners, but we can get a listing of all the possible addresses if we need to. 00:06:52 So that gives you a little more realistic example where we have an OData service that combines two entities. Let me show you one other example here. This is an even more complex scenario. In this situation, we have a view, this is actually a SQL view, being put together with an analytic view. So we have purchase order header data and then we have this purchase order work list, which includes item data. 00:07:26 The process is basically the same, this is a one-to-many relationship. So for a single header record, youd have multiple item records, which makes good sense. And in this case we have views, so I did want to show you that when we have views we have to specify the keys as well. Because it cant just go and just look up the view definition and know what the key fields are. So that is the optional addition I spoke of earlier. 00:07:58 Otherwise, this is just another example. This is actually the OData service that sits behind our purchase order work list. So the purchase order header entity fills this first table and the purchase order item entity is bound to the Items table. And you notice what happens here when I choose the lead selection on the header it loads all the item details down here 00:08:29 And as I described we didnt have to do any special programming in the user interface to make that possible. Thats all done because the user interface is able to read the entity relationships that we defined in the OData service. And because we bound both of these table controls to the same OData service, just two entities in that OData service, they're related. They understand that relationship, that association from the OData service, and we get the same relationship created between the two UI elements. 00:09:00 So this has given you some idea of some of the more advanced features that we have in OData services. Of course theres many other features, other URL parameters that can be specified, most of which will be generated by the user interfaces we will see in the next unit. But if you want to research them further I strongly recommend that you look in the SAP HANA developers guide where all of the parameters and permutations of the OData service definition is contained, as well as all the URL parameters that can be passed into the service at runtime.

Page 21

Copyright/Trademark

WEEK 4, UNIT 7 00:00:13 This is week four, unit 7: Calling an OData Service from the User Interface. In this unit, were going to put together everything weve learned so far in this week. Were going to take what we learned about the user interface technology and what we learned about creating an OData service and now create a new user interface that will consume and present that OData service. 00:00:35 This is the complete round trip. Is one thing to learn about creating OData services, but until you can really extend them to the user interface and present them to the user, you dont have the complete story. This is why I really like combining the user interface portion together with the service creation portion of any sort of workshop. 00:00:58 So what were going to do now is were going to take the SAPUI5 project that we created previously in this week and well extend it, well copy the index.html and well only have to make a couple of minor changes to it. One thing is that well be using a table control, so well have to extend the UI libraries in the bootstrap to also include the UI table library. 00:01:24 Well also have to change the view because well have a new view in this application. And what we should have at the end of this project is we should have a nice table control that displays the data from our OData service and has built-in sorting and filtering and also the ability to scroll through the data and load the next batch of data as we move every 100 records into the data. 00:01:52 So lets go into the system and I have my Exercises_UI project. Inside this project, I just want to say New>View. This will launch the SAPUI5 wizard, allowing us to create both a new view and a new controller with all the proper setup and specification. So we want it to be inside our existing project so itll still put it inside the WebContent/exercises_UI folder .And I want this to be my...xsodataTest will be the name of the view in the controller and I still want it to be a JavaScript-based development paradigm. 00:02:32 So well say Finished and its now generated a new empty controller and view for us. And before we can do anything with this empty view and controller we need to copy our index.html 00:2:48 Copy. And then well just do a paste and the new file will be named...well just name it .xsodataTest.html So here we want to add our SAPUI table and then we can change this. Doesnt really matter what the ID is, but I like to change the ID so it matches my view name. So it would be idxsodataTest. Far more importantly is that we change the view name here to be xsodataTest. Therefore this html page will load correctly the new view weve just created.

00:03:43 So our html is fine. Our controller...we still dont need to put anything in the controller, you might have thought, Oh, Im going to need to finally use the controller, Ive got some events. But the nice thing about using SAPUI5 Ive described a couple of times is that because Ive combined the OData services, a lot of the standard events of the UI elements are also already implemented inside the UI element. So that means that the sorting, the filtering, and the scrolling are all things that are implemented for you and will automatically know how to call the OData service with the corresponding URL parameters. Youll see that once we've got our application running. Ill use some developer tools to show you whats going on behind the scenes and show you the URLs that are being generated. 00:04:35 So here...oh, I lost my template. One second, let me come back over to my other project because you dont want to watch me type all of this but I will go through it and explain to you what all of this code is doing. 00:04:55 Most of it is very straightforward so in our createContent, this is where we render our user interface. The first thing that were doing is were declaring a model object, were saying it is of a type, model.data.00DataModel. At this point we need only point it to the URL of our xsodata service. Notice that we dont specify any entity at this point. You create the model for the OData service itself and not any of the entities inside there.

Page 22

Copyright/Trademark

00:05:27 Youll see in just a minute when we bind the table to that model, only then will we supply the entity and thats how we can have a single model with multiple entities and therefore multiple tables tied to the same service, just different entities in that service. 00:05:44 Next the rest of this is really just for rendering the table so here Im creating a new table control. I say I want 10 rows visible at a time. I set a title into that table and then I go about creating all of the columns for the table. Now, one thing that I could have done here that would have been a little more eloquent but would have been a little harder to understand from a source code standpoint is that I could have actually used the metadata of the OData service, made a call, gotten the metadata back, and then looped over the metadata and created my columns dynamically. 00:06:18 Now if this were a real production program, I would do that, personally, so that the columns of the table dynamically adjust to whatever columns are available in the OData service. 00:06:29 But for the purpose of a learning exercise I thought it was simpler if we just hard code the column names and the bindings to the data. So this is not necessarily what you want to do because I am assuming the names of the columns dont change and Im hard coding the column descriptions so theyre not language-independent. 00:06:50 If we call them metadata, we would automatically get the OData service, which knows which language were logged into the Web site with and uses that to look up the column definitions and descriptions and pass them back in the metadata. So we would have a nice way of doing this dynamically, but like I said, that would have complicated the example a bit more and I didnt want to do that. 00:07:14 After weve added all of our columns we can set the model as the model for the table. After that, we can create a sorter. A sorter will just tell the OData service and the table which columns should be sorted by default. Were going to have it automatically sort by the PartnerID, the key column of the table. 00:07:38 And then we tell the table bindRows. And at the point where we bind the rows, thats when we give it the entity. So the tables already associated with our OData service because weve given it the model, which is just a local representation of the OData service and now it knows exactly which entity its bound to. 00:07:58 And this is also the point where we can pass in the sorter and it will put that sort criteria into the first request to the OData service so the data comes back already sorted. Here were just getting the number of rows so we can ask the table bindings the length of its rows property and that will tell us how many rows its currently displaying and then were putting that into the title. 00:08:26 Then we return the table itself. So I think we got a good user interface here now. Ill save all of my open files and I will commit everything back to my repository. And now I will activate all these new files and were ready to go to the user interface and have a look at this new application. 00:08:59 Workshop/sessiona00/ui/Exercises_UI/WebContent and well just change which html page well load. We want the xsodataTest.html. And here you see, heres my table control, 10 rows displayed and the ability to scroll into the data. Its sorted by partner ID. I could change the sort order, sort by Email Address instead. I can filter and come here and sort by all AG companies. So you see the sorting, filtering all working. 00:09:54 Now what might be interesting is to see what is going on behind the scenes when this is taking place. Now this is why I like to use Google Chrome, of course we support Firefox, Chrome, Internet Explorer, all the major browsers, with our user interface technology. 00:10:14 I like to test and develop in Chrome because I like the built-in developer tools. So without any extensions, just a standard feature of Chrome is the ability to go to Tools > Developer

Page 23

Copyright/Trademark

tools. And one nice thing is you've got this little red X down here that shows you if there any syntax errors. These are actually not errors. SAPUI5 always tries to query for the most specific text bundle, so it found an English text bundle but then it tried to find an English US text bundle, which we simply dont maintain that on the server side, we dont maintain the difference between English and English US. So when it made the request for that resource we got a 404. 00:10:57 But if I had had any syntax errors in my applicationoften with SAPUI5 or any JavaScriptbased html user interface design environmentwhen you make a syntax error in the JavaScript it will often cause the entire page not to render and youll just get a blank screen. Without some of these developer tools to show you where your syntax error is or why youre getting it, it would be very difficult to find your errors. 00:11:26 And I know that there are similar tools for other browsers, Firefox has some extensions that will add tools similar to this. Some colleagues use Internet Explorer and use HttpWatch, which is a third-party tool that you can purchase, but I like the Chrome tools because theyre already built into every version of Chrome. 00:11:50 Now one of the other things that we can see here is that I can go to Network and this will show all the requests from the client to the server. This is really nice for looking at our OData request. So if I would change the sort here to say sort by Partner ID, then you see that theres been a request to the server. 00:12:09 And if I go into this request, let me just show you some of the details here, its making a request to our xsodata service, our business partners and it says $skip=0&$top45, so it knows we only have 45 records or scroll bars at the top so thats why we got the skip0. But then the user interface element automatically added the orderby = PartnerId descending. We didnt have to program that on the client side, we didnt have to do any programming on the server side. The user interface knows how to build these additional calls to the OData service. And this is part of the value of using OData services and using the SAPUI5 controls to consume them. 00:12:56 Here Ill do a filter now, you see weve got another request to the server now. And weve added the $filter, LegalForm=AG and once again we didnt have to program any of that; its all handled for you. The OData service is dynamically performing the query on the server side and on the client side the user interface element takes care of that event handler for us. 00:13:23 Now, one other thing that Ill show you while Im in here. in addition to just seeing the URL and, of course, the headers, I could also look inside the response object and even take a peek inside the data. So this is an excellent troubleshooting tool for when you are having problems. Ill intentionally go back to my UI5 view and Ill make a mistake here. 00:13:51 Let me incorrectly reference my OData service and I will save this and now I will reactivate this. Now I do this on purpose and make this mistake on purpose for two reasons. First, I want to show you something. If I come back to the user interface and I just refresh, Im still getting my data and you might be wondering well, he has the wrong OData service so why is he getting his data? 00:14:25 Well, thats because of .js files. JavaScript files are cached on the client side. So anytime you make a change to the view or the controller we have to go in and we have to clear our browser cache on the client side in order for those changes to be picked up. So in Chrome theres these nice tools, Clear Browsing Data, and I can say The Past Hour because I just created these objects. 00:14:50 Now when I refresh I dont get any data. If this had happened initially I might be looking at this going, Oh, I got my table, it rendered correctly. Why do I not see any data? And this is also where the developer tools are very handy. So Ill go ahead and Ill turn on the Developer Tools and Ill refresh the page. Youll see a lot of loading here because we load additional libraries and text property files and everything.

Page 24

Copyright/Trademark

00:15:18 Right away I see that something's wrong because my OData service calls are all failing, Im getting a 404 Not Found. So right away, that metadata call and then the OData service call itself I got a 404 Not Found so I know I have some problems and based upon the status code. I know I probably put in the URL incorrectly as opposed to an authentication problem or some other HTTP error code. 00:15:43 So these developer tools are very important to troubleshooting because when you start doing client-side development you cant expect that Im going to get a syntax check on the server side for something like this. The code isnt really being interpreted until it reaches the client side. The same thing for if I would create some sort of syntax error. 00:16:05 We could do a few scans on the server side and look for problems, but it has to be really badly semantically incorrect. If I just reference the wrong object or I reference an initial object or something like that, that cant be determined until runtime. That means syntax errors often arent found until they reach the client side. Therefore you need good troubleshooting tools on the client side to be able to work through those kinds of problems. 00:16:31 In this week we seen the basics of our user interface technology that we make available with HANA. Weve also seen how we can create OData services using the generic OData service generation framework and weve seen how we can combine those two together. 00:16:50 In the next week, well continue the concept of building services and well look at how we can go beyond the limitations of the built-in OData service generation framework. What if you want to combine multiple tables together in a way that we cant describe with entities? What if you want to do CREATE or UPDATE operations? Or maybe you want a custom body format or custom HTTP headers? In these cases, you wouldnt use the OData service generation framework, but you would custom code your own REST-based services using server-side JavaScript and thats what well see in the next week.

Page 25

Copyright/Trademark

www.sap.com

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.