We are working with lots of mixed-scenarios, meaning that our data is stored in BW and exposed as Calculation Views for further HANA native processing. When we became aware that HANA modeling is moving away from HANA Studio and into Web IDE for SAP HANA with quite some new features, we were excited at first. This blog explains, why we are nevertheless staying in HANA Studio for the time being.
First off, SAP made it clear that the next “major” HANA release will remove XS Classic (XSC), see SAP Note 2465027. This also means that the HANA Modeler within HANA Studio is deprecated, already there are no new features but only critical bugfixes. The following picture shows the transition:
While XS classic runtime is delivered with the HANA DB out-of-the-box, you need to install and configure the XS advanced (XSA) runtime if you want to use the “Web IDE for SAP HANA” (XSA WebIDE). By the way: don’t confuse it with the “HANA Web-based Development Workbench” (XSC WebIDE), which you won’t miss, because you probably did not know that it existed anyway.
We thought: great – the Web IDE is browser-based, so no more HANA studio maintenance necessary. Also, there is no more proprietary HANA repository, but a shift to the well-known GIT instead. Very nice, but wait… what does that mean for deployment?
Deployment
Up until now, we created Calculation Views in HANA Studio, and then deployed them to our other BW systems simply by using transaction SCTS_HTA (HANA transport for ABAP – HTA). However, this only works with packages of the classic HANA repository. SAP announced that HTA will work within the new environment as well, however this support is only planned for BW/4HANA. If you are still using BW 7.x, like we do, then you are already massively discriminated at that point. Sure, you could go for other deployment options – see picture below – but none are as convenient as HTA from a BW perspective.
Migration
If you want to reuse your existing HANA models within WebIDE, then you have to follow SAP Note 2396214 first. For that reason, we converted all our Attribute- and Analytic Views to Calculation Views and also adapted our Script-based Calculation Views to make use of table functions. By the way, this is a step that is recommended in any case – even if you are still far away from WebIDE usage – as it optimizes the runtime performance. But back to our POC – so now we had all our objects ready for moving into WebIDE, and to do so we ran the command line tool „xs-migration”. It reads the content of a Delivery Unit – which you need to prepare first – and converts all included objects to the new HDI-compliant format. The HANA Deployment Infrastructure (HDI) is basically the framework for handling DB artifacts within WebIDE. However, this first conversion step went rather well, at least after SAP fixed a bug that was obstructing us. The next step was to import the converted objects within WebIDE. Unfortunately, despite all efforts this just failed for us. Within an OSS incident we once more learned that the software version you are using, really is essential. That is because some features that our Calculation Views would have required, are just not supported with WebIDE on HANA 1. We were suggested to upgrade to HANA 2, which was not supported by our hardware at that time.
Cross Schema Access
So now it was already clear that you need to have BW/4HANA on HANA 2, if you want to utilize the WebIDE reasonably. Somewhat disillusioned we started to play around within WebIDE anyway. We created a simple Calculation View and wanted to include an External HANA View, generated out of BW. Immediately we learned that this is not as simple as it used to be anymore. The reason is that all HDB artifacts are kept within a HDI container, which technically is an isolated DB schema, see picture below.
If you want to access data from another schema like _SYS_BIC (where all the legacy Calculation Views are stored) or some other schema YXZ (could be your ERP system), then you have to go through Synonyms. At the time we ran our POC, it was necessary to manually create Synonyms for every single object involved. Also, it was required to setup a user-provided service through command line tool for that purpose, which is all but user-friendly (why can’t it be done via XSA Administration?). At least there have been improvements, so meanwhile Synonym generation can be done automatically from within the Calculation View editor. Still, if you want it the other way around – that is to access HDI objects from outside – then you need to set appropriate authorizations. For that purpose you will have to make yourself familiar with. hdbrole, .hdbgrants and all that comes with it.
Summary and recommendations
For HANA database development there is no way around WebIDE in the near future.
On the plus side, it runs within the browser, has an integrated GIT client with source control and versioning, there is an all-or-nothing build approach instead of individual object activation (so no more broken single objects), there is a graphical CDS editor and additional Calculation View nodes (graph, intersect, minus) are available among other new features.
On the negative side, it’s not simply the user interface that changed, but the whole repository and deployment infrastructure. This comes with the loss of backwards compatibility and also with complex new access scenarios that need to be taken into account. So, my personal recommendations are:
- Migrate Attribute-, Analytic- and Script-based Calculation Views now
- Familiarize with HDI and new security concept
- Start exploring WebIDE and its modeling tools
- Experiment with GIT teamworking scenarios
- Consider switching to XSA with BW/4HANA and HANA 2