1. Why?
When you download and run the hxehost virtual appliance it start with some predefined configurations :
- by default it is supposed to work in private LANs if you don't deploy the appliance in a cloud provider so it comes with routing_mode=ports (every app deployed gets a new port instead a new hostname in a domain)
- the VM appliance creates on the first start a SSL certificate which is self-signed (is not trusted by browser or analytics clients)
- you can't disable (easy) the SSL mode for app hosting
As a conclusion, for you it is hard to publish the downloaded, runnable VM to internet from 2 reasons :
- it is not easy to change the SSL certificate with anoter one that is issued by a trusted Root CA
- it's hard to route/maintain public ports to internal ports (and on HXE they may change also for apps)
- it is almost imposible to test HXE on-prem xsodata data integration with cloud analytics SaaS (any kind from any provider) beacuse of data access
Also if you are planning a multitenant application, the xsodata compatibility mode has no real option to filter the services based on the tenant column differentiator.
Because I'm a developer and I know to solve any problem with a custom program
🙂
I wrote a proxy app in dotnetcore3.1 for relaying requests to XSODATA backends.
Tha plan is that you publish a IIS Web server to the internet, not directly the HXE system and you access the data via the proxy endpoint that embeds the Tenant ID (a Guid of course) in the Url and this app has a custom defined SSL certificate when you create it.
2. Features of the developed app
- filter by tenant column name via route parameter ( http(s)://base_href/tenant_id/ replaces the url to one xsodata service)
- memory cache for request responses with 1 minute cashing of response
- forward odata query and ads the mandatoru $format=json required in HANA 2.0 xsjs compatibility and the $filter=tenantcolumn eq 'tenantid' soyou expose only the desired data
- always get json format response
- reduce d.result object of xsodata to plain json array
- replace the base_href of the __metadata objects with the new url of the service that proxies
3. Code is available on github.com
Prerequirements :
- SAP HANA Express 2.0 VM or docker container
- Widnows IIS for hosting or another runtime for dotnetcore3.1
Repositories for test :
A test db for hana with xsodata service:
https://github.com/radu103/hana-generic-repository-test-db
The C# solution for the proxy :
https://github.com/radu103/dotnetcore-api-http-proxy-for-https-source
4. Conclusions
The speed is outstanding because of the .NET Core MemoryCache (Duration=1 minute for each url that was requested to xsodata backend) and the Node.js package from Hana XSODATA is really flexible with running the xsodata queries
With cache the response is around 5 ms* !
Without cache the response take around 100 ms* !
(* for a small dataset of 100 rows)
The cool thing now is that I can create pretty dashboards online with SAP Analytics Cloud without exposing my HXE system on the internet because i can get my data via odata or json data source adapter !
