In this blogpost I want to share details of the two different ways HDI (HANA Deployment Infrastructure) containers can be developed and integrated within SAP Datasphere.
The official SAP documentation on this topic can be found here Exchanging Data with SAP SQL Data Warehousing HDI Containers in SAP Datasphere.
With HDI develpoment User Provided Services (UPS’s) are a necessary evil. What this documentation doesn’t mention is that there are in fact two types of UPSs that can be used in this development methodology.
- Procedure (P)UPS, by copying & pasting the UPS definition from Datasphere creates a PUPS
- Regular UPS, remove the procedure syntax from the UPS definition and you have a UPS.
The TL;DR of this is don’t create a PUPS create a UPS. Remove the procedure references, this will reduce complexity.
HDI Data Exchange Options
Developing with SAP Datasphere is possible in three distinct places.
- Native Datasphere Space Objects
- Open SQL Schema (OSS)
- HDI Containers
In figure 1.1, I have tried to illustrate that not all objects are accessible between the different development environments. All the objects physically live inside Datasphere. If you want to access the Open SQL Schema (OSS) objects then only OSS tables and OSS views can be seen within the Native Datasphere environment. This also applies to HDI artifacts, only Calculation Views, SQL Views and Tables are visible in the Native Datasphere environment. With regards to Native Datasphere objects, only Views that have been “exposed for consumption” are visible to the OSS user and in turn the HDI Container.
User Provided Service (UPS) vs Procedure User Provided Service (PUPS)
Figure 1.1 intentially simplifies the HDI development experience by not showing the User Provided Service (UPS) that is needed to grant access to objects that exist out of the HDI Container itself.
In Datasphere the standard definition of the UPS is provided using the type procedure, PUPS (Procedure User Provided Service).
# Procuedure User Provided Service (PUPS)
{
"user": "OPTANE#I049374",
"password": "Can't share that",
"schema": "OPTANE",
"tags": [
"hana"
],
"type": "procedure",
"procedure_schema": "OPTANE$TEC",
"procedure": "HDI_GRANTOR_FOR_CUPS"
}
During investigation, I found that the procedure syntax makes development more complicated as the procedure restrictions the type of objects and grants that can be performed.
By removing the procedure reference in the UPS definition as shown below, development becomes easier.
# User Provided Service (UPS)
{
"user": "OPTANE#I049374",
"password": "Can't share that",
"schema": "OPTANE",
"tags": [
"hana"
]
}
What’s Happening Here?
I have tried illustrate that in figure 2.1, the PUPS does not allow you to grant objects from within the Open SQL Schema. It also prevents you from granting schema privileges which forces you to grant individual views. Only Datasphere views with the “Expose for Consumption” ON, can be used by the HDI container.
Figure 2.2 shows that with the traditional UPS you have greater flexibility with HDI development. The same HDI concepts with grants and synonyms, still apply in the HDI container but you have less restrictins. The UPS can access both the native space views, with “Expose for Consumption” ON, and also all the OSS tables and OSS views.
Conclusion
Don’t let the PUPS control your development especially if you are using the OSS. Go instead with the regular UPS.
Be the first to comment