orkungedik/SAP-basis-dataset huggingface dataset:
## 4.2.14.1.5.2  Prepare
Before you can proceed with the development of the add-on, you have to perform several preliminary steps.
- Register the development namespaces before any system is set up. To start the actual add-on development process, you have to set up the system landscape and global account structure for development. For pipeline automation, set up a CI/CD server, in this case a Jenkins server.
- Create one or more software components that make up the add-on in the namespaces registered for you. In this scenario, namespaces are required for both the add-on product name and software components. You can register these namespaces with the development namespace/license keys tool.
- Purchase the SAP BTP, Cloud Foundry environment entitlements necessary for the account setup, which includes the service ABAP environment for development. The ABAP environment (service plan saas\_oem ), Application runtime, SaaS provisioning, ABAP Solution service as well as the Landscape Portal are used for providing the SaaS app.
##  Recommendation
We recommend using the browser-based IDE SAP Business Application Studio for UI development. In this case, additional configuration is required to enable developers to use this service.
Once you've completed these steps, you can start developing an add-on.
## Prerequisites
- To register a namespace, you need an S-user in SAP One Support Launchpad with authorization to reserve a development namespace. See SAP note 1271482 .
- To set up global accounts for development and poduction, you need two global accounts on the SAP Business Technology Platform with the corresponding entitlements for services and applications. See Entitlements and Quotas.
- To create ABAP instances, you have to set up the account structure in the global account for development, and assign entitlements for each subaccount. See Configure Entitlements and Quotas for Subaccounts.
- To develop UIs, you need an entitlement for SAP Business Application Studio and an assignment to a subaccount for development. See SAP Business Application Studio.
- To set up transports from the development to the test system, you need a test system and optionally a pipeline in a Jenkins CI/CD server that is provisioned using a Cx Server to automatically import new changes. See Jenkins and Cx Server .
- To set up add-on development, you need a development system.
## 4.2.14.1.5.2.1  Register a Namespace
Using a reserved namespace for add-on development and build is necessary for a unique add-on product and software component name.
##  Note
You need to register a namespace before the first ABAP system is provisioned. To activate namespaces in already existing systems after system provisioning, see Maintain Namespaces.
If you need a new S-user, get in touch with a user administrator in SAP ONE Support Launchpad.
As an S-user with authorization Reserve Namespaces , you have to reserve a namespace for your partner customer ID to register a namespace with the Namespace app. See Namespace Application .
Due to length restrictions of some objects, namespaces should have 5-8 characters. See SAP note 105132 and 395083 .
## 4.2.14.1.5.2.3  Set Up a Global Account for Production
As a SaaS solution operator, you have to configure the global account for production.
<!-- image -->
##  Recommendation
We recommend the following subaccount structure:
In the 00 Landscape Portal subaccount, your subscription to the Landscape Portal is created. If required, the CI/CD service should also be subscribed in this subaccount. No Cloud Foundry environment is required.
In the 05 Provide subaccount, the add-on product is provided as a SaaS solution for production purposes in the production phase. The solution is consumed by your customers from consumer subaccounts.
In the provider context, the ABAP environment (saas\_oem) service plan is used.
##  Note
In the provider subaccount, the entitlement for an ABAP instance of service plan type abap/ standard needs to be available.
Additionally, considering the availability of software components only in the same global accounts, you have to create the production systems as well as development and test systems in the same global account.
See Delivery via Add-On or gCTS [page 1214].
These provider ABAP instances allow flexible sizing, multitenancy, and the possibility to install an add-on product during provisioning.
For the provisioning of these ABAP systems of service plan saas\_oem , another set of services comes into play: With the ABAP Solution Provider and the saas-registry service, you can provide your add-ons as SaaS solution offerings. See ABAP Solution Service [page 1251].
Note that these service entitlements must be assigned to different subaccounts, according to the following structure:
| Global Account                  | Subaccount   | Space   | Services                                                                                                                                      |
|---------------------------------|--------------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------|
| Global Account for Produc- tion | 05 Provide   | Provide | abap/saas_oem abap/hana_compute_unit (standard: 4) abap/abap_compute_unit (standard: 1) Application Runtime abap-solution saas-registry xsuaa |
Additionally, the following entitlements for SaaS application subscriptions are required:
- Web access for ABAP for access to systems during the development phase. See Subscribing to the Web Access for ABAP.
- Landscape Portal to manage systems and tenants in the provider subaccount. See Landscape Portal.
If you want to integrate an existing corporate identity provider in the subaccounts of the global account for production for authentication/authorization, see Trust and Federation with Identity Providers [page 2280]. To restrict access based on certain criteria such as the IP address, you need to use the SAP Cloud Identity Services - Identity Authentication.
##  Tip
For in-depth information about the system landscape/account model, check out System Landscape/ Account Model [page 1192].
## 4.2.14.1.5.2.4  Create ABAP Instances
As a SaaS solution operator, you have to create ABAP instances.
For development and testing in the development codeline, one system is provisioned in each of the development and test subaccounts. Use service parameter is\_development\_allowed to differentiate between development and production systems. The test and assembly systems must be productive to avoid changes being made to the add-on outside of the development system.
| Global Account                   | Subaccount   | Space   | ABAP Instances                                                                           |
|----------------------------------|--------------|---------|------------------------------------------------------------------------------------------|
| Global Account for Develop- ment | 01 Develop   | Develop | Create an ABAP instance (abap/standard) DEV Set parameter is_development_allo wed = true |
| Global Account   | Subaccount   | Space   | ABAP Instances                                                                            |
|------------------|--------------|---------|-------------------------------------------------------------------------------------------|
|                  | 02 Test      | Test    | Create an ABAP instance (abap/standard) TST Set parameter is_development_allo wed = false |
##  Note
You don't have to create an ABAP instance in the 03 Build/Assemble , 04 Build/Test , and 05 Provide subaccount because the system is created automatically.
In the 03 Build/Assemble account, assembly systems are provisioned by the add-on build pipeline. These systems are used to import the desired software components that are then packaged for add-on delivery (see Software Assembly Integration (SAP\_COM\_0582) [page 846]). As an operator, you don't have to provision these systems manually.
In the 04 Build/Test subaccount of the global account for production, an add-on installation test system is automatically created. This ABAP environment service instance of plan saas\_oem is provisioned with parameter is\_development\_allowed = false .
In the 05 Provide subaccount of the global accounts for development and production, a customer production system is created automatically by the ABAP Solution Service during the first subscription. For more information on how to get started with your customer account, see Getting Started with a Customer Account in the ABAP Environment [page 169] and Creating an ABAP System.
Use service parameter is\_development\_allowed to differentiate between development and production systems. The test and assembly systems must be productive to avoid changes being made to the add-on outside of the development system.
Subscribe to the Web Access for ABAP to gain access to the SAP Fiori launchpad in all subaccounts of the global production account.
## 4.2.14.1.5.2.5  Set Up UI Development
As a SaaS solution operator, you have to set up SAP Business Application Studio for development.
As a developer user, you can then create an SAP Fiori dev space and generate UI projects.
##  Recommendation
For frontend development, we recommend using SAP Business Application Studio. See Develop an SAP Fiori Application UI and Deploy it to ABAP Using SAP Business Application Studio [page 1750].
## 4.2.14.1.5.2.6  Set Up Add-On Development
Learn how to set up add-on development by creating and importing software components. Furthermore, read about configuring ABAP Test Cockpit checks and check variants, as well as enabling transport blocking to fix issues early on during development.
## Create and Import Software Components
To transport new developments from system to system, the add-on development is structured by software components. Software components are independent development containers.
To create a new software component for add-on development, as an add-on admin user, use the Manage Software Components app and create a new component of type Development . The name of the software component begins with a namespace that was activated in the development system. By default, all namespaces of the global account owner are enabled in the systems. See How to Create Software Components.
Clone the main branch of the software component to the development and test system.
Software components in the development and test system should always stay on the main branch. If you want to work on maintenance branches to develop bug fixes and other maintenance deliveries, create a dedicated hotfix development and test system (maintenance codeline).
##  Tip
For in-depth information about versioning and branches, check out Versioning and Branches. In case you are creating software components with dependencies to each other, make sure to declare these dependencies in software component relations. Refer to Software Component Relations.
## Configure ABAP Test Cockpit Checks, Check Variants
By default, a check variant ABAP\_CLOUD\_DEVELOPMENT\_PARTNER is generated in ABAP environment systems. You should use this variant for ABAP Test Cockpit check runs or create a custom check variant based on it. See Creating ATC Check Variants. You can also create custom ABAP Test Cockpit checks. See Creating ATC Checks.
Custom ABAP Test Cockpit checks and check variants are created as part of a software component, whereas the default check variant is generated locally.
##  Note
We recommend running ATC checks using at least those checks included in the ABAP\_CLOUD\_DEVELOPMENT\_PARTNER check variant. Depending on your use case, it makes sense to add additional ATC checks to a custom check variant instead.
## Configure ABAP Test Cockpit to Interrupt Transport Releases
We recommend enabling the blocking of transport releases in case of priority 1 (error) and priority 2 (warning) findings using the default check variant ABAP\_CLOUD\_DEVELOPMENT\_DEFAULT or a custom check variant. You can enable transport blocking in the ABAP Test Cockpit Configurator app. See ABAP Test Cockpit Configurator.
Interrupting a transport release in case of severe findings can help to fix issues early on during development. The later errors are detected in the development process, the more costly it is to resolve them. See Launching ATC Check Implicitly.
## 4.2.14.1.5.2.7  Set Up Transport from Development to Test System
You can perform the import of your software components into a test system either manually by using the Manage Software Components app or in an automated way using the ABAP Environment Pipeline [page 1198].
## Manual Import into Test System
As an add-on admin user, you can pull the latest released changes of a software component to the test system by using the main branch. You can test these changes in the test system independent from ongoing development. See Pull Software Components [page 2918] and ABAP Lifecycle Management [page 757].
## Automatic Import into Test System with ABAP Environment Pipeline
<!-- image -->
As a DevOps engineer, you can configure the ABAP environment pipeline for an automated import of software components to test system TST. With the pipeline, the pulling of specified software components is automated and performed on a regular schedule.
The continuous testing scenario of the ABAP environment pipeline is described in detail in Continuous Testing on SAP BTP ABAP Environment .
## 00 Landscape Portal
- Entitlements: Landscape Portal (1x standard), Continuous Integration and Delivery (1x default)
- Subscriptions: Landscape Portal, Continuous Integration and Delivery
- Administrator users have role collections Subaccount Administrator and LandscapePortalAdminRoleCollection .
- Viewer users have role collections Subaccount Viewer .
## 03 Build/Assemble
- Entitlements: abap (1x standard, 2x abap\_compute\_unit, 2x hana\_compute\_unit)
- Subscriptions: -
- Cloud Foundry is enabled
- 1 Cloud Foundry space is created
- If configured, an ABAP environment instance is provisioned
- Administrator users have role collection Subaccount Administrator , are CF Org Managers and Space Managers
- Viewer users have role collection Subaccount Viewer , are CF Org Members and Space Developers
- The specified technical user is granted the same authorizations as the viewer user group.
## 04 Build/Test
- Entitlements: abap (1x standard, 2x abap\_compute\_unit, 2x hana\_compute\_unit), Web Access for ABAP (1x default)
- Subscriptions: Web Access for ABAP
- Cloud Foundry is enabled
- 1 Cloud Foundry space is created
- Administrator users have role collection Subaccount Administrator, are CF Org Managers and Space Managers
- Viewer users have role collection Subaccount Viewer , are CF Org Members and Space Developers
- The specified technical user is granted the same authorizations as the viewer user group.
After executing the booster, you maintain the same technical user(s) in the Credentials section of the Build Product Version app.
You are then ready to configure one or more pipeline templates, see Configure a Pipeline Template.
When configuring a template, reuse the resources created by the booster as follows:
For the "Prepare System" stage, reuse the subaccount/CF space from the 03 Build/Assemble subaccount. If you provisioned a system during the booster execution, specify its instance name in the template so that it will be used.
For the "Integration Tests" stage, reuse the subaccount/CF space from the 04 Build/Test subaccount. If you provisioned a system during the booster execution, specify its instance name in the template so that it will be used.
## 4.2.14.1.5.3  Develop
Both the initial implementation and any further development of the add-on are performed in the development system of the development subaccount.
You can use various SAP technologies at this point, such as the ABAP RESTful application programming model (RAP) for modeling and implementing business objects and the browser-based IDE SAP Business Application Studio for developing SAP Fiori UIs. Depending on the business use case, some additional development effort may be necessary to implement suitable launchpad content, Identity &amp; Access Management artifacts, or communication management artifacts.
Once you've completed these development activities, the solution is ready to be tested in a suitable test system.
## Prerequisites
- For ABAP development, you need a developer user using ABAP development tools for Eclipse. See Getting Started as a Developer in the ABAP Environment [page 221].
- For UI development, you need a developer user using SAP Business Application Studio. See Develop an SAP Fiori Application UI and Deploy it to ABAP Using SAP Business Application Studio [page 1750].
- For custom code migration, you need a business user that is assigned the business role based on business role template SAP\_BR\_IT\_PROJECT\_MANAGER , and a communication arrangement instance for SAP\_COM\_0464 . See Custom Code Analysis [page 2660].
## 4.2.14.1.5.3.2  UI Development
SAP Fiori applications are developed in SAP Business Application Studio on top of business services in the ABAP development system and then deployed to the ABAP development system to be part of the same software component as backend artifacts.
As a developer user, once business services are implemented as UI services, you can create SAP Fiori elements apps using SAP Business Application Studio. See Develop an SAP Fiori Application UI and Deploy it to ABAP Using SAP Business Application Studio [page 1750].
##  Note
To grant business users access to an app, the consumer's administrator creates corresponding business roles. Moreover, to influence the layout for specific user groups. the administrator can maintain corresponding space and page templates. It's recommended to provide business role templates with business catalogs and corresponding space and page templates as part of an add-on. This simplifies the process and speeds up the configuration of the Fiori launchpad for each consumer.
As described in Scoping Space and Page Templates [page 1761], space and page templates need to be scoped manually in the development system. However, these are scoped automatically in consumer tenants.
## 4.2.14.1.5.3.3  (Optional) Code Migration from On-Premise
Optionally, you can migrate existing custom ABAP code for add-on development purposes. This custom code migration process analyzes your existing code for cloud-readiness. See How to Check your Custom ABAP Code for SAP BTP ABAP Environment and Custom Code Analysis [page 2660].
After adapting the code and making necessary changes, you can migrate the code via abapGit. See How to Bring your ABAP Custom Code to SAP BTP ABAP Environment .
## 4.2.14.1.5.4  Test
Once development has been completed, you can test the solution in the test subaccount that you have previously set up. The software components that make up the solution are imported into a provisioned test
system, while any additionally required configuration has to be carried out by you. This may entail creating suitable business roles, maintaining communication arrangements, or other administrative tasks performed via the SAP Fiori launchpad of your ABAP system.
You can also use a CI/CD server and a Jenkins pipeline to automate the test process. This allows you to schedule regular tests and to be notified as soon as issues arise within the solution.
If the solution is successfully tested and works correctly, you can proceed with the add-on build.
## Prerequisites
- For testing in SAP Fiori launchpad in your ABAP environment, you need a business user in the test system that has the required authorizations to use the Manage Software Components app as well as authorizations that are required as a test user.
- For testing in the ABAP Test Cockpit, you need a developer user using ABAP Development Tools. See Getting Started as a Developer in the ABAP Environment [page 221].
- (Optional) For running ATC checks as part of the ABAP environment pipeline, you have to create a pipeline in a Jenkins CI/CD server. See Jenkins and Custom Jenkins Setup .
## 4.2.14.1.5.4.2  Test in the ABAP Test Cockpit
## Manual Testing During Development
With the ABAP Test Cockpit, you can run a set of checks (check variants) on software component or package level. See Checking Quality of ABAP Code with ATC and ABAP Test Cockpit in the Cloud - What is already possible .
To fix and revalidate ABAP Test Cockpit findings, as a developer user, you can run ABAP Test Cockpit checks on developed software components explicitly via ABAP Development Tools in the DEV system. See Launching ATC Check Run from the Project Explorer and Launching ATC Check Run Explicitly.
If transport blocking in case of ABAP Test Cockpit findings is configured (see Set Up Add-On Development), ABAP Test Cockpit checks are executed implicitly. See Launching ATC Check Implicitly.
## Continuous Testing Using ABAp Environment Pipeline
<!-- image -->
To schedule a regular execution of ABAP Test Cockpit checks for a software component in the test system, you can use a CI server and pipeline to automate this process. You can reuse the previously described setup of a transport from development to test system using the ABAP environment pipeline. See Set Up Transport from Development to Test System.
As a DevOps engineer, configure the ABAP environment pipeline by using a static and preconfigured system. With the pipeline, the following steps are then automated, triggered by the pipeline execution of a Jenkins administrator:
- Pulling the specified software components/Git repositories
- Running the configured ABAP Test Cockpit checks
The continuous testing scenario of the ABAP environment pipeline is described in detail in Continuous Testing on SAP BTP ABAP Environment .
## 4.2.14.1.6  Order and Provide
After the initial add-on version has been built, you must deploy and provide it as a SaaS solution so that the add-on can be consumed by customers via a subscription in the SAP BTP cockpit.
## 4.2.14.1.6.1  Deploy
In order to offer a multitenant application based on an ABAP add-on product, a multi-target application (MTA) is developed and deployed to the Cloud Foundry environment on SAP BTP. The MTA integrates the different services required for this scenario, such as the ABAP Solution service, responsible for provisioning ABAP systems, tenants, and users on demand. For more in-depth information, see Multitenant Applications [page 1248].
Once you've configured your multitenant application, you can deploy it once for testing purposes in the global account for development. After testing the subscription process during this development phase, the multitenant application can be deployed to the global account for production. See System Landscape/Account Model.
After the multitenant application has been deployed for production purposes, the SaaS solution is ready for commercialization.
You have two options for implementing and deploying the application. The recommended approach is to use the Maintain Solution app in the Landscape Portal. See Maintain Solution.
Alternatively, you can create your own multitenant application. This allows you to modify parameters that are not exposed in the Maintain Solution app; however, the app should cover all common use cases. See Developing Multitenant Applications in the Abap Environment.
## gCTS Delivery
If you use gCTS instead of add-ons for delivering software components to production systems, you have to configure the multitenant application manually. In the configuration of the ABAP solution service the value for the add-on product name must be left empty. This is currently not supported by the Maintain Solution app. See Delivery via Add-On or gCTS.
## Prerequisites
- To configure the sizing of a SaaS solution, you have to determine the expected load per region by using the Technical Monitoring Cockpit. See Technical Monitoring Cockpit (Cloud Version).
- To implement and deploy a multitenant application for a SaaS solution, you have to assign the necessary entitlements in the provider subaccount, for example for the ABAP Solution service. See Multitenant Applications [page 1248] and Entitlements and Quotas.
## 4.2.14.1.6.1.1  Sizing
A multitenant application has some central sizing properties that dictate the scope and metric of your offering, or in other words, how many resources will be available for each consumer.
Tenant Limit: Before deploying your application, you must decide on a tenant limit. Once that number of consumer tenants is reached in a system, a new system will be provisioned for the next consumer. If you choose a limit of 1, you will be defining a single tenant offering with one consumer per system.
##  Tip
For in-depth information about multitenancy, see this section.
Additionally, you need to define the sizing of each provisioned ABAP system. The sizing is defined by the number of ABAP compute units (runtime) and HANA compute units (persistence) each system is assigned. These values are reflected by the parameters size\_of\_runtime and size\_of\_persistence. For more information, see Creating an ABAP System [page 183].
For multitenancy offerings, there's no sizing/quota per customer. You must decide on an overall sizing depending on the expected load in a region. You can use the Technical Monitoring Cockpit to assist you in this.
##  Note
If the quota for a system is exceeded, you can request a resizing of the ABAP runtime or persistency depending on the needs of the SaaS application.
## 4.2.14.1.6.1.4.2  SAP Authorization and Trust Management Service
<!-- image -->
```
- $XSAPPNAME(application,sap-provisioning,tenant-onboarding) foreign-scope-references: - uaa.user role-collections: - name: ${appname}-admin role-template-references: - $XSSERVICENAME(${appname}-abap-solution).SolutionAdmin
```
The xsuaa service instance, acts as an OAuth 2.0 client to the multitenant application, and to the ABAP Solution service instance. It provides access to the SaaS Provisioning service for calling callbacks and getting the dependencies API by granting corresponding scopes.
A role collection is defined as part of the xsuaa configuration which provides authorization for the initial user onboarding in the new ABAP tenant after a subscription was done.
For this purpose, the 'SolutionAdmin' role is referenced. See Quick Start: Create Role Collections (with Predefined Roles).
Finally, a foreign scope reference is defined to ensure a token exchange will be possible and the ABAP systems can be called.
## 4.2.14.1.6.1.4.5  Cloud Controller Access Destination
A destination called ASP\_CC needs to be created for ABAP Solution Service to be able to access the Cloud Foundry Cloud Controller API for creation and access to ABAP service instances.
## Prerequisites
- You've created a user in SAP ID service.
- The user has been added as a Cloud Foundry org member in the provider subaccount where the Cloud Foundy environment is enabled.
- The User has been added with the role of a Space Developer, in the space where the multitenant application (MTA) is deployed.
##  Note
Please note that you should never set personal credentials (e.g. for your account) in the User and Password fields. Always use a technical user instead.
## Process Steps
1. In the provider subaccount navigate to Connectivity -&gt; Destinations
2. Create a new destination as follows:
| Property       | Value                                                                                                         |
|----------------|---------------------------------------------------------------------------------------------------------------|
| Name           | ASP_CC                                                                                                        |
| Type           | HTTP                                                                                                          |
| Description    | Access the Cloud Foundry Cloud Controller API                                                                 |
| URL            | < API Endpoint domain of Cloud Foundry landscape> You can find it under your subaccount > Overview.  Example |
| Proxy Type     | Internet                                                                                                      |
| Authentication | OAuth2Password                                                                                                |
| User           | <User ID/E-mail>                                                                                              |
| Password       | <Password>                                                                                                    |
| Client ID      | cf                                                                                                            |
| Client Secret  | <needs to be left blank>                                                                                      |
<!-- image -->
<!-- image -->
| Property          | Value                                                          |
|-------------------|----------------------------------------------------------------|
| Token Service URL | https:/ / uaa.<landscape-host>/oauth/token                     |
|                   |  Example https:/ /uaa.cf.eu10.hana.ondemand.com/oauth/to- ken |
For more information on landscapes/regions, see Regions and API Endpoints for the ABAP Environment.
Instead of creating the ASP\_CC destination manually, you can also save the following as a text file instead and then import the destination as a template:
<!-- image -->
## 4.2.14.1.6.1.4.6  Regions
As a provider, you can deploy your SaaS solution in a subaccount that is located in one of the regions available for the ABAP environment, see Regions and API Endpoints for the ABAP Environment [page 42].
A consumer can then subscribe to and access your SaaS solution from a subaccount. The consumer subaccount needs to be located in the same region as the subaccount which you deployed the SaaS solution in.
Keep in mind that regions are chosen on the subaccount level: For each subaccount, you select exactly one region. This is done when creating the subaccount. The Landscape Portal can be accessed from subaccounts located in regions that are available for the ABAP environment. You thus need to make sure that the subaccount from which you want to access the Landscape Portal has the correct region attribute (that is, the technical key, such as cf-eu10). For more information on regions, see Regions and Accessing the Landscape Portal.
## 4.2.14.1.6.1.4.7  Troubleshooting
## Multitenant application cannot be undeployed
- Always use MTA Undeployment (cf undeploy &lt;MTA ID&gt; --delete-services) instead of deleting service instances individually.
- Check if the saas-registry service instance still contains active subscriptions: the saas-registry instance can only be deleted once there are no more active subscriptions. Unsubscribe using the Subscription Management Dashboard Note, however that if the subscription is forced to be deleted through any additional channel (using the Subscription Management Dashboard or by subaccount deletion), it will lead to an orphan tenant in the ABAP Solution. Providers need to be aware of this before deleting subscriptions with the 'force' option.
## Cannot create consumer-specific route according to TENANT\_HOST\_PATTERN (in the development phase)
## 
```
Sample Code TENANT_HOST_PATTERN: (.*)-my-consumer-subdomain-productabcdefghijklmnopq-saassolution-dev.cfapps.eu10.hana.ondemand.com Consumer Subaccount Subdomain: my-consumer-subdomain Route Domain: cfapps.eu10.hana.ondemand.com Route Hostname: my-consumer-subdomain-productabcdefghijklmnopq-saas-solutiondev (64 characters)
```
## After deployment of MTA for multitenant application, no abap system is created
- ABAP systems are automatically created by the ABAP Solution Provider (ASP) during the first subscription and not after the solution deployment.
## Issues with parameter consumer\_tenant\_limit
- Keep in mind that recently deleted consumer tenants are counted towards the tenant limit as long as they are still in retention time. Systems are automatically created. Non-consumer tenants (provider tenant, test tenants) do not count towards this limit.
## 4.2.14.1.6.2  Commercialize
To offer your SaaS solution to customers, register the SaaS solution in the SAP Store. See SAP Store .
Additionally, you can request an SAP Extension Suite certification for your product so that it gets listed in the SAP Certified Solutions Directory. See SAP Extension Suite Certification and SAP Certified Solutions Directory .
After finishing this process, your customers can order the SaaS solution, which is the preliminary step to actual subscription.
## Prerequisites
Before registering a SaaS solution in SAP Store or certifying the solution, you have to deploy the first add-on version and multitenant application. See Multitenant Applications [page 1248].
## 4.2.14.1.6.2.1  (Optional) Register SaaS Solution in SAP Store
SAP Store is the enterprise marketplace where we bring together customers and partners on a single, easy-touse, global online platform. See SAP Store .
To learn more about how you can offer your SaaS solution to SAP customers via SAP Store, see Getting Started with SAP Store .
## 4.2.14.1.6.2.2  (Optional) Certification
With an SAP Extension Suite certification, your SaaS solution is featured in the SAP Certified Solution Directory, which allows for more growth and customer participation. See SAP ICC Integration Scenario - SAP Extension Suite Certification and SAP Certified Solution Directory .
##  Note
Certification of SaaS solutions is only available if you have used add-on build delivery.
## 4.2.14.1.6.3  Subscribe
Once the SaaS solution has been fully deployed and commercialized, customers can order the offered product. After the buying process has been completed, you, as a SaaS solution operator, are responsible for onboarding the customer.
## 4.2.14.1.6.3.1  Create Consumer Subaccount
Since your solution is only available within your global accounts for production, you as the solution operator must create a consumer subaccount for your customer. After a customer has ordered the SaaS solution, create a 06 Consume subaccount in the global account for production, which will be used to create the subscription. See Set Up a Global Account for Production [page 1224].
While creating the subaccount, you must provide the following details:
- Name: Give the subaccount a unique display name. This can be the name of the customer, a customer number or a specific naming pattern.
- Provider: Choose the IaaS provider according to the IaaS provider selected for the provider subaccount.
- Region: Choose the subaccount region according to the region where the provider subaccount was created. See Regions and API Endpoints for the ABAP Environment.
- Subdomain: The subdomain plays an important role, as it becomes the consumer-specific part of the tenant-specific application URL.
## 4.2.14.1.6.3.2  Subscribe to SaaS Solution
After you as the solution operator have created the consumer subaccount, the subscription to the SaaS solution is enabled for the consumer.
In the consumer subaccount, navigate to the Service Marketplace. To subscribe to the SaaS solution, select the solution and the desired service plan and choose Create. The subscribed application is now displayed in Services Instances and Subscriptions.
The subscription process triggers the provisioning of:
- a new ABAP system in case all other systems have reached the consumer tenant limit.
- a new consumer tenant that is represented by an additional client in the ABAP system.
In both cases, a confirmation mail will be sent to the initial administrator maintained in the solution configuration. You can also monitor the provisioning using the Systems Overview and Operations Dashboard apps in the Landscape Portal.
The business type of the consumer tenant that is created depends on the usage parameter configured for your solution. If you have set usage = prod , a tenant of business type Partner Customer Production Tenant is created. If you have set usage = test , a tenant of business type Partner Customer Test Tenant is created. For more information, see Tenant Business Types [page 1282].
##  Note
gCTS Delivery: In case of delivery via gCTS, you, as a SaaS solution operator, can use a separate test subscription that is not related to a customer to trigger the creation of the system before the actual customer subscription. This initial system creation and import of the software components needs to be performed for each customer production system.
## 4.2.14.1.6.3.3  Configure Consumer Subaccount
Depending on the scope of the SaaS solution and customer requirements, you can make the following configurations in the consumer subaccount:
- Trust Configuration: You can configure a custom identity provider for the authentication of subscribed applications in the consumer subaccount. See Trust and Federation with Identity Providers. To restrict access based on certain criteria, such as the IP address, use the SAP Cloud Identity Services - Identity Authentication.
##  Note
With new subaccounts created after September 24th 2020, automatic creation of shadow users is switched off by default for the default identity provider, SAP ID service. If the creation of shadow users is disabled, any additional business users need to be added manually to the users of the consumer subaccount so that authentication on subaccount level is possible. Business users can only log on to the ABAP tenant if there is an existing employee/business user in the ABAP system.
- Cloud Connector: Using Cloud Connector, you can create a link between SAP BTP applications and on-premise systems. See Managing Subaccounts on how to add and connect a consumer subaccount to Cloud Connector.
- Destination: Configure destinations, including technical information about the target resource, to connect your application to a remote service or system. See Managing Destinations.
These configurations can be done directly by you, the SaaS solution operator, or by the customer. In the latter case you provide the necessary authorizations by assigning the role collection Subaccount Administrator to a consumer subaccount administrator. The consumer subaccount administrator can then access the consumer subaccount in the SAP BTP cockpit including subscriptions, trust configuration, Cloud Connectors and destinations without having access to other consumer subaccounts in the global account for production.
The consumer subaccount administrator can assign role collection Cloud Connector Administrator to a user to operate the data transmission tunnels used by the Cloud Connector. While adding the consumer subaccount in Cloud Connector, the same Cloud Connector administrator user is being configured.
See Role Collections and Roles in Global Accounts, Directories, and Subaccounts [Feature Set B] for more information on available role collections in the consumer subaccount.
## 4.2.14.1.6.3.4  Initial User Onboarding
In order to be able to start using the solution, your customer needs to receive an initial administrator user in their consumer tenant. This is done automatically via the initial tenant onboarding of your solution.
To trigger this onboarding process, you as the provider need to be assigned to the SolutionAdmin role collection in the consumer subaccount:
1. Log on to the consumer subaccount and navigate to Security Role Collections.
2. Select the role collection SolutionAdmin, choose Edit, scroll down to Users, and select +. Enter the email address of your user, select SAP ID Service as your identity provider or use your preferred custom identity provider, and save your changes.
Now you are ready to access the solution's new tenant, where you will see the initial onboarding screen. In the confirmation dialog, you must confirm details such as email, subdomain, and subaccount ID to onboard an initial user for the customer:
1. Open the URL your provider has sent you to get access to their SaaS application.
2. On the initial administrator onboarding screen, your email address, subdomain, and subaccount ID are displayed. Select Onboard User to start the onboarding process. This might take a few minutes. Once the process is finished, you are redirected to the system. This onboarding process only needs to be performed once.
You can also monitor the tenant user provisioning using the Systems Overview and Operations Dashboard apps in the Landscape Portal. Ongoing tenant user provisionings are displayed in the Requests section of the Systems Overview app. See Systems Overview.
## 4.2.14.1.8  Maintain, Monitor, Support
After the go-live of the SaaS solution and the deployment of its updates, consumers using the solution might run into issues that you have to troubleshoot and debug.
## 4.2.14.1.8.1  Maintain
After the initial add-on release has been shipped as a SaaS solution offering, the development of maintenance patches, support packages, and consequent add-on releases comes into play.
Once everything is implemented, built, and the maintenance delivery is deployed, the corresponding changes become available in the customer production system AMT.
##  Note
New features are developed on different code lines (branches). If you create a so-called maintenance branch to implement patches while new features are implemented in the main branch of a software component, you can implement new features and provide bug fixes at the same time. For more information, see Versioning and Branches.
## Prerequisites
- To set up the maintenance system landscape, you need the relevant entitlements in the global account for development. See Entitlements and Quotas.
- When using a maintenance system landscape, you require business users with authorization to use the Manage Software Components app and developer users using ABAP Development Tools must be available in the systems. See Manage Software Components [page 2914] and Getting Started as a Developer in the ABAP Environment [page 221].
- To configure new add-on versions, you need the existing pipeline configuration for an add-on build pipeline. These can be the pipeline templates in the Build Product Version app or a manual configuration. See Build Product Version and Build and Publish Add-on Products on SAP BTP ABAP Environment .
- If you have configured the add-on build pipeline manually, you need a Jenkins server where you can execute it.
- To use the Landscape Portal, you need a subscription to the Landscape Portal application and a user assigned to role collection LandscapePortalAdminRoleCollection .
## 4.2.14.1.8.1.1  Set Up Maintenance System Landscape
<!-- image -->
Bug fixes aren't implemented as part of the development code line, but in a separate correction code line. In this manner, corrections can be delivered to consumers even while regular development is ongoing.
We recommend setting up a maintenance system landscape that runs in parallel to the development system landscape. This maintenance landscape consists of:
- A correction system COR where corrections are developed. This system is provisioned in subaccount 01 Develop in the development space. Set parameter is\_development\_allowed = true .
- A quality assurance system QAS for testing the corrections. This system is provisioned in subaccount 02 Test in the test space. Set parameter is\_development\_allowed = false .
The required entitlements and system-related details are listed in the table below:
| Global Account                   | Subaccount   | Space   | Entitlements                                                                                   | ABAP System   |
|----------------------------------|--------------|---------|------------------------------------------------------------------------------------------------|---------------|
| Global Account for De- velopment | 01 Develop   | Develop | 1x abap/standard abap/hana_com- pute_unit (standard: 2) abap/abap_com- pute_unit (standard: 1) | COR           |
|                                  | 02 Test      | Test    | 1x abap/standard abap/hana_com- pute_unit (standard: 2) abap/abap_com- pute_unit (standard: 1) | QAS           |
The Manage System Hibernation app in the Landscape Portal allows you to shut down the maintenance systems when no corrections are being developed, significantly reducing the costs incurred. See Manage System Hibernation. For more information on working with two codelines, see Use Case 2: One Development and Correction Codeline in a 5-System Landscape.
It is not strictly necessary to set up a separate maintenance system landscape. You can also implement corrections in the existing development and test systems to further reduce costs. In this case, ongoing development must be stopped while the release branch is checked out and worked on. See Use Case 1: One Codeline in a 3-System Landscape.
## 4.2.14.1.8.1.3  Trigger Add-On Build Pipeline
<!-- image -->
Similar to the build of the initial add-on version, as an add-on administrator, you need to trigger the execution of the configured ABAP environment pipeline for an add-on build. You can do this using the Build Product Version button in the corresponding app. After a successful build, the new add-on version is technically available for deployment to the ABAP environment. See Build Product Version. If you are configuring the add-on build pipeline manually, then you need to trigger its execution in your Jenkins server. For in-depth information about the ABAP environment pipeline, check out ABAP Environment Pipeline.
##  Note
If you are using gCTS instead of add-ons for delivering software components into production systems, an add-on build is not required.
Please ensure that the add-on product version to be published is properly tested before confirming the release decision. This includes testing in SAP Fiori launchpad and the ABAP Test Cockpit. See Test in the ABAP Environment SAP Fiori Launchpad [page 1236] and Test in the ABAP Test Cockpit [page 1238].
During add-on build a new semantic version API snapshot will automatically be created for each add-on software component. In the assembly system BLD semantic version snapshots are automatically created
and set to check-relevant during add-on build. Do not perform manual actions on API snapshots in these systems.
## 4.2.14.1.8.1.4  Check Add-on Build Result
Use the Check Product Version app in Landscape Portal to check whether the product version, its components, and respective packages are ready for deployment. See Check Product Version.
## 4.2.14.1.8.1.5  Deploy Add-On Update
As a SaaS solution operator, you can apply add-on updates to existing systems via theDeploy Product app in the Landscape Portal.
You can select the target add-on product and version for the update. Afterwards, you can select the systems where the update should be applied and schedule the update.
##  Note
If you are using gCTS instead of add-ons for delivering software components into production systems, you need to pull the changes of all relevant software components into all productive systems using the Manage Software Components app. An update deployment via the Landscape Portal is not required.