First of all you might be wondering why we are making a big deal about a patch. Normally a patch or revision between SPS levels for SAP HANA would likely only contain bug fixes. However for the development tooling we are now architecturally somewhat separated from the SAP HANA core which allows us to also ship new functionality in certain patches. This is key because there were several really good features which just didn’t quite get finished in time for SPS 12. Now we are able to ship them to you without having to wait until the next major release of HANA at the end of the year.
In this blog I’d like to point out a few of the differences you as a developer will encounter with this new patch and also how you can take advantage of some of the new features.
The first item I’ve seen some people confused about is the naming of Patch 1. In the above announcement blog and the documentation, the name Patch 1 is used. However if you look on the service marketplace at the patch download its actually listed as patch 3:
There is a Service Note that actually documents that fact that what we are calling SAP Web IDE for SAP HANA SPS 12 Patch 1 is technically numbered as Patch 3.
This note is useful because what we refer to as SAP Web IDE for SAP HANA SPS 12 Patch 1 is actually several separate components from the SMP with different patch levels:
The final piece of the puzzle comes when you look in the SAP Web IDE for SAP HANA itself in the Help->About menu option. There you will see a completely different version number. The number you want to see here is 3.12.25 or higher in order to have the fixes and functionality in what we are calling SAP Web IDE for SAP HANA SPS 12 Patch 1.
New Role for Using the SAP Web IDE for SAP HANA
If your system was recently upgraded and you logged into to see a “Not Authorized” message; don’t panic. You haven’t been demoted. This patch level just comes with better security checks for using the development tools. There is a new role check and in order to continue using the SAP Web IDE For SAP HANA, you or your security admin needs to create a role collection and assign this to your user.
This can be done by an administrative user logging into the XS Advanced Administration tool and going to the Application Role Builder tile. After this patch you will see a new application role named webide*. It has two role templates – one for the Web IDE Developer and one for the Web IDE Administrator. The Web IDE Administrator is important because it is needed to run the new SSL Certificate Administration and Space Enablement admin tools we will talk about in a second.
Choose the Configure Role Collections option in the bottom right corner of this tool. Then create a new role collect (or two if you want to separate the two templates). My system is private, so I just created a single role collection named WEBIDE_DEVELOPER which contains both of the role templates:
Now you can go to the user administration tool in either the XS Advanced Administration or the older SAP Web-based Development Workbench Security tool. Assign the new role collection to all of your SAP Web IDE for SAP HANA users as appropriate.
With XS Advanced, we introduced the concept of Spaces and Organizations. This is essentially a concept to better separate, control, and scale applications and services within the XS Advanced layer. The initial version of the SAP Web IDE for SAP HANA in SPS 11 didn’t really support separate spaces at all and in fact only allowed development in the SAP space. The SPS 12 initial version improved things a bit by at least allowing development in a single separate space which could be chosen as system installation or upgrade time. With the Patch 1, we more fully support multiple spaces for development.
The first part of this change is the Space Enablement tool. No longer must an admin choose the development space during upgrade/installation. Now one or more spaces can be made available for development by running the Space Enablement tool. This is a new administration tool that gets installed with the SAP Web IDE for SAP HANA. Look at your XS Applications either from the command line (xs apps in the SAP space) or via the web based XS Advanced Administration tool to find the port/URL which this new tool is running on.
This tool is pretty simple. You can see the status of all the spaces in your system or you can choose the space you want to use for development and Enable it. This also solves a problem we had with the initial version of SPS 12. This enablement creates the di-builder service in the development space. In SPS 12 initially this service was created automatically upon first project creation in the SAP Web IDE for SAP HANA. However if something went wrong (for instance the user didn’t have proper authorizations for the space), it was very difficult to troubleshoot and/or rerun. Now this enablement can be redployed in a given space at any time via this tool.
The other aspect of this enhancement is that now that we can have multiple development spaces in use on a single system, we must specify the target space in the project properties in the SAP Web IDE for SAP HANA. Just right mouse click on the project and choose Project Settings and then switch to the new Space tab in the settings editor.
SSL Certificate Administration Tool
Also new in this patch level is an administrative tool to help with the upload of HTTPS certificates. This is necessary for making outbound HTTPS requests from the SAP Web IDE for SAP HANA. Most commonly this functionality is needed when communicating with the external Git server. Often if you are running your own Git server within your enterprise, you will need to upload its certificate or your internal CA using this tool before we can connect to Git from the SAP Web IDE for SAP HANA.
HDI Deploy 2.0
The last new feature I want to detail is the fact that Patch 1 comes with the HDI Deploy version 2.0. This is the Node.js module that runs during the Build of an HDB module. This new version includes several enhancements especially when dealing with cross container and user provided services.
One of the problems with HDB module usage of cross container and user provided services in the past was that you had to hard code the service name in the design time files like the hdbgrant or hdbsynonymtemplate. This was especially not nice when dealing with services that might have been created by the Web IDE for SAP HANA itself since they have the username and workspace in them. Not only was this name long and nasty looking, but coding it within your development objects broke the ability to clone the project and test run it under a different user.
HDI Deploy solves this problem by introducing the concept of SERVICE_REPLACEMENTS. Basically this is a way to define a logical service name in the mta.yaml and use it in the various development objects. At build or deploy/installation time, this logical name will be replaced by the actual service name.
For example, we have have a single MTA project with two HDB modules – core-db and user-db. From core-db we want to access user-db. Therefore in the user-db container resource we define a property which can hold the generated service name:
Now in the core-db module definition of the mta.yaml when we list the user-container resource dependency we also add the SERVICE_REPLACEMENTS section. We add a logical service name of hdi-user-service which maps to the user-container-name property (which in turn will be set to the generated service name).
This means that in the development objects themselves, we no longer have to hard code the container service name. For example in our hdbsynonymtemplate for the user-db access from the core-db the target grantor is hdi-user-service (the key from the SERVICE_REPLACEMENTS) which gets replaced with the actual service name at build/deploy time.
A similar usage is when you want to access an existing Catalog schema via User Provided Service. You use the same setup when you define the resource for the user provided service:
And in the requires section of the consuming module, you again use the SERVICE_REPLACEMENTS to define the logical service name:
This logical service name is again used in the development artifacts like the hdbgrants and replaced at build/deploy time:
The final HDI Deploy 2.0 feature I want to discuss is the concept of default access role. Before HDI Deploy 2.0, you couldn’t control the access grants to the container technical user. If you created analytic or structured privileges within your container, the technical user never had access to these privileges by default. This meant a manual grant to these technical users. This was not so nice because it involved a manual step after installation of an MTA, but also because it required knowing and working directly with the HDI container technical name (often a GUID like generated string of characters and numbers).
With HDI deploy 2.0 we now give the developer the ability to define a role which details what the technical user will be granted upon build/deploy. The role name must be exactly default_access_role, therefore we recommend putting it in a separate folder where namespaces are deactivated. You then define an hdbrole design time object like any normal role. Now you as the developer have the control and can limit access. For example you might not give the technical user Insert/Create/Update access to your tables; but instead only Execute to procedures. Inside the procedures you have definer rights and you have the insert/update/create operations. This further limits access forcing all modification operations to have to pass through your procedures as a pseudo API even for the container execution technical user.