Connecting the SAP HANA Service on Cloud Foundry to SAP Analytics Cloud – The lazy approach, pt1
This series of blog posts will cover how to connect an instance of SAP Cloud Platform, SAP HANA Service (Cloud Foundry) with SAP Analytics cloud to consume Calculation Views in an HDI container.
If you are looking to connect an on-premise SAP HANA system to SAP Analytics Cloud with XS Advanced, check this series of blog posts.
I will be replicating these steps in different machines or, even worse, instructing people to do this. So I have streamlined this process as much as I could. In other words, this is the result of my being both lazy and having a short attention span (especially when a task is rewarding yet boring…).
- You have admin access to your Cloud Foundry sub-account
- You have admin access to an instance of the SAP HANA Service (also translates to: no, you cannot do this with the trial)
- You have installed the CF CLI (https://developers.sap.com/tutorials/cp-cf-download-cli.html) and the Multi-Target Application Cloud Foundry CLI Plugin (Downloaded from here https://tools.hana.ondemand.com/#cloud and installed as per https://docs.cloudfoundry.org/cf-cli/use-cli-plugins.html#plugin-install)
- You have WinRAR installed and it allows you to modify the files without explicitly extracting them
- You have a calculation view in an HDI container. I have a sample repository that you can simply build here if you want to just test this: https://github.com/SAP/hana-xsa-calculation-view-anonymity/
This is one of the reasons why I added the disclaimer. I’m using the on-premise adapter for cloud foundry. I did not see a reason not to, but if you have a valid one, I’m listening.
Download it from here:
(Yeah, I did that on purpose)
This is where WinRAR becomes important. WinRAR allows me to modify the MTAR without unpackaging it. Which means that if you do not have the builder installed, it does not matter. It’s also one less command line.
|If you cannot do this with WinRAR, it’s not so bad. You will need to download the Multi Target Application Builder from here: https://tools.hana.ondemand.com/#cloud . If this is your case, extract the application into a folder and proceed with the modifications starting with Change the tenant mode … .|
This is the zip file:
And it has an MTAR in it:
Double-clicking on that one:
This is the actual application you will deploy.
You will change some configurations that affect the way the application interacts with the UAA service in your Cloud Foundry subaccount. You will also change the CORS configuration so that your SAP Analytics Cloud connection is not rejected.
Start by xs-security.json.
The following overrides the default mode, “shared”. The shared mode is used for multi-tenancy applications, in which different subaccounts subscribe to the approuter. Each subaccount would have its own URL identifying them as a tenant, so some wiring is needed in the approuter through environment variables TENANT_HOST_PATTERN and SAP_JWT_TRUST_ACL. See the help if you need to use UAA in multi-tenant mode.
In my case, I had to look at the xsuaa binding for another existing application, and fetch the URL for the UAA service:
And use the placeholders so that the URL could be derived from the calling app:
Which in my case resulted in blurredpart-prod-(.*)-dev-xsahaa-entry.cfapps.(.*).hana.ondemand.com
This blog post by Bhoomika Agarwal helped me understand this: https://blogs.sap.com/2017/11/16/guide-for-user-authentication-and-authorization-in-sap-cloud-platform/
I am doing this because I do not have/need a multi-tenant installation.
Right under the “xsappname”, add:
If you are deploying this in multiple spaces in the same subaccount, you will need to change the xsappname.
Save the file and go back to edit the application. Say yes to keep your changes:
You will need the hostname of your SAP Analytics Cloud tenant. You will find it in the URL:
Back to the WinRAR: Go into the META-INF folder. Edit the mtad.yaml.
Add the host (without “https://”), remove the port and add the protocol
Save the file. You’ll be asked to confirm to save the changes to the archive.
Of course, the answer is Yes.
Close that window. The archive containing the mtar will also ask if you want to save the changes… Guess the answer!
Make sure your changes are getting saved… guess I don’t need to explain why this is important, do I?
Somewhere you can access from the CLI console.
|If you had to decompress the MTAR to edit the files, you can build it again with the mta_archive_builder (requires Java to be installed) and a command like this one: java -jar mta_archive_builder.jar –build-target=CF build|
You are now ready to deploy the adapter.
Get the endpoint of your subaccount:
Log in to the CLI and deploy the archive:
cf login -a <<endpoint>> cf deploy <<mtar>>
I promised a lazy installation but I am using the CLI? Yes, because this file is heavy and I prefer a verbose console when Murphy’s law applies.
You now have a running application. On clicking the endpoint for xsahaa-entry…
…you should get to the authentication splashscreen
|If you used the multi-tenant setting, check your UAA URL is being called in case you need to adjust the TENANT_HOST_PATTERN variable|
And this is the next thing you will configure… in the next blog post.
But, wait! Some community service here… Is this helpful? Show some appreciation by hitting the like button on the top! (and be sure to do that with any other author going out of their way to publish their findings 😉 )
Here’s the second part: