In this series of blog posts, I will try to explain some of the basic concepts of HANA XSA in a simplified way which I learned from my experience while implementing it for our client.
In the this first blog post you will able to understand the parameters you will have to considers while designing your HANA XSA Architecture.
To visit the other blog posts in this series follow the below links.
HANA XSA Simplified 3: Using GIT as a central repository in WebIDE and Deploy Process
HANA XSA Simplified 4: SAP HANA Database Authorization provisioning for HDI Container roles
HANA XSA Simplified 5: Deployment options for XS Advance MTA projects
Tenant: With HANA 2.0, SAP has made it mandatory to have multi tenant installation of HANA. With the tenant concept, it is possible to do the physical division of single HANA system. It provides the flexibility to have multiple tenants in single HANA environment where each tenant can be allocated with amount of memory and CPU threads based on their usage. It also allows to manage the set of Database Users, Catalog objects, Traces, Backup and Restore separately for each tenant.
Organizations and Spaces: While moving from HANA XS classic to XS advance, SAP has added support of runtimes like Java, Nodejs and build packs like python developments. It also added more different components like xsa cockpit, webide, hrrt-core etc. for developing and managing the applications. Organization and Spaces is a virtual division of HANA XSA layer which provides the isolated environment for different applications with flexibility to share the data with authorized channel.
Container or MTA Project: XSA introduces the Multi-Target Applications (MTAs) full stack development which allows to club the different type of components like database development, node.js and HTML into single packages as an application. It is a microservice-driven architecture of a solution is typically characterized by the cooperation of several service instances fulfilling dedicated task.
There are many factors which need to be considered for designing HANA XSA Architecture. Here we will mainly discuss about “What level of data and application isolation required between the projects and how to achieve the cross container data virtualization using different techniques”?
Below reference Architecture can be used based on the different requirements of data and application isolation requirements.
Below are Container design methodologies based on different level data isolation requirement:
Below are cross container data virtualization techniques which can be used based on the different scenarios.
Example: Container 1 in Tenant 1 contains Finance data of multiple Divisions, Container 3 in Tenant 2 is built only for Division ‘A’ and Container 4 in tenant 2 is built for Division ‘B’ then single SDA connection with SSO authentication can used for both with different authorizations at the source tenant 1.
Example: Container 1 in Tenant 1 contains master data which can be shared with all the other container without any authorization restrictions then single SDA connection with technical user can used to virtualise the data from the source tenant 1.
Example: Single application can be divided into 2 projects in same space for modelling simplicity like Container 1 and Container 2 in Space 1. These 2 projects can share the data without any restriction among them using UPS.
Hope, this blog post will help you to take right decisions while designing the HANA XSA Architecture for data and application isolation and to achieve the data virtualization using different techniques.
In the this first blog post you will able to understand the parameters you will have to considers while designing your HANA XSA Architecture.
To visit the other blog posts in this series follow the below links.
HANA XSA Simplified 2: HANA XS classic and XS Advance comparison and migration from XSC to XSA
HANA XSA Simplified 3: Using GIT as a central repository in WebIDE and Deploy Process
HANA XSA Simplified 4: SAP HANA Database Authorization provisioning for HDI Container roles
HANA XSA Simplified 5: Deployment options for XS Advance MTA projects
Tenant: With HANA 2.0, SAP has made it mandatory to have multi tenant installation of HANA. With the tenant concept, it is possible to do the physical division of single HANA system. It provides the flexibility to have multiple tenants in single HANA environment where each tenant can be allocated with amount of memory and CPU threads based on their usage. It also allows to manage the set of Database Users, Catalog objects, Traces, Backup and Restore separately for each tenant.
Organizations and Spaces: While moving from HANA XS classic to XS advance, SAP has added support of runtimes like Java, Nodejs and build packs like python developments. It also added more different components like xsa cockpit, webide, hrrt-core etc. for developing and managing the applications. Organization and Spaces is a virtual division of HANA XSA layer which provides the isolated environment for different applications with flexibility to share the data with authorized channel.
Container or MTA Project: XSA introduces the Multi-Target Applications (MTAs) full stack development which allows to club the different type of components like database development, node.js and HTML into single packages as an application. It is a microservice-driven architecture of a solution is typically characterized by the cooperation of several service instances fulfilling dedicated task.
There are many factors which need to be considered for designing HANA XSA Architecture. Here we will mainly discuss about “What level of data and application isolation required between the projects and how to achieve the cross container data virtualization using different techniques”?
Below reference Architecture can be used based on the different requirements of data and application isolation requirements.
Below are Container design methodologies based on different level data isolation requirement:
- Building the Containers in different space and different tenant: This can provide the highest level of data and application isolation. In the reference architecture this can be visualized by Dev Tenant 1 and Dev Tenant 2 where isolation can be achieved at data, database users, spaces, HDI containers, application and traces level. In this case if there is requirement to share the data between the projects built on different tenants then below data virtualization options are available (Preferred way ‘Virtual access using SDA with Single Sign On’). This scenario can be helpful in cases where there is a requirement to secure finance, HR or critical data from other containers. These applications can be built in separate tenants and provide the secure access to critical data.
- Building the Containers in different space but same tenant: This can provide the data and application isolation but cannot provide the isolation at database users and traces level. In the reference architecture this can be visual by HDI Container 3 and HDI Container 4 in Dev Tenant 2 (Preferred way ‘Virtual access using SDA with SDA with Single Sign On’). This scenario can be used where there is a non-critical data in containers but still need the isolation between the data and application.
- Building the Containers in single space and single tenant: This can provide the application isolation but cannot provide the isolation at data, database users and traces level. In the reference architecture this can be seen by HDI Container 1 and HDI Container 2 in Dev Tenant 1. With this architecture it is very easy to share the data between the containers using UPS and synonyms (Preferred way ‘Virtual access using User Provided service (UPS)). This case can be applicable where one application needs to be divided into 2 projects for simplicity of developments or because of some other reason.
Below are cross container data virtualization techniques which can be used based on the different scenarios.
- Virtual access using SDA with Single Sign On: SDA connection with Single sign on authentication can be created between Tenant 1 and Tenant 2 (In diagram it is indicated by 2). This is the most secured way to share the data between the database containers as it requires to have the data base end users available in both tenants with proper authorizations. In this case there is more flexibility to design the different authorizations as per users or user groups in source tenant. It can be also used within the tenant to access the data between 2 HDI containers in different spaces (In diagram it is indicated by 4).
Example: Container 1 in Tenant 1 contains Finance data of multiple Divisions, Container 3 in Tenant 2 is built only for Division ‘A’ and Container 4 in tenant 2 is built for Division ‘B’ then single SDA connection with SSO authentication can used for both with different authorizations at the source tenant 1.
- Virtual access using SDA with Technical user: SDA connection with technical user can be used in same way as SDA with SSO. The only limitation with SDA using technical user that Technical user in source tenant need to be given wide authorizations. There is no flexibility to design the users or user groups based authorization in the source tenant.
Example: Container 1 in Tenant 1 contains master data which can be shared with all the other container without any authorization restrictions then single SDA connection with technical user can used to virtualise the data from the source tenant 1.
- Virtual access using User Provided service (UPS): User provided service can be created only using technical user. It can be used in most of the data virtualization scenarios. In cross tenant and cross space scenarios. It works in same way as SDA with Technical user. In case of container in same space UPS can be created without using technical user. There is no restriction on what data and views can be seen by other containers.
Example: Single application can be divided into 2 projects in same space for modelling simplicity like Container 1 and Container 2 in Space 1. These 2 projects can share the data without any restriction among them using UPS.
Hope, this blog post will help you to take right decisions while designing the HANA XSA Architecture for data and application isolation and to achieve the data virtualization using different techniques.
- SAP Managed Tags:
3 Comments
