orkungedik/SAP-basis-dataset huggingface dataset:
## 4. Default Values:
If you do not provide any of the above parameters, the application uses the predefined default timeout values. This ensures that there is always a time limit in place to prevent MTA operations from running indefinitely.
Default values:
- Start timeout: 1h
- Upload timeout: 1h
- Stage timeout: 1h
- Task execution timeout: 12h
## Maximum Allowed Values
- Upload timeout: 3h
- Stage timeout: 3h
- Start timeout: 3h
- Task execution timeout: 24h
## Related Information
Modules [page 625]
## 4.1.8.1.8.2  Docker Images as Part of an MTA Deployment
Deploy Docker images as part of a Multitarget application.
You can deploy your own or 3rd party Docker images in the Cloud Foundry environment by referencing them in an application module.
This type of application deployment is faster, as images are already built. Thus, staging is not required, and also all dependencies are statically included in the image.
##  Note
When you reference docker images, MTA packages are not self-sustained - they depend on external repositories hosting images for the deployment.
You can deploy Docker images as MTA modules using the Cloud Foundry command line interface.
To deploy a Docker image as a Cloud Foundry application, your deployment descriptor should reference the image in a module as described in the following example:
<!-- image -->
Using the parameters above:
- image - you reference the location of the image so that it can be scheduled for download by the platform. You have to provide the location of the image using the format &lt;registry.domain&gt;&lt;:port&gt;/repo/
image:&lt;tag&gt; . If you don't do so, images are referenced from Docker Hub. See more about deploying an application with Docker in the provided link at the end of the section.
- (Optional) username and password - you provide credentials in the descriptor only when the image repository requires them.
- no-source - set this parameter to true only when creating an MTA development descriptor ( mta.yaml ) that is meant to be used with the Cloud MTA Build Tool.
## Related Information
Cloud Foundry Documentation: Deploying an App with Docker
```
CF MTA Examples in GitHub: Deploying Docker Images as CF Apps with an MTA https:/ /hub.docker.com/ Cloud MTA Build Tool: Configuring a module that does not have source code to build and package
```
## 4.1.8.1.8.3  Tasks
Create one-off administration tasks or scripts.
During the deployment process, these tasks can be executed against staged applications. The platform creates a new container for them, where they are performed for a specific period until they are completed, after which the container is deleted.
One-off tasks are modeled in accordance to the following structure:
```
 Sample Code _schema-version: "3.1" type: javascript.nodejs
```
```
ID: foo version: 3.0.0 modules: - name: foo parameters: no-route: true no-start: true disk-quota: 2GB tasks: - name: example_task command: npm start memory: 1GB
```
In the structure above, the parameters stand for the following:
- When the task is triggered, the npm start command is executed.
- Entering a specific value in the memory parameter is optional. A platform-derived default memory size is used for the execution of the task. You can specify a different value if required.
- The no-route parameter specifies if a route is required. Applications whose only purpose is to perform a task and then be stopped usually do not require a route. The default value is false .
- Use the no-start parameter if you want only the one-off tasks to be executed, that is, without triggering the start of the application. If you do not define this parameter, tasks are automatically executed after the applications are started.
##  Note
Тhe values for аpplication memory and task memory do not have a dependency. This is also valid for the allowed disk quota.
##  Tip
For more information about one-off tasks, see MTA Deployment Descriptor Examples [page 607].
The following codeblock contains an example for a database migration task:
## 
```
Sample Code _schema-version: "3.1" ID: foo version: 3.0.0 modules: - name: foo type: javascript.nodejs parameters: no-route: true no-start: true memory: 1GB disk-quota: 2GB tasks: - name: db_migration command: "bin/rails db:migrate" memory: 256M                    #This parameter is optional. disk-quota: 128M                #This parameter is optional.
```
## Related Information
Using Tasks
<!-- image -->
## 4.1.8.1.8.4  Services
If you want to create a service instance in the Cloud Foundry environment using the SAP Cloud Deployment service, you must define an MTA resource first. These resources can have different types and parameters which modify their behavior. There is a predefined set of supported resource types, that in most cases represents a certain combination of service offering and plan. See Predefined MTA Resource Types [page 616].
<!-- image -->
```
type: com.sap.xs.uaa
```
The result will be a service instance called my-xsuaa-service with service offering xsuaa and service plan application .
For a more flexible approach, see Generic MTA Resource Types [page 615] and Resource-Specific Parameters [page 619].
##  Note
In most cases, MTA resources represent a Cloud Foundry service, but there are cases where they represent a different platform entity, for example a service key. They can even serve only to a group of configurations. See Resources [page 613] for more information.
## Service Plans
##  Note
This information applies only to service instances that are managed by service brokers.
A service plan defines a specific configuration of a service offered on SAP BTP. While the service itself provides the functionality (e.g., database, messaging, etc.), the service plan determines the level or variant of that functionality - such as free, standard, or enterprise editions.
Each service offered on the marketplace has one or more available service plans. Choosing the appropriate plan is essential for resource allocation, cost, and feature set.
When you create or update a service instance, you need to specify the desired service with the required service-plan parameter:
## 
```
Sample Code resources: - name: my-database type: org.cloudfoundry.managed-service parameters: service: hana service-plan: hdi-shared
```
## Updating Service Plans
Updating service plans is, by default, fail-safe for those operations which result in a call to the service brokers. You can control this behavior by using the fail-on-service-update parameter.
Possible values for the parameter are:
- null (default value): If the update triggers an asynchronous operation (when the service brokers allow plan updates), the deployment will not fail even if the operation fails.
- true : If the update of the service plan fails (even asynchronously), the deployment will also fail.
- false : The update becomes even more permissive - even if the initial call to update the service plan fails, the deployment will still continue.
##  Example
```
parameters: fail-on-service-update: plan: true
```
## 4.1.8.1.8.4.3  Service Tags
Some services provide a list of tags that are later added to the &lt;VCAP\_SERVICES&gt; environment variable. These tags provide a more generic way for applications to parse &lt;VCAP\_SERVICES&gt; for credentials.
You can also provide custom tags when creating a service instance. To inform the SAP Cloud Deployment service about custom tags, you can use the special service-tags parameter. This parameter must be located in the resources definition that represent the managed services, as illustrated in the following example:
##  Sample Code Defining Service Tags in the MTA Deployment Descriptor resources: - name: nodejs-uaa type: com.sap.xs.uaa parameters: service-tags: ["custom-tag-A", "custom-tag-B"]
##  Note
Some service tags are inserted by default, for example, xsuaa , for the XS User Account and Authentication (UAA) service.
## Updating Service Tags
Updating service tags is, by default, not fail-safe because the update does not result in a call to the service broker and can also be used with user-provided service instances. You can control this behavior by using the fail-on-service-update parameter.
Possible values for the parameter are:
- null (default value): If the update fails, the deployment will also fail.
- true : If the update of the service tags fails, the deployment will also fail.
- false : The update becomes permissive - even if the call to update the service tags fails, the deployment will still continue.
##  Example
```
parameters: fail-on-service-update: tags: true
```
## 4.1.8.1.8.4.4  Service Broker Creation
Service brokers are applications that advertise a catalog of service offerings and service plans, as well as interpreting calls for creation, binding, unbinding, and deletion. The deploy service supports automatic creation (and update) of service brokers as part of an application deployment process.
Аn application can declare that a service broker should be created as part of its deployment process, by using the following parameters in its corresponding module in the MTA deployment (or extension) descriptor:
##  Tip
You can use placeholders ${} in the service-URL declaration.
##  Sample Code
```
- name: jobscheduler-broker properties: user: ${generated-user} password: ${generated-password} parameters: create-service-broker: true service-broker-space-scoped: true service-broker-name: jobscheduler service-broker-user: ${generated-user} service-broker-password: ${generated-password} service-broker-url: ${default-url}
```
##  Note
By default, defined service brokers in MTA are attempted to be registered as standard service broker which is available in all orgs and spaces. In practice, however, this is forbidden, as the registration requires CF admin access, which is not provided to anyone.
For test purposes, space-scoped brokers can be registered. In order to do that, parameter servicebroker-space-scoped needs to be equal to true .
The value of the ' ${generated-user} ' and ' ${generated-password} ' placeholders in the properties section is the same as in the parameters section. The service-broker application uses this mechanism to inject the user-password credentials.
The create-service-broker parameter should be set to true if a service broker must be created for the specified application module. You can specify the name of the service broker with the service-broker-name parameter; the default value is ${app-name} The service-broker-user and service-broker-password are the credentials that will be used by the controller to authenticate itself to the service broker in order to make requests for creation, binding, unbinding and deletion of services. The service-broker-url parameter specifies the URL on which the controller will send these requests.
##  Note
During the creation of the service broker, the Cloud Controller makes a call to the service-broker API to inquire about the services and plans the service broker provides. For this reason, an application that declares itself as a service broker must implement the service-broker application-programming interface (API). Failure to do so might cause the deployment process to fail.
##  Note
Normally, the registration of а space-scoped broker is successful, because it requires SpaceDeveloper privileges of the user. However, for a global registration of the service broker, global admin privileges are needed, which the platform developer usually does not have. In such cases, the MTA deployment would fail. T o solve this, do not use the --do-not-fail-on-missing-permissions option, which will result in skipping the step with a warning.
## 4.1.8.1.9 Features
The section describes multitarget application-specific features available in the Cloud Foundry environment of the SAP Business Technology Platform.
Each feature has its own productive benefit. For example, the blue-green deployment enables the zerodowntime update of your multitarget application.
- Cross-MTA Dependencies [page 723]
- Blue-Green Deployment of Multitarget Applications [page 705]
- Legacy Blue-Green Deployment [page 706]
- Blue-Green Deployment Strategy [page 708]
- (Experimental) Namespaces [page 714]
- Parallel Module Deployment [page 720]
- Sequential Resource Processing [page 722]
- Features Related to SAP Alert Notificaton service for SAP BTP [page 728]
- Deploying Content with Generic Application Content Deployment [page 691]
- Docker Images as Part of an MTA Deployment [page 673]
## 4.1.8.1.9.1.4  CPI Content Deployment
This approach provides a mechanism for direct content deployment from the SAP Cloud Deployment service to content backend without the need for an intermediate Cloud Foundry application.
##  Note
This approach is only supported for MTA schema version 3.1 and higher.
This mechanism utilizes the CPI provided protocol. The end-to-end flow and MTA modelling are very similar to Deploying Content with Generic Application Content Deployment [page 691].
## Supported content type offerings
Cloud Foundry service offerings that currently support GACD are:
- API Management content - MTA module type com.sap.api.management
- CPI content - MTA module type com.sap.integration
## 4.1.8.1.9.2  Blue-Green Deployment of Multitarget Applications
Use the blue-green deployment technique by running two identical production environments, allowing seamless updates without downtime for Cloud Foundry Multitarget applications.
<!-- image -->
##  Restriction
Blue-green deployment is supported only for Cloud Foundry applications. It is not supported for bound services, such as service instances and their configuration, workflow content, and HTML5 repository content, among others. Live and idle applications are bound to the same service instances.
By using the blue-green deployment technique, you can update the system without downtime and with reduced risk. During the process, you can perform tests and validation of the new application version using productive data. A classical blue-green deployment of stateless applications, which are modeled as an MTA, is supported.
In the context of Multitarget applications, you have the following options for using blue-green deployment:
- Legacy Blue-Green Deployment [page 706] - where the production environments are called 'blue' and 'green'
- Blue-Green Deployment Strategy [page 708] - where the production environments are called 'live' and 'idle'
- (Experimental) Incremental Blue-Green Deployment Strategy [page 711] - an alternative to the standard blue-green deployment strategy, where the "idle" application is incrementally scaled up to the desired instance count while the "live" application instances are gradually stopped
## Related Information
Using Blue-Green Deployment To Reduce Downtime
## 4.1.8.1.9.2.1  Legacy Blue-Green Deployment
Use the legacy blue-green deployment strategy of Multitarget applications.
## Prerequisites
##  Restriction
Blue-green deployment is supported only for Cloud Foundry applications. It is not supported for bound services, such as service instances and their configuration, workflow content, and HTML5 repository content, among others. Live and idle applications are bound to the same service instances.
- You have a previously deployed MTA, with functional productive applications and routes:
- You have ensured that the changes in the new version of the application are compatible with the old version. This includes changes in the database tables, UAA configurations, and so on.
<!-- image -->
## Procedure
1. Deploy your updated MTA (the green version) by executing the cf bg-deploy &lt;your-mta-archivev2&gt; command.
The first action is that all MTA services are updated.
This action:
- creates new applications adding 'green' to their existing application names
- creates temporary routes to the 'green' applications.
- interrupts the process showing a message similar to the following:
<!-- image -->
## 
```
Output Code Process needs additional user input Use "cf bg-deploy -i 469520 -a resume" to resume the process Use "cf bg-deploy -i 469520 -a abort" to abort the process
```
2. Optionally, test the 'green' version using the temporary routes.
##  Note
You can skip this step by using one of the following command line options:
- --no-confirm - you have to use it when starting the process.
- --skip-idle-start - this option will also skip the start of the newly deployed applications on temporary routes.
3. If you do not want to make the 'green' version available, abort the process using cf deploy -i &lt;operation ID&gt; -a abort .
##  Note
This action does not perform a rollback and the state of apps, routes and services remains unchaged. Depending on your needs, you might want to remove the new app versions and the temporary routes.
4. To make the 'green' version productive, choose Resume .
This action:
- maps the productive routes to your green versions
- deletes the temporary routes
- restarts 'green' apps with productive route configurations
- restarts the applications, so that the environment URLs are updated
- deletes the 'blue' applications, which were productive before
<!-- image -->
<!-- image -->
## Results
For more detailed information and example results of the legacy blue-green deployment process, see Legacy Blue-Green Deployment .
## Related Information
Blue-Green Deployment of Multitarget Applications [page 705]
Blue-Green Deployment Strategy [page 708]
(Experimental) Incremental Blue-Green Deployment Strategy [page 711]
## 2. Module-Level and Resource-Level Parameters
If no command-line argument is provided, the module-level and resource-level parameters are considered next.
## Example :
<!-- image -->
## 3. Global-Level Parameters
If neither command-line options nor module-level parameter are provided, the global parameters are used. Global parameters are applicable for all applications.
<!-- image -->
## 4.1.8.1.9.5  Sequential Resource Processing
In various cases, some resources depend on other resources to already exist in order to process. Whenever an order of resource processing is necessary, the processed-after attribute can be utilized.
This attribute contains a list of resource names. It creates a sequence of services, an order, in which the services should be processed. If a resource has this attribute, it will be processed after the other resources in a higher position are processed.
##  Note
If the parameter processed-after is not specified, the resources are processed in parallel.
##  Note
The processed-after parameter is supported from schema version 3 onwards. If you attempt to use processed-after with schema version lower than 3, the deployment will ignore the attribute.
Example : Service A requires service B and service C to be processed first. On the other hand, both service B and service C require service D to be processed first. Service D does not require any other service to be proccessed. So the sequence for processing is - D → B, C → A.
## 
```
Sample Code MTA Deployment Descriptor (mtad.yaml) _schema-version: 3 ID: multiple-anatz version: 3.0.0 modules: - name: multiple-anatz type: staticfile resources: - name: serviceA type: org.cloudfoundry.managed-service parameters: service: application-logs service-plan: lite processed-after: [ serviceB, serviceC ] - name: serviceB type: org.cloudfoundry.managed-service parameters: service: application-logs service-plan: lite processed-after: [ serviceD ] - name: serviceC type: org.cloudfoundry.managed-service parameters: service: application-logs service-plan: lite processed-after: [ serviceD ] - name: serviceD type: org.cloudfoundry.managed-service parameters: service: application-logs service-plan: lite
```
In the example, the processed-after attribute ensures that serviceD is processed first, then serviceC and serviceB are processed in parallel, and finally serviceA is processed.
## Circular Dependencies
Due to a modelling error, you can create direct or transitive circular deployment order dependencies between resources. In such cases, it is reported as a deployment error.
## 4.1.8.1.9.7  Features Related to SAP Alert Notificaton service for SAP BTP
Deploy and update the SAP Alert Notification service for SAP BTP using the multitarget application concept, or get notified by the service about multitarget application operation status.
## Deploying and Updating the service
As an alternative to the manual procedure, you can use a deployment descriptor to automate the initial deployment of SAP Alert Notification service. You can use the same procedure to update the service parameters. See the procedure described in Configuration Management Using Multitarget Application Descriptors.
## Using the SAP Alert Notification service for BTP for alerts during deployment and undeployment of multitarget applications
You can set SAP Alert Notification service for SAP BTP to dispatch alerts to a communication channel of your choice, so that you are informed about the status of MTA deployment and undeployment operations. For example, if setup to do so, upon a successful deployment it can send you an e-mail or a Slack message. You can also get notified for problems in MTA operations, as you can also receive alerts if the deployment has encountered issues.
The integration between the services is out-of-the-box, that is, no special steps are required for its activation. If you have a service instance in the space where the MTA deployment takes place, it would automatically receive alerts from the MTA deployments in that space.
See how you can match events using multitarget operations as described in Multitarget Application Events.
To see additional details, see Receive instant notifications...with the SAP Cloud Deployment service .
## 4.1.8.1.10  Transporting Multitarget Applications in Cloud Foundry using CTS+
You can enable transport of SAP BTP applications and application content that is available as Multitarget Applications (MTA) using the Enhanced Change and Transport System (CTS+).
## Prerequisites
- You have configured your SAP BTP subaccounts for transport with CTS+ as described in the document How to...Configure SAP BTP, Cloud Foundry environment for CTS.
- The content that you want to transport can be made available as a Multitarget Application (MTA) archive as described in Multitarget Applications in the Cloud Foundry Environment [page 598].
## Context
You use the Change and Transport System (CTS) of ABAP to transport and deploy your applications running on SAP BTP in the form of MTAs, for example, from development to a test or production subaccount. Proceed as follows to be able to transport an SAP BTP application:
## Procedure
1. Package the application in a Multitarget Application (MTA) archive using the Archive Builder Tool as described in Defining Multitarget Application Archives [page 604].
2. Attach the MTA archive to a CTS+ transport request as described in How to...Configure SAP BTP, Cloud Foundry environment for CTS .
3. Trigger the import of an SAP BTP application as described in How to...Configure SAP BTP, Cloud Foundry environment for CTS .
## Related Information
<!-- image -->
Resources on CTS+
Setting up a CTS+ enabled transport landscape in SAP BTP
## 4.1.8.1.13  Troubleshooting
This topic contains information that is essential for troubleshooting issues.
Before you start investigating the problem, download the logs for the current deployment. The logs contain the following structure of files:
- OPERATION.LOG - contains the whole deployment log
- &lt;application-name&gt;.log - there is a separate file for each application. It holds the logs related to the application during staging and starting
##  Note
Note that the operation logs are kept for 3 days. Make sure that you download them before the retention period expires
To download the logs, execute the following command:
cf dmol -i &lt;process-id&gt;
 Example cf dmol -i cbe58aeb-0c40-4a3e-972d-82a499815745
## Troubleshooting an MTA Operation Failure
To troubleshoot issues, see the list of problems that may occur during the Multitarget Application deployment that is available in MTA Operation Failure [page 736].
## Creating an Incident
If the list does not contain a solution for your issue, you can contact the service support team by reporting an incident through the SAP Support Portal . Here is a list of what to provide in an incident:
1. Select the component BC-CP-CF-DS from the Component dropdown list.
2. In the description field, provide as much information as possible about the Cloud Foundry region, Cloud Foundry organization and space names and/or Global Unique Identifiers.
3. Provide information about scenario with the exact steps to be reproduced, expected result, actual result or the error that appears, relevant logs and screenshots. In all cases, the starting point for the investigation are the Multitarget Application operation logs.
## 4.1.8.2 Continuous Integration and Delivery
Learn how to integrate CI/CD into your development with the SAP Cloud Application Programming Model (CAP).
## 4.1.8.2.1 What Are Continuous Integration and Delivery?
Continuous Integration (CI) describes a software development process in which various team members frequently integrate their contributions into a single main line. Before each integration, the changes are verified through builds and automated testing. This allows you to detect errors as quickly as possible and prevent integration problems before completing the development.
<!-- image -->
## Continuous Integration Flow
The basic flow of Continuous Integration comprises the following steps:
1. The Developer writes code and pushes the code changes into a repository on a central source code management system (SCM).
2. The Source Code Management System triggers the Continuous Integration (CI) server.
3. The Continuous Integration server runs automated builds and tests and sends feedback about their outcome to the Developer.
As you can see from the figure above, Continuous Integration is a cycle: as soon as the CI server has sent its feedback to the developer, the flow starts over again. The developers either correct their previous code change, which must then be built and tested again, or start working on an entirely new one.
The Continuous Delivery (CD) concept expands on the one of continuous integration. It adds the aspect that any change that has successfully passed the tests is immediately ready to be deployed to production, both from a technical and qualitative point of view.
The following graphic shows the relation between Continuous Integration and Continuous Delivery:
Relation Between CI and CD
<!-- image -->
The Continuous Delivery process ensures that the most current version is successfully built, tested, and provided in a shippable format. Based on the release decision by the development team or delivery manager, it can be shipped to customers or deployed to production at any time.
For more information about the concepts and principles of Continuous Integration and Continuous Delivery, see the Continuous Integration and Delivery Introduction Guide.
## 4.1.8.2.2 SAP Continuous Integration and Delivery
SAP Continuous Integration and Delivery is a service on SAP BTP that helps development teams collaborate more effectively, improve the quality of their software, and speed up their delivery process. It provides readymade CI/CD pipelines for SAP-specific use cases that can be connected to a source repository to automatically build, test, and deploy code changes. This helps identify issues and prevent integration problems at an early stage in the development process.
The Continuous Integration &amp; Delivery service focuses on two key benefits: Simplicity and Flexibility .
## Simplicity
SAP Continuous Integration and Delivery offers predefined CI/CD pipelines that can be used out of the box. Depending on the development scenario they are used for, they only require minimal configuration. This means that even users without expertise in CI/CD can easily leverage the service for their needs. Additionally, the service includes the necessary infrastructure, freeing you from having to manage it yourself.
## Flexibility
By offering the ability to customize pipelines with additional commands, credentials, and variables, SAP Continuous Integration and Delivery provides a high degree of flexibility. With this option, the service does
not only cover standard use cases, but also addresses more complex scenarios. Additional commands enable you to expand your pipelines with various tasks that are executed before or after a certain stage. Additionally, extra credentials and variables allow you to further customize your CI/CD jobs.
## SAP Continuous Integration and Delivery for CAP
For how to configure a CI/CD pipeline for the development of applications that follow the SAP Cloud Application Programming Model, see Get Started with an SAP Cloud Application Programming Model Project in SAP Continuous Integration and Delivery (tutorial) and Configure a Cloud Foundry Environment Job (documentation).
## 4.1.8.3 Deploy Business Applications in the Cloud Foundry Environment
When an application for the Cloud Foundry environment resides in a folder on your local machine, you can deploy it and start it by executing the command line interface (CLI) command push . T o deploy business applications bundled in a multitarget application archive, you have to use the command deploy-mta .
- For more information about developing and deploying applications in the Cloud Foundry environment, see http:/ /docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html .
- For more information developing Multitarget Applications, see Multitarget Applications in the Cloud Foundry Environment [page 598]. See Multitarget Application Commands for the Cloud Foundry Environment [page 2554] for information about MTA deployment.
## Related Information
Download and Install the Cloud Foundry Command Line Interface [page 2533] Log On to the Cloud Foundry Environment Using the Cloud Foundry Command Line Interface [page 2534] Multitarget Application Commands for the Cloud Foundry Environment [page 2554]
## 4.2 Development in the ABAP Environment
Learn more about developing applications in the ABAP environment.
## Overview
The ABAP environment is a platform as a service that allows you to extend existing ABAP-based applications and develop ABAP cloud apps decoupled from the digital core. You can leverage your ABAP know-how in the cloud and reuse existing ABAP assets by writing your source code with ABAP Development Tools for Eclipse.
The ABAP environment enables you to expose :
- OData services. See ABAP RESTful Application Programming Model.
- HTTP services. See Working with the HTTP Service Editor.
- SQL services. See Data Federation Using the SQL Service.
- RFC function modules. See Providing an RFC Service.
- SOAP provider model. See Providing a SOAP Service.
With your ABAP applications, you can consume :
- HTTP services (HTTP client). See Outbound HTTP Administration Tasks.
- OData services (service consumption model). See Developing a UI Service with Access to a Remote Service.
- Remote Function Calls (RFC). See Outbound RFC Administration Tasks.
- On-premise systems via Cloud Connector. See Integrating On-Premise Systems [page 1099].
- SOAP-based Web services. See Outbound SOAP Administration Tasks.
## Technical Limits and Boundary Conditions for ABAP Applications
For elasticity, operability and protection reasons, the runtime of API or UI requests to ABAP applications is limited. After 10 minutes, running requests are automatically canceled. Tasks requiring longer runtimes have to be executed in Application Jobs, as background processes via the background processing framework (bgPF), or need to be split into smaller work packages. For an optimal user experience, all ABAP applications, including application jobs, have to be prepared to be interrupted and restarted even earlier than the maximum runtime. This allows to provide a continuous application service, unimpacted from scaling operations, maintenance activities or even infrastructure failures.
## Development Resources
ABAP RESTful Application Programming Model ABAP Development Tools for Eclipse: User Guide
ABAP CDS Development User Guide
Generative AI in ABAP Cloud ABAP Keyword Documentation [page 751] ABAP Lifecycle Management [page 757] Connect to the ABAP System [page 748] Providing an HTTP Service Integrating On-Premise Systems [page 1099] Supported Protocols and Authentication Methods Inbound Communication Working with abapGit [page 764]
## Related Information
Eclipse Tool for the ABAP Environment Learning Journey Manage Software Components [page 2914] Video Tutorials
## 4.2.1  Getting Started as a Developer in the ABAP Environment
Learn about your first steps to get started as a developer in the ABAP environment.
##  Note
This documentation informs you about the first steps as a developer and assumes that the necessary steps for setting up the ABAP environment are done. For more information about how to set up the ABAP environment and getting started as an administrator, see Getting Started with a Customer Account in the ABAP Environment [page 169].
## Developing Applications: Overview
<!-- image -->
- https:/ /tools.hana.ondemand.com/#abap [https:/ /tools.hana.ondemand.com/#abap]
- Connect to the ABAP System [page 748]
- https:/ /developers.sap.com/tutorials/abap-environmentgcts.html#b1afe95c-9acb-4f75-8f80-1abe93cb524f [https:/ /developers.sap.com/ tutorials/abap-environment-gcts.html#b1afe95c-9acb-4f75-8f80-1abe93cb524f]
- https:/ /help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/ 31367ef6c3e947059e0d7c1cbfcaae93.html [https:/ /help.sap.com/viewer/ 65de2977205c403bbc107264b8eccf4b/Cloud/en-US/31367ef6c3e947059e0d7c1cbfcaae93.html]
- https:/ /help.sap.com/viewer/DRAFT/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/ 59656c2f858748fe976456248d390c5c.html [https:/ /help.sap.com/viewer/DRAFT/ 65de2977205c403bbc107264b8eccf4b/Cloud/en-US/59656c2f858748fe976456248d390c5c.html]
- https:/ /help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/ 31367ef6c3e947059e0d7c1cbfcaae93.html [https:/ /help.sap.com/viewer/ 65de2977205c403bbc107264b8eccf4b/Cloud/en-US/31367ef6c3e947059e0d7c1cbfcaae93.html]
1. Download and install ABAP Development Tools (ADT) from https:/ /tools.hana.ondemand.com/#abap. See Video Tutorial: Configure ABAP Development Tools .
##  Note
SAP GUI is not supported in the ABAP environment. You can only use ADT as your development environment.
2. Create an ABAP cloud project with ADT to connect to the ABAP system in the ABAP environment (see Connect to the ABAP System [page 748]).
3. Develop your application (see Development in the ABAP Environment). To learn more about how to develop applications, see Tutorial: Create Your First ABAP Console Application and Video Tutorial: Create Application .
## More Information About Development in the ABAP Environment
For more information about ABAP development, see Development in the ABAP Environment.
## 4.2.1.1 Connect to the ABAP System
Set up your ABAP cloud project to connect to the ABAP system.
## Prerequisites
- You are assigned the developer role. See Assigning the ABAP Developer User to the ABAP Developer Role [page 196] and Creating Service Keys.
##  Note
The process for connecting to an ABAP service instance URL when creating a new ABAP Cloud project in ABAP development tools for Eclipse has changed. For more information, see ABAP Service Instance URL [page 1772].
- You have downloaded and installed the front-end components of ABAP Development Tools (ADT). See Video Tutorial: Configure ABAP Development Tools.
- You are a member of the relevant space in the Cloud Foundry environment, see Add Space Members Using the Cockpit, or you have a service key in JSON format, see Creating Service Keys.
## Procedure
1. Open Eclipse and select File New ABAP Cloud Project from the menu.
2. To establish a service instance connection, you have the following options:
- a. Insert the URL from the SAP Fiori launchpad of your system.
- b. If you still have a service key available, you can extract the URL from it by clicking the link shown in the description of the window you're in: Do you have a service key? Extract the URL from the service key. In this case, a new window opens up where you can paste in your service key. Next, choose Copy to Clipboard . Now, you're in the Connect to an ABAP Service Instance window again and you can paste in the service instance URL. Choose Copy logon URL to clipboard and paste the URL into your browser to log on to the system.
3. To create your ABAP cloud project, select Finish .
## Results
You have created an ABAP cloud project that is added to the Project Explorer .
##  Note
To verify your result, expand the first level of the project structure. Make sure that the following nodes are included:
- Favorite Packages : Contains the local packages and the packages that you have added to your favorites.
- Released Objects : Contains all released SAP objects that are available to use or reuse.
## Related Information
Video Tutorial: Create ABAP Cloud Project Video Tutorial: Create Package &amp; Persistence Tutorial: Create Your First ABAP Console Application ABAP Cloud Projects
## 4.2.2  ABAP Development Tools for Eclipse: User Guides
Get an overview of all available user guides for ABAP development tools for Eclipse.
## ABAP Development Tools for Eclipse
This guide describes the tool set and functionality of ABAP development tools for Eclipse:
- Joule for developers, ABAP AI capabilities supports you in the end-to-end development using generative AI and can be integrated into ABAP development tools for Eclipse. It's currently only available for customers using SAP BTP ABAP environment or SAP S/4HANA Cloud Public Edition. To leverage Joule for developers, ABAP AI capabilities, you need to purchase an additional license. See Getting Started.
- Within the ABAP core development scenario: In particular, it focuses on use cases for creating, editing, testing, debugging, and profiling development objects like ABAP classes, ABAP Dictionary objects, function modules and so forth.
- For Core Data Services (CDS) in ABAP development for SAP HANA scenarios: In particular, it focuses on use cases for creating, editing, testing, and analyzing ABAP CDS entities like data definitions and so forth.
- When developing all types of SAP Fiori applications as well as publishing Web APIs in the context of the Joule for developers, ABAP AI capabilities (RAP).
- When creating lifecycle-stable and cloud-ready business apps, services, and extensions in the context of the ABAP Cloud development model.
- For the integration of native SAP HANA objects (in the context of SAP HANA repository content) within the ABAP layer.
## Generative AI in ABAP Cloud
This guide describes how generative AI supports you in the end-to-end development for ABAP Cloud.
## 4.2.3  ABAP Data Models Guide
In the ABAP Cloud development model, data models used for ABAP applications are based on ABAP Core Data Services (ABAP CDS). ABAP CDS is used for defining and consuming semantically-rich data models optimized for SAP HANA. ABAP data models can be used as the foundation for analytical and transactional ABAP applications, as well as enterprise search models. The ABAP Data Models Guide provides information on the different aspects of ABAP data models and their components.
<!-- image -->
- https:/ /help.sap.com/docs/abap-cloud/abap-data-models/abap-tuning-objects?locale=en-US [https:/ / help.sap.com/docs/abap-cloud/abap-data-models/abap-tuning-objects?locale=en-US]
- https:/ /help.sap.com/docs/abap-cloud/abap-data-models/tuning-objects?locale=en-US [https:/ / help.sap.com/docs/abap-cloud/abap-data-models/tuning-objects?locale=en-US]
- https:/ /help.sap.com/docs/abap-cloud/abap-data-models/annotations-in-abap-cdsb22c173af13f426689e977ecff7ccf2b?locale=en-US [https:/ /help.sap.com/docs/abap-cloud/abapdata-models/annotations-in-abap-cds-b22c173af13f426689e977ecff7ccf2b?locale=en-US]
- https:/ /help.sap.com/docs/abap-cloud/abap-data-models/data-types-in-abap-cdsf04708ca02d345e18fecbbd9a1eb9eb7?locale=en-US [https:/ /help.sap.com/docs/abap-cloud/abapdata-models/data-types-in-abap-cds-f04708ca02d345e18fecbbd9a1eb9eb7?locale=en-US]
- https:/ /help.sap.com/docs/abap-cloud/abap-data-models/functions-in-abap-cds?locale=en-US [https:/ / help.sap.com/docs/abap-cloud/abap-data-models/functions-in-abap-cds?locale=en-US]
- https:/ /help.sap.com/docs/abap-cloud/abap-data-models/entity-modeling?locale=en-US [https:/ / help.sap.com/docs/abap-cloud/abap-data-models/entity-modeling?locale=en-US]
•
https:/ /help.sap.com/docs/abap-cloud/abap-data-models/cds-authorization-concept?locale=en-
US [https:/ /help.sap.com/docs/abap-cloud/abap-data-models/cds-authorization-concept?locale=en-US]
- https:/ /help.sap.com/docs/abap-cloud/abap-data-models/cds-projection-views?locale=en-US [https:/ / help.sap.com/docs/abap-cloud/abap-data-models/cds-projection-views?locale=en-US]
- https:/ /help.sap.com/docs/abap-cloud/abap-data-models/cds-aspects?locale=en-US [https:/ / help.sap.com/docs/abap-cloud/abap-data-models/cds-aspects?locale=en-US]
## 4.2.4  ABAP Keyword Documentation
The ABAP keyword documentation describes the syntax and meaning of the keywords of the ABAP language and its object-oriented part - ABAP objects.
## Context
The ABAP keyword documentation provides you with context-sensitive information for your ABAP source code.
## Accessing ABAP Language Help
To access the ABAP language help from the source code editor, position your cursor on an ABAP statement for which you need help, and press F1 . The language help is displayed in a separate window.
To view the entire ABAP keyword documentation, see ABAP - Keyword Documentation.
## 4.2.8  Background Processing Framework
The background processing framework (bgPF) is a framework that asynchronously and reliably executes methods of applications that develop background processes.
The background processing framework (bgPF) is designed to execute methods of applications that develop background processes asynchronously and reliably. It is beneficial in applications that require time-consuming processes, enabling users to continue with other tasks while bgPF handles the processes in the background. bgPF is built on the background remote function call (bgRFC). It supports both transactional and queued background processes. In conjunction with the ABAP RESTful Programming Model (RAP), bgPF provides transactional control to maintain data consistency. The framework offers several advantages, including transactional consistency and integration with various ABAP tools. It is part of the standard functionality in ABAP Cloud and supports easy code testing.
Find more information in the Background Processing Framework documentation.
## 4.2.9  ABAP Lifecycle Management
This chapter helps you to plan and set up your landscape and lifecycle management by describing how software components can be used and which possibilities you have for transportation of development objects and business configuration.
## 4.2.9.2 Transport Mechanisms
There are two git-based transport mechanisms in the ABAP environment.
Git-based CTS (gCTS ) is the evolution of the classical Change and Transport Management System (CTS). It is the recommended approach for transporting objects between ABAP systems in your global account. It offers built-in and easy to use functionalities provided by the Manage Software Components app in your SAP Fiori launchpad.
abapGit is an open-source Git client that allows you to import existing code into your ABAP system. You should use it for the following use cases:
- Migrate on-premise code to the cloud. See Use abapGit to Transform ABAP Source Code to the Cloud .
- Transfer your code from the cloud to on premise. See Transfer Your ABAP Source Code With SAP BTP ABAP Environment via abapGit .
- Export your code when the development ABAP system is decommissioned.
- Transfer your code from one cloud to another to share it with others, for example as open source, or from a partner to a customer account.
- Implement mechanisms for distributed development and testing in dedicated development/test ABAP systems. This can be useful for special projects, such as proof of concepts or features that are dependent on regular development of a solution but shall run independent from its lifecycle.
- To learn more about abapGit, see Working with abapGit [page 764].
For a quick start on transportation, see Transport a Software Component Between Two ABAP Systems . For more information about the according delivery process, see Delivery via Add-On or gCTS.
## 4.2.9.4.1 Install and Set Up abapGit
Learn how to install and set up abapGit.
- You have signed up for a Git account of your choice, for example GitHub.
- You have downloaded and installed the front-end components of ABAP Development Tools (ADT).
##  Restriction
Please be aware that abapGit is an open-source project maintained by the open source community and is not owned by SAP. Therefore, SAP does not provide support for the open source abapGit version (ZABAPGIT). Consequently, we ask you to refrain from creating incidents related to the use of the ZABAPGIT report. However, for the SAP BTP ABAP environment, a separate SAP-owned version (fork) of abapGit has been established. SAP does provide standard support for this version.
## Part 1: Create a Git repository
1. Log on to your github.com account.
2. Create an abapGit repository by clicking on New repository .
3. Enter a repository name, tick the Initialize this repository with a README checkbox, and select Create repository .
## Part 2: Install zabapGit for the on-premise use case
1. Copy the content of the latest build from program zabapgit to your clipboard. You can find the content in the abapGit repository https:/ /github.com/abapGit/abapGit .
##  Caution
Check with your system administrator before installing zabapgit .
2. Log on to an on-premise system of your choice, create a new program, and paste the content from your clipboard.
##  Note
Select EN as your logon language.
3. Activate and execute the program.
abapGit is installed and launched.
## Part 3: Install an ABAP Development Tools for Eclipse Plugin for abapGit
1. Log on to ABAP development tools for Eclipse.
2. Navigate to Help Install New Software... .
3. To install the abapGit repositories ABAP development tools for Eclipse plug-in, add the following URL: https://eclipse.abapgit.org/updatesite/ and provide a name for the repository.
4. To display all the available features, press enter, and select abapGit for ABAP development tools for Eclipse .
5. Select Next to finish the installation.
## Related Information
Create Content in an On-Premise System and Push it to abapGit Repository
## 4.2.9.4.2 Create Content in an On-Premise System and Push it to abapGit Repository
## Prerequisites
You have installed and set up abapGit. See Install and Set Up abapGit [page 768].
##  Restriction
Please be aware that abapGit is an open-source project owned by the community. Therefore, we do not provide support for abapGIT. We only support the Git integration in the ABAP environment.
## Procedure
1. After installing and launching abapGit, select Clone or download , and copy the URL of your repository.
2. Call up transaction ZABAPGIT , and select + Online .
3. Paste the URL of your repository.
4. Select Create package .
##  Note
If you have already created a software component with gCTS, you can skip steps 4 to 6 and use this software component in step 7.
5. Add a package name and short description, and select Continue .
6. Confirm with OK .
The cloned abapGit repository is displayed in abapGit.
7. Log on to ABAP Development Tools in Eclipse, and navigate to your newly created package.
8. Add ABAP development objects to your package. See Released ABAP Object Types [page 780].
9. Navigate back to the abapGit UI, and select Refresh to display the development objects that you have created in Eclipse.
10. Choose Stage .
11. Select single objects or choose Add all and commit .
##  Note
You can also select structure packages to be exported.
12. Enter a committer name , committer e-mail , and comment .
13. Select Commit .
14. In the Login popup, enter your abapGit repository server credentials, and select Execute .
The pushed ABAP objects are displayed in your abapGit repository.
## Next Steps
Import Content from abapGit Repository into the ABAP Environment [page 770]