In the recent few months, there were several questions about HANA 2.0 upgrade in the forums. Some developers thought that, it is a big change and lot of things get changed with that. It is not true though in all cases. In this blog, I am writing about the options generally available while doing the upgrade project to 2.0.
If it is just a database upgrade, then It is fairly a simple process which is taken care by basis/Admin team, leaving modelers/developers with no specific task to be done during this process.
However, if the customer choose to upgrade to 2.0 and also migrate to XS Advanced server, then it is a significant effort to the developers, so in this blog, we will look at both options of upgrade as shown in the picture below.
Option 1 : Upgrade to HANA 2.0 SP 03 or 04 with out XSA migration
This is a very straight forward process, data base will be upgraded to 2.0 version, XS classic server is available in 2.0 SP 03, so technically there will be no change in the process of how we do modeling and development of native HANA objects like DB tables, Views, Stored procedures, functions and modeling calculation views. Even the XS application development with xsjs and xsodata will remain same as they are before.
So with this upgrade, Customer will have flexibility to continue with XS classic developments with HANA studio tool, will be benefiting from some of the data base features of 2.0 (but not all). Because many of the database and application features are in only available with Web IDE for HANA + XSA.
With this approach, old objects in 1.0 will continue work without any issues, developer will not have to much during pre or post upgrade, of course developers may validate some objects just for sanity check or smoke test to confirm the upgrade is successful other than that, no impact.
If you are using HANA as run time version for S/4 HANA or BW/4 HANA then upgrading to 2.0 is going to with this option.
Option 2: Upgrade to HANA 2.0 SP 03 or SP 04 with XSA migration
In this option, after upgrade to 2.0, we will have XS classic and XS advanced, will be leveraging XSA server for new developments and also migration of 1.0 XS classic objects to XS advanced. So in this option, developers will need to understand architecture of XSA , developments in Web IDE for HANA and migration options from XS classic. So in this case also, XS classic is not removed from the HANA platform, which allows the customer to migrate to XSA slowly as non-disruptive approach.
2.a upgrade to 2.0 and migrate to XSA slowly
It is kind of hybrid approach, So for new developments, we can use Web IDE for HANA with Git hub integration and for XS classic developments and maintenance we can still use HANA studio/Eclipse.
This approach is non disruptive, at the same time customer can be aligned with SAP road-map going ahead with XS advance server only in the future.
2.b Upgrade and Migrate to XSA at the same time
Customer will choose to upgrade the DB to 2.0 and also migrate XS classic to XS advanced server in one process. Therefore it gets more complicated, because it required significant effort from development team. Also, there are some challenges currently with XSA in support to S/4 HANA and BW/4 HANA mixed use cases. Some of the complex tasks like, migrating schema to DB modules in Web IDE, HDI container management, creating cross schema services, creating synonyms to access objects, build and deployment process and finally source code control with github etc., will require significant effort in planning and developer skill set to do so. On the application development, it is not going to be such a big change, because xsjs ans xsodata files are supported in nodejs run time given in XSA. But there will be some effort involved in the redesigning the security model.
Summary: However, with XS classic deprecated already, considering XS Advanced as future app server in the SAP road map, it is more feasible option to go with 2.a, so that you can actually leverage XS Advanced features which come up with SP 03 or 04.
Thank you, please let me know your comments.
If it is just a database upgrade, then It is fairly a simple process which is taken care by basis/Admin team, leaving modelers/developers with no specific task to be done during this process.
However, if the customer choose to upgrade to 2.0 and also migrate to XS Advanced server, then it is a significant effort to the developers, so in this blog, we will look at both options of upgrade as shown in the picture below.
Option 1 : Upgrade to HANA 2.0 SP 03 or 04 with out XSA migration
This is a very straight forward process, data base will be upgraded to 2.0 version, XS classic server is available in 2.0 SP 03, so technically there will be no change in the process of how we do modeling and development of native HANA objects like DB tables, Views, Stored procedures, functions and modeling calculation views. Even the XS application development with xsjs and xsodata will remain same as they are before.
So with this upgrade, Customer will have flexibility to continue with XS classic developments with HANA studio tool, will be benefiting from some of the data base features of 2.0 (but not all). Because many of the database and application features are in only available with Web IDE for HANA + XSA.
With this approach, old objects in 1.0 will continue work without any issues, developer will not have to much during pre or post upgrade, of course developers may validate some objects just for sanity check or smoke test to confirm the upgrade is successful other than that, no impact.
If you are using HANA as run time version for S/4 HANA or BW/4 HANA then upgrading to 2.0 is going to with this option.
Option 2: Upgrade to HANA 2.0 SP 03 or SP 04 with XSA migration
In this option, after upgrade to 2.0, we will have XS classic and XS advanced, will be leveraging XSA server for new developments and also migration of 1.0 XS classic objects to XS advanced. So in this option, developers will need to understand architecture of XSA , developments in Web IDE for HANA and migration options from XS classic. So in this case also, XS classic is not removed from the HANA platform, which allows the customer to migrate to XSA slowly as non-disruptive approach.
2.a upgrade to 2.0 and migrate to XSA slowly
It is kind of hybrid approach, So for new developments, we can use Web IDE for HANA with Git hub integration and for XS classic developments and maintenance we can still use HANA studio/Eclipse.
This approach is non disruptive, at the same time customer can be aligned with SAP road-map going ahead with XS advance server only in the future.
2.b Upgrade and Migrate to XSA at the same time
Customer will choose to upgrade the DB to 2.0 and also migrate XS classic to XS advanced server in one process. Therefore it gets more complicated, because it required significant effort from development team. Also, there are some challenges currently with XSA in support to S/4 HANA and BW/4 HANA mixed use cases. Some of the complex tasks like, migrating schema to DB modules in Web IDE, HDI container management, creating cross schema services, creating synonyms to access objects, build and deployment process and finally source code control with github etc., will require significant effort in planning and developer skill set to do so. On the application development, it is not going to be such a big change, because xsjs ans xsodata files are supported in nodejs run time given in XSA. But there will be some effort involved in the redesigning the security model.
Summary: However, with XS classic deprecated already, considering XS Advanced as future app server in the SAP road map, it is more feasible option to go with 2.a, so that you can actually leverage XS Advanced features which come up with SP 03 or 04.
Thank you, please let me know your comments.
- SAP Managed Tags:
10 Comments
