In this post, we’ll look at the deployment options for the different SAP Business Technology Platform development environments.
A few points to note as we consider these deployment options include the following.
The structure of the SAP BTP provisioning in terms of global account, subaccounts, and spaces—any configuration like connecting to a specific on-premise system or security setup, is specific in a subaccount instance of the platform. So, if you’re deploying an application which is, say specific to finance, then it’s better to have a separate subaccount for finance only. If the same subaccount is used for all areas, there is a chance of configurations getting overwritten or conflicts and confusion arising.
For every environment like development, test, and production, you need separate subaccounts. In fact, since each subaccount would be linked to the core instance of the underlying transactional system, which may be on-premise SAP S/4HANA, for example. Ideally, you have one-to-one linkages between the environments of this SAP S/4HANA instance and the corresponding subaccount. This approach ensures testing with the backend systems and security, all in sync, with no deployment risks.
Further classification under the subaccount is provided spaces, which is a concept inherited from Cloud Foundry. But this concept can also be used for logical groupings of developments.
For applications developed in SAP BTP, Neo environment, the first point of entry into the deployment architecture is often through SAP Web Dispatcher.
SAP BTP, Neo environment, also supports multitarget application (MTA) deployment but not in the cloud environment.
When an application is created in SAP BTP, Neo environment, you’ll create a project in SAP Web IDE, push the code to GitHub, and then have three options for saving the application: saving locally, committing changes to GitHub, or pushing the application to the SAP BTP instance. The main runtimes available in SAP BTP, Neo environment, support development using Java, JavaScript, SAP HANA, and HTML5/SAPUI5. Developer environments are available on Eclipse and on SAP Web IDE. Developer environments are available on Eclipse and on SAP Web IDE. For XS-JS development, you can use Eclipse plugins or the SAP HANA Web-Based Development Workbench. An application can be run locally for unit testing but, in this state, is not available for other users. Only when published to SAP BTP and activated will the application be ready to run on the cloud. As shown in the figure below, some services are available in the SAP BTP cockpit, while the deployment and versioning functionalities are available via SAP Web IDE for Neo.
Unlike other environments, SAP Business Application Studio has no roadmap to support Neo environments so far.
The next figure shows versioning capabilities within SAP BTP, Neo environment.
When an application is deployed on Cloud Foundry from the developer workspace to SAP BTP, Cloud Foundry uses different containers, for instance, various app containers and database containers. Since the architecture using Cloud Foundry is completely different from using Neo, these applications are deployed and executed differently as well.
Runtimes available in Cloud Foundry include Java, HTML5, Node.js for backend applications, and machine learning algorithms in Python. While SAP Web IDE still supports full stack development, including frontend development capabilities, database models, and business logic built into backend capabilities, the newer IDE called SAP Business Application Studio is now the preferred development and deployment environment for the cloud-native applications (unless using ABAP).
In Cloud Foundry, MTA deployment is possible. Let’s look at an example of creating an application using the Cloud Foundry architecture and then using MTA to deploy the application. In our example, we’ll consider a simple cloud-native application with a frontend and a schema in the SAP HANA database with some calculation views, consuming some services from other systems, perhaps SAP S/4HANA through a CDS view. How the deployment architecture should look is shown in this figure.
The AppRouter is the first point of entry when a user calls your application through a web browser. The AppRouter also handles security considerations and authenticates the user. The call goes from this application to the microservice, over an HTTP service or a REST service.
2
The application can be deployed into different app containers, depending on the microservices used. Cloud Foundry has container services and backing services. With each container, core parts of the application server are deployed too. For instance, a microservice may use different languages. This multilingual operation is supported by backing services, which contain every attached resource for your application, for example, persistence objects or job schedulers.
While typical artifacts are created through the SAP Business Application Studio (or SAP Web IDE full-stack), if you use a language not yet supported by the SAP Business Application Studio/SAP Web IDE, you can connect an external development tool for any language through Git. All the code for all your applications can be stored in a Git repository. The deploy services available in Cloud Foundry can act as the central component for managing the lifecycle of the application. These services enable MTAs, which will package up all the different parts of the application in a single .yaml file, to be transported across different landscapes. The MTA will split up the application into modules: For instance, one module may be for the SAP HANA database for database content (CDS views, calculation views), while another module may contain Java/Node.js for backend code. A third module may be an HTML5 module for the HTML frontend content. The deployment functionality also contains configuration information for security and other dependencies like services the application needs. It will take care of getting the code from the developer workspace into the relevant parts of Cloud Foundry (e.g., HDI containers into the table/views/databases, frontend/backend into app containers, etc.).
Once the development is built, you generate the .yaml file through the graphical menu or using the CLI in SAP Business Application Studio. You’ll also need to input some details into the descriptor files for an SAP Cloud Application Programming Model-based application. Then, this application will be built, which generates the .mtar file in the .mta archive folder. The advantage of this build and deployment approach is that it knows all the dependencies and sequences and takes care of the generation of the different code in different languages. Once the .mtar file is generated, you can deploy this application, which you will then see in your dev space (assuming you first deploy to a dev environment before moving to other environments), including logs for the deployment of each module (e.g., .srv for the web services or .ui for the UI module).
Note: Detailed guidance for Cloud Foundry deployments can be found at http://s-prs.co/v550429.
After the application, whether a microservice or a function is created, it is containerized using Docker containers and exposed as standard in the Kubernetes framework, and it is possible to make these scalable. For complex requirements, this is the option to be chosen. Then, the Docker image can be deployed to SAP BTP, Kyma runtime, using the Kyma console. After deployment to SAP BTP, Kyma runtime, the status can be checked in the Kyma dashboard through the log output. Logs are available for each namespace and for also for particular lambda functions.
Microservices can be deployed through the deployments as YAML Ain’t Markup Language (YAML) or JavaScript Object Notation (JSON) files. Continuous integration/continuous deployment (CI/CD) pipelines use kubectl.
ABAP developments are created as software components under “packages” in ABAP. When you release the code, the packages are stored in the Git repository, which handles the deployment as a whole. The entire code is deployed.
Transport organizers in ADT in Eclipse are used for deploying ABAP programs to application servers configured in SAP Business Application Studio. OData services are created and then deployed to the application server in the cloud. The transports are handled using SAP Cloud ALM or Git-based CTS (gCTS).
The ABAP code can also be placed in the abapGit repository, from which the deployment can be handled it. However, abapGit is currently available only as a plugin to ADT.
Editor’s note: This post has been adapted from a section of the book Application Development with SAP Business Technology Platform by Gairik Acharya, Govind Bajaj, Avijit Dhar, Anup Ghosh, and Asidhara Lahiri.