HANA XSA Simplified 2: HANA XS classic and XS Advance comparison and migration from XSC to XSA

[former_member599759]

As I promised in my earlier blog post, I have come up with next blog post in this series on XS classic and XS advance comparison and how to migrate your existing XSC application to XSA. In this blog post you will understand step by step process to migrate from XSC to XSA process.

You can visit other blog posts in this series using below links.

HANA XSA Simplified 1: HANA XSA Implementation Methodology for different customer scenarios.

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

In below table, I have summarized high level comparison between XSC and XSA. To see the more details about the changes from XSC to XSA technical architecture and other aspects, you can visit the below link.

https://help.sap.com/viewer/58d81eb4c9bc4899ba972c9fe7a1a115/2.0.04/en-US/b1333dbbfa9549ffa76850b5b5...

Criteria	XS Classic	XS Advanced
General	SAP HANA XS classic is a lightweight application server includes web based HTTP and OData services. It can consume HANA database artifacts (e.g. calculation views) and it has built in support for the SAP Fiori UI. It supports transactional services based on core data services (CDS). It uses database permissions; there are DB users in HANA itself. It was introduced in SAP HANA 1.0 SPS 05.	SAP HANA XS Advanced is an enhanced application server for native development in the SAP HANA environment. It evolved from SAP HANA XSC. 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. It was introduced in SAP HANA 1.0 SPS 11.
Programming Model	XSJS and oData	XSJS, oData, Node.js, C++
Database	Schema-based	HDI Container based database module
Security	Uses Repository roles, Users, SAP provided HANA roles at HANA database level	Uses XSA security for developers, HANA database security for third party reporting end users using Repository roles, xs-security.json for web based developments
Development environment	HANA Studio and Web Development Workbench	WebIDE
Artifacts repository	HANA Repository	Git
Transport	CTS+, ABAP Based Transports, Delivery Units	XS Deploy, CTS+, Jenkins and CI/CD, ABAP Based Transports
Deployment	Projects are directly deployed on the Database	Projects are deployed onto Organization and Spaces
Isolation	Content isolation is possible only using schema and packages	Content isolation is possible with HDI Container
Role Provisioning	Any user with Role Admin authorization can provision roles to others	Object owner user is owner of all the authorization; only object owner can provide the roles created inside that container to other users

High level steps in migration from HANA XSC to XSA.

Preparation

In this step, we will prepare the source system, delivery unit and user for migration.

1. Migration from the XSC to XSA: In below table you can find the XSC Objects which are not supported by the XSA Migration tool. These XSC objects first need to be migrated to supported objects in XSC itself. There is a tool within HANA studio which helps to convert some of these objects like Analytical Views, Attribute Views to Calculation views but most of the objects need to be converted manually like Catalog tables to HDB Tables. If Catalog tables are not converted into HDB tables or Repository tables then these tables will not get migrated. You will have to manually migrate these tables into classic schema of your Target HANA system and then create the User provided service to access these tables. Migration tool will create the synonyms to access these tables in HANA XSA project.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

   XSC Non-Supported Objects	XSC Supported Objects
   Analytical Views, Attribute Views, Scripted (text-based) calculation views	Graphical Calculation View
   Catalog Schema, Catalog tables	HDB tables or Repository tables
   XML-based analytic privileges	SQL analytic privileges
   Application Function Library (AFL) models	AFLLang procedure
   Decision tables	Graphical Calculation View

   
   


2. Download the migration software: Download the latest XS Advanced Migration Assistant package ‘XSAC Migration 1’ from SAP Software Download portal or use the SAP Note 2362604 - SAP HANA XS Migration Assistant 1 for SAP HANA 2.0 SPS0.Unpack the ZIP archive on your local desktop or laptop. Place this directory close to the root directory (for example, C:\).Only for Linux: Make the \xs-migration and \sapjvm_8_jre\bin\java files executable.


3. Prepare the delivery unit in source system: Collect all the packages in delivery unit which you would like to migrate. Let us consider delivery unit name is DU_XSA_MIGRATION.


4. Source system check: If your Delivery Unit is on the source system, whose version is SAP HANA 1.0 SPS 10 or less than this then it will not have the procedure SYS.GET_OBJECTS_IN_DDL_STATEMENT available. In this case you will have to use the Target system as Parsing system.If your Delivery Unit is on the source system, whose version is SAP HANA SPS 11 or more then you do not need the parsing system.


5. Enable GET_OBJECTS_IN_DDL_STATEMENT: If source HANA system is single tenant, then execute following SQL statements on your SYSTEM database
   

   ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'system') SET ('sqlscript', 'enable_builtin_procedure_get_objects_in_ddl_statement') = 'true' WITH RECONFIGURE

   
   If source HANA system is Multi-tenant, then execute following SQL statements on your SYSTEM database
   

   ALTER SYSTEM ALTER CONFIGURATION ('nameserver.ini', 'system') SET ('sqlscript', 'enable_builtin_procedure_get_objects_in_ddl_statement') = 'true' WITH RECONFIGURE

   
   


6. User authorization: Below authorizations are required for the user in source system which will be used for migration. Let us consider migration user in source system is XSA_MGR. Try to use SYSTEM user to provide these authorizations; as SYSTEM user will have permission to provide these authorizations.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

   Object privileges	GRANT EXECUTE ON "SYS"."GET_OBJECTS_IN_DDL_STATEMENT" TO “XSA_MGR”; GRANT EXECUTE ON "SYS"."GET_OBJECT_DEFINITION" TO “XSA_MGR”; GRANT EXECUTE ON "SYS"."REPOSITORY_REST" TO “XSA_MGR”; GRANT SELECT ON "_SYS_BI"."M_SCHEMA_MAPPING" TO “XSA_MGR”; GRANT SELECT ON "SYS"."GRANTED_PRIVILEGES" TO “XSA_MGR”; GRANT SELECT ON "SYS"."GRANTED_ROLES" TO “XSA_MGR”; GRANT SELECT ON "SYS"."M_DATABASE" TO “XSA_MGR”; GRANT SELECT ON "SYS"."OBJECTS" TO “XSA_MGR”; GRANT SELECT ON "SYS"."OBJECT_DEPENDENCIES" TO “XSA_MGR”; GRANT SELECT ON "SYS"."PROCEDURES" TO “XSA_MGR”; GRANT SELECT ON "SYS"."SYNONYMS" TO “XSA_MGR”; GRANT SELECT ON "SYS"."TABLE_COLUMNS" TO “XSA_MGR”; GRANT SELECT ON "SYS"."TABLES" TO “XSA_MGR”; GRANT SELECT ON "_SYS_REPO"."ACTIVE_CONTENT_TEXT_CONTENT" TO “XSA_MGR”; GRANT SELECT ON "_SYS_REPO"."ACTIVE_CONTENT_TEXT" TO “XSA_MGR”; GRANT SELECT ON "_SYS_REPO"."ACTIVE_OBJECT_TEXT_CONTENT" TO “XSA_MGR”; GRANT SELECT ON "_SYS_REPO"."ACTIVE_OBJECT_TEXT_CONTENT" TO “XSA_MGR”; GRANT SELECT ON "_SYS_REPO"."ACTIVE_TAGS" TO “XSA_MGR”; GRANT SELECT ON "_SYS_REPO"."CATALOG_OBJECTS_CREATED_BY_REPOSITORY_ACTIVATIONS" TO “XSA_MGR”; GRANT SELECT ON "_SYS_RT"."CDS_ANNOTATION_VALUE" TO “XSA_MGR”; GRANT SELECT ON "_SYS_RT"."CDS_ARTIFACT" TO “XSA_MGR”; GRANT EXECUTE ON "SYS"."GET_OBJECTS_IN_DDL_STATEMENT" TO “XSA_MGR”;
   System privileges	GRANT "CATALOG READ" to “XSA_MGR”;
   Package privileges in migrated DU	GRANT REPO.READ on "<your-package>" to “XSA_MGR”;

   
   

Migration

In this step, we will see how to use the migration assistance tool.

1. Unzip the migration tool downloaded from SAP download portal, it will look like shown below.


2. Open the CMD on your desktop where migration tool is downloaded and navigate to xs-migration tool folder.


3. Get the host name or IP of the source HANA system and index server SQL port number. You can use below SQL to get the host name and SQL port of the system.
   

   SELECT HOST FROM M_CONNECTIONS WHERE CONNECTION_ID = CURRENT_CONNECTION;
   
   
   
   SELECT SERVICE_NAME, PORT, SQL_PORT, (PORT + 2) HTTP_PORT FROM SYS.M_SERVICES 
   
   WHERE ( SERVICE_NAME = 'indexserver' and COORDINATOR_TYPE = 'MASTER' ) or SERVICE_NAME = 'xsengine';​

   
    


4. If source system is on or higher than SAP HANA 1.0 SPS 11 then use below commands in the CMD (For Windows systems use ‘Set’ and for Linux systems use ‘Export’):Set HANA_HOST=HANA_source_system_host_nameSet HANA_SQL_PORT=HANA_source_SQL_Port_numberSet HANA_USER=XSA_MGRSet HANA_PASSWD=Passwordxs-migration.bat --target-dir C:\result DU_XSA_MIGRATION
   

   Note: Make sure ‘result’ folder is not available at C:\. System will create this folder while generating the output. If this folder is already available, then you will get the error ‘Target directory "C:\result" does exist.’.
   

   
   Based on the number of objects, it will take some time to complete the process. Once process is completed, you will see below message.
   

   

   
   There are more options which can be used with xs-migration.bat statement. Please refer below link to find more options.
   

   https://help.sap.com/viewer/58d81eb4c9bc4899ba972c9fe7a1a115/2.0.04/en-US/2a4f5f4ac28942d39c3875fea2...

   
   


5. Go to the C:\result


6. In ‘report.html’ file you can find all the logs, success, warning and error messages. Use the below link to learn more about reading report. https://help.sap.com/viewer/58d81eb4c9bc4899ba972c9fe7a1a115/2.0.04/en-US/c9ae88eb263c4da7a52e7682d5...


7. Go to db -> src folder. Under the src folder you can find all the objects from your source system converted into XSA compatible objects

Import Project into WebIDE

In this step, we will import the project into WebIDE and do the necessary adjustments.

1. Add to the result folder to .zip.


2. Login to your XSA webide, right click on the ‘Workspace’ and import the result.zip folder. In the ‘Import to’ field you can provide the XSA project name then click on OK.


3. Now in project, we can see all the objects are imported in XSA format.


4. Check in the .hdinamespace file, it will have the path of XSC package structure. This path will be used in all the objects name based on the “subfolder” settings.This will be derived from XSC project package names and structure.


5. Note: This is not the recommendation; it is only suggestion. In my projects, I do not use the imported project. I generally create new project and then import objects into new project and change the names for these objects as per new project namespace. In this case, I have created ‘Project_ABC’ project with ABC_DB database module. In this way I can manage the project using new folder structure in XSA.Note: Try to keep the database module separate for every project. If you use the same DB name in all the project, then you will face issues when you will deploy the projects with same DB module name in same space. First project will get deployed successfully but when you will try to deploy the second project it will fail. Second project will try to create DB service name which is already created by first project. In this case DB service name is ‘hdi_ABC_DB’. Same is the case with the schema name. Try to keep it different.


6. Copy the objects from imported project to newly created project and then change the name for these objects and also change or replace the namespace inside the objects wherever it is required. Start with base level objects like tables and then gradually go up like flowgraphs, calculation views and role etc. You can also do it opening the object in SQL or JSON and use the Find and Replace functionality and then save. If you have changed the namespace for tables then you will also have to change the table names in all the places where they are used.
   

   Example: In case of calculation view name can be changed from Semantics and then ‘Refactor’ it. To change the tables used in the calculation view you can user the ‘Replace Datasource’ functionality.

   
   

Data Migration

To migrate the Data from existing XSC tables to XSA tables you can use different methods.

1. Download the data into CSV file and then load the data from CSV files into HANA XSA tables.


2. Create the SDA or SDI connections from source XSC system to XSA system; create flowgraph and load the data.


3. Use other ETL tools like data services or Talend to load the data from source to Target.

I hope this blog post will help you to understand the difference between HANA XSC and XSA and It will helpful for you to migrate your existing XSC applications to HANA XSA.

[kgaurav2k14]

Thanks Vivek for such a detailed explanation. Please help us with your experience with the entire migration lifecycle. We need to understand the real challenges and obstacles you have faced if any.

I have opened a discussion on below link, please share your experience there.

https://answers.sap.com/questions/13204459/hana-xs-to-xsa-migration-challenges.html

Thanks,

GK

[AndersonCM]

Hi vivek.vpc1985,

I have a question, Why do you tell that transport in XSA are XS Deploy, CTS+, Jenkins and CI/CD, ABAP, Based Transport? because sap documentations say that Delivery Units are enabled for transport between hana systems.

"You can also use the delivery unit to transport repository content between SAP HANA systems".

Enclose link: "https://help.sap.com/viewer/a4d43a319ecf464e9d838454a6bdb9ad/2.0.05/en-US/ebb13d7db3f5407fbe7eb1dbe0a3c329.html"

 

Regards,

Anderson CM.

 

[former_member599759]

Hi anderson.cardozo,

Delivery units can be used to transport repository content between SAP HANA XSC systems. In the comparison table you can find the delivery unit option under the HANA XSC column. I also gone through the link provided by you but in that link, I did not find any information on how can we transport the repository content between SAP HANA XSA systems. Please correct me if I am missing something here. I have covered all the transport possibilities in HANA XSA in the blog https://blogs.sap.com/2020/08/23/hana-xsa-simplified-5-deployment-options-for-xsa-mta-projects/. Please let me know if you still have more doubts.

[balazs_rajnai]

Hello vivek.vpc1985 
Based on what we learnt about XSA, it seems the CTS+ functionality is a stepback, as in XSC there was no need of downloading the mtar file to the local repo and then attaching it to the transport. Can you please confirm our understanding that there is no automated way of perform this in XSA or if there is a way then can you let me know that?

[former_member599759]

Hello balazs.rajnai

In our project also we are using CTS+ for transport. As you mentioned there is no way that mtar files get attached to the transport request automatically. We are using same method to download the mtar file and then manually attach it to the transport request.