In this blog, I am going to describe the process of HANA XSA application deployment in a Dev -- > QA -- > Prod system landscape at a very high level. Also, I will explain different options available for deployment of XSA objects.
With the XS advanced server, the development and deployment process has been changed a bit from XS classic, on tooling prospective now we got Web IDE for HANA, GitHub and XS Command line tools for the purpose of object development, Source control and deployment respectively. Basically XSA is an On-Premise offering of Cloud foundry run times and deployments process in general.
In this document, I am going to take an example of MTA project's db module which creates HDI-container objects in the database and then deploy them in QA and Production systems. However, the deployment process is going to be same for Node module or html module deployments as well.
The below picture describes the very high level process of development and deployment, explained in 3 major steps.
1. Development:
In the above example scenario, Developer_1 created an MTA project in Web IDE for HANA, with a DB module which has hdbtable and Calculation views as the development artifacts, upon the build, HDI container is created in the database as run time objects.
In Web IDE for HANA, MTA project source code is checked into/Committed GitHub by Developer_1, if the other developer also making changes to the same project, he/she can pull that project code from GitHub and make the necessary changes and build it. Upon the completion of build of Developer_2, a different HDI container is created for Developer_2 in the database, it is independent of Developer_1 container objects, thereafter developer_2 can commit the code back to GitHub with the latest changes. So version control and dependencies are managed very effectively GitHub. All of this happening in Dev space of Web IDE.
2. MTA Archive Generation:
When the DB module is ready for deployment, Select the Project header and build it, with that an MTA Archive file is generated at the top of the project, this file has an extension of .mtar and it can have multiple modules to deploy at one time.
Alternatively you can use MTAR builder(command line tool) to package the MTAR file based on yaml configuration.
Once the MTAR is file is generated, then export the MTAR file to personal directory folder.
3. Deployment :
there are several options available for deployment purpose,
Option 1: XS Command tool can be used to deploy the MTA project into a Central space in the Development system, Central space is different from Dev Space, though both spaces are configured in HANA developer server, Central space is considered as HANA Dev system of XS classic (just for understanding). Which means, all the prototypes and Sandbox work will be done in Dev space in Web IDE with GitHub source control and approved version will be deployed into central space by Admin.
So, there after the same MTAR file will be deployed into QA and Production as well using XS command tool based on the test results and approvals process defined in the organization.
Option 2: You can also configure CTS (SAP transport) to deploy XS Advanced objects, the process is very similar what explained above, however a transport landscape has to be configured, then attach the MTAR file to the TR created in SAP system and that can be imported into the target system. the detailed process is explained in this document, CTS for XSA.
Option 3: if you are implementing Continuous Integration and deployment(Dev Ops) model in your organization, GitHub or Jenkins tools can be used for the automatic deployment purpose.
Summary: Again, It is a very high level explanation of deployment process for HANA XSA objects with a simple scenario as example, in the complex scenarios where an extensive use of services, synonyms to access to cross containers and ERP schema etc, deployment MTAR file will have to be generated by making sure all the dependencies are taken care appropriately.
Thank you.
With the XS advanced server, the development and deployment process has been changed a bit from XS classic, on tooling prospective now we got Web IDE for HANA, GitHub and XS Command line tools for the purpose of object development, Source control and deployment respectively. Basically XSA is an On-Premise offering of Cloud foundry run times and deployments process in general.
In this document, I am going to take an example of MTA project's db module which creates HDI-container objects in the database and then deploy them in QA and Production systems. However, the deployment process is going to be same for Node module or html module deployments as well.
The below picture describes the very high level process of development and deployment, explained in 3 major steps.
1. Development:
In the above example scenario, Developer_1 created an MTA project in Web IDE for HANA, with a DB module which has hdbtable and Calculation views as the development artifacts, upon the build, HDI container is created in the database as run time objects.
In Web IDE for HANA, MTA project source code is checked into/Committed GitHub by Developer_1, if the other developer also making changes to the same project, he/she can pull that project code from GitHub and make the necessary changes and build it. Upon the completion of build of Developer_2, a different HDI container is created for Developer_2 in the database, it is independent of Developer_1 container objects, thereafter developer_2 can commit the code back to GitHub with the latest changes. So version control and dependencies are managed very effectively GitHub. All of this happening in Dev space of Web IDE.
2. MTA Archive Generation:
When the DB module is ready for deployment, Select the Project header and build it, with that an MTA Archive file is generated at the top of the project, this file has an extension of .mtar and it can have multiple modules to deploy at one time.
Alternatively you can use MTAR builder(command line tool) to package the MTAR file based on yaml configuration.
Once the MTAR is file is generated, then export the MTAR file to personal directory folder.
3. Deployment :
there are several options available for deployment purpose,
Option 1: XS Command tool can be used to deploy the MTA project into a Central space in the Development system, Central space is different from Dev Space, though both spaces are configured in HANA developer server, Central space is considered as HANA Dev system of XS classic (just for understanding). Which means, all the prototypes and Sandbox work will be done in Dev space in Web IDE with GitHub source control and approved version will be deployed into central space by Admin.
So, there after the same MTAR file will be deployed into QA and Production as well using XS command tool based on the test results and approvals process defined in the organization.
Option 2: You can also configure CTS (SAP transport) to deploy XS Advanced objects, the process is very similar what explained above, however a transport landscape has to be configured, then attach the MTAR file to the TR created in SAP system and that can be imported into the target system. the detailed process is explained in this document, CTS for XSA.
Option 3: if you are implementing Continuous Integration and deployment(Dev Ops) model in your organization, GitHub or Jenkins tools can be used for the automatic deployment purpose.
Summary: Again, It is a very high level explanation of deployment process for HANA XSA objects with a simple scenario as example, in the complex scenarios where an extensive use of services, synonyms to access to cross containers and ERP schema etc, deployment MTAR file will have to be generated by making sure all the dependencies are taken care appropriately.
Thank you.
- SAP Managed Tags:
13 Comments
