Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 


This is Part-3 of a 3-part blog post series on detailed step-by-step installation of SAP Data Intelligence on-premise v3.0/3.1 on Microsoft Azure. I would like to thank skugan.venkatesan for his contributions in helping me with this blog post. This blog post explains the steps needed to expose SAP Data Intelligence for end user access.

The Part-2 blog post covers the preparations on the Kubernetes cluster and the SLCB tool(Software Lifecycle Container Bridge).

The Part-1 blog post covers the system setup required to start with SAP Data Intelligence installation.

Install NginX Ingress Controller

Now that SAP Data Intelligence has been successfully deployed on the Azure Kubernetes Services, let’s perform the final setup to access SAP Data Intelligence. The steps here are quite typical for accessing any web application/APIs deployed on Kubernetes.

It is imperative to expose an external IP address for accessing SAP Data Intelligence in the Azure Kubernetes cluster. Therefore, in the last step, post all the settings- the application will be exposed to the internet. If so required, the Azure built in security mechanisms like Network Security Groups can still be used to control the access.

Here an ingress controller will be setup, which shall act as a reverse proxy for Kubernetes. In the previous parts 1 & 2 of this blog post series, the helm package was previously installed in the Jumpbox. Using Helm package manager, Nginx-ingress controller will be installed. Please find below the command to install the ingress controller.
helm install stable/nginx-ingress --namespace kube-system


By default, TLS (Transport Layer Security) is enabled. Now let’s check whether a pod has been initialized on which the ingress controller would run (i.e., ingress controller would be deployed on the Kubernetes Service). Please execute the following command to get all nodes in all namespaces.
Kubectl get nodes –allnamespaces -o wide

It is observed that under the “kube-system” namespace the Ingress controller has been deployed. And It is also in “running” state. So, all is good till now.

To check on which Port ingress controller runs, execute the following command. The ingress controller that we had installed runs on port 443 (for HTPS) and 80 (HTTP).
kubectl get ingress –all-namespaces

Since DI needs to be exposed to the internet, the ingress controller is created as an External load balancer. Please login to Azure Portal- there you will see that an external Load Balancer being created in Azure, this would already be configured with the right backend pools and the required routing rules. Finally a public IP address would also be assigned automatically.

Please navigate to Azure Portal > Resource Groups > MC_<ResourceGroupName>_<ClusterName> > Select Load balancer.

Now there will be 2 resource groups with identical names as soon as you deploy the Kubernetes services. Please navigate to the resource group starting with prefix of “MC”, and select the ingress load balancer. The other load balancer is for the for SLCB, and this has already been explained in Part-2 of this blog post series.

As mentioned in the above screenshots, the IP address of the load balancer can be retrieved by navigating to the portal. The other method is to execute the following command. This command will retrieve the IP address of the ingress controller and store it in the public_ip variable. This variable can then be printed with the echo command.
public_ip=$( kubectl -n kube-system get service -l app=nginx-ingress -l component=controller -o jsonpath="{.items[0].status.loadBalancer.ingress[0].ip}");  
echo ${public_ip}


Assign DNS to the Ingress controller load balancer

Now that external IP Address has been assigned to the load balancer, we can proceed to setup a DNS for this IP address. Here the DNS will be setup by using Azure’s in-built DNS services.

There are two ways to assign the DNS name to IP address. Execute script from the SAP Data Intelligence installation guide or go to the Azure Portal and change the settings in there. Here the 2nd approach will be taken.


Now that DNS has been assigned to the Load Balancer IP, let’s create a self -signed certificate. Please Note: In production use cases, it is recommended to use proper Certificate Authority signed certificates. For this scenario, let’s proceed with the self-signed certificate.

Let’s create a self-signed SSL certificate and deploy it to the cluster. Change the <FQDN> to the full domain name defined above, for example and the <namespace> to the namespace chosen during the SAP Data Intelligence installation. FQDN is the DNS name that you had assigned to the load balancer in the previous step.


Generate certificate with OpenSSL

Install OpenSSL if not already there in your Jumphost- as this will be used to create a self-signed certificate. As a first step, let’s create a private key. Please execute the command below to generate the private key.
# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls.key -out /tmp/tls.crt -subj "/CN=<FQDN>"

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /tmp/tls.key -out /tmp/tls.crt -subj "/CN="

As a first step, the private key for the certificate is created and saved in the /tmp/ folder under the name tls.key. This key will now be used to generate the certificate.
# kubectl -n <namespace> create secret tls vsystem-tls-certs --key /tmp/tls.key --cert /tmp/tls.crt

kubectl -n dataintelligencekubes create secret tls vsystem-tls-certs --key /tmp/tls.key --cert /tmp/tls.crt

Now the certificate has been generated. The next step is to create an ingress rule using a YAML template. The YAML file is used to dictate how applications behave deployed in a Kubernetes cluster.

Let’s create a configuration script for the ingress and save it on the Jumpbox. The script listed here in the Installation Guide (Point #4) has been improved with an annotation. Please follow the steps given below. The filename used in the steps below is vsystem-ingress.yaml- but any other file anme can also be used.

Do NOT replace the <DNS_REPLACE> in the below mentioned script.
apiVersion: extensions/v1beta1
kind: Ingress
name: vsystem
annotations: nginx "true" HTTPS "true" "500m" "30" "1800" "1800" "16k" "true"
- hosts:
secretName: vsystem-tls-certs
- host: <DNS_REPLACE>
- path: /
serviceName: vsystem
servicePort: 8797


Execute the following commands to activate the ingress. Replace the <dns_name> and <namespace> according to your previous choices:

<dns_name> = The DNS name assigned to the load balancer.

<namespace> = Kubernetes namespace given during SAP Data Intelligence installation in part-2 of this blog post series.
# export dns_domain=<dns_domain>

export dns_domain=

"kubectl apply" command is used to apply a configuration to a resource by filename. Let's apply the vsystem-ingress.yaml file configuration to the NGINX-INGRESS resource.
# cat vsystem-ingress.yaml | sed "s/<DNS_REPLACE>/${dns_domain}/g" | kubectl -n <NAMESPACE> apply -f –

cat vsystem-ingress.yaml | sed "s/<DNS_REPLACE>/${dns_domain}/g" | kubectl -n dataintelligencekubes apply -f -



Now let’s try to access SAP Data Intelligence through the browser.


Log in using the credentials defined during the installation.


That’s all, folks! The installation is complete- SAP Data Intelligence can now be accessed via the browser. Hope you followed through all the 3 blog posts and were successfully able to follow all steps listed here.

Questions? Post as comment.

Useful? Give a like and share on social media. Thanks!