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.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.
- 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.
Using a reserved namespace for add-on development and build is necessary for a unique add-on product and software component name.
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.
As a SaaS solution operator, you have to configure the global account for development (used for development, testing, and demo purposes).
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 01 Develop subaccount, add-on development is performed in a permanent development system. See Development in the ABAP Environment.
In the 02 Test subaccount, the developed software components are tested after a successful import into a permanent test system.
In the 03 Build/Assemble subaccount, the add-on package assembly is performed in a transient assembly system that is created and deleted automatically by the build pipeline.
In the 04 Build/Test subaccount, the add-on product is installed and tested again.
In the 05 Provide subaccount, the add-on product is provided as a SaaS solution for testing purposes in the development phase.
You can use a booster (see Booster for Landscape Portal) to automatically perform the setup of subaccounts 00 Landscape Portal, 03 Build/Assemble and 04 Build/Test. This includes the assignment of entitlements, creation of subscriptions and trust setup as described below.
If you use gCTS instead of add-ons for delivering software components to production systems, the setup and usage of the following subaccounts is redundant:
- 03 Build/Assemble (used for the add-on assembly)
- 04 Build/Test (used for add-on installation test)
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 (only one global account is used).
In the provider subaccount, the entitlement for an ABAP instance of service plan type
abap/standardinstead ofabap/saas_oemneeds to be available.
You should configure a Cloud Foundry space in each subaccount. Dividing the development, testing, and assembling activities into different subaccounts allows for maximum flexibility. For instance, you may want to use different identity providers or consume different connectivity services during testing and development.
The ABAP systems that you use for development, testing, and add-on assembly are of type abap/standard and made available via entitlements. ABAP systems for add-on installation are of type abap/saas_oem. These service entitlements must be assigned by an administrator to different subaccounts, according to the following structure:
|
Global Account |
Subaccount |
Space |
Services |
|---|---|---|---|
|
Global Account for Development |
01 Develop |
Develop |
1x abap/standard abap/hana_compute_unit (standard: 2) abap/abap_compute_unit (standard: 1) |
|
02 Test |
Test |
1x abap/standard abap/hana_compute_unit (standard: 2) abap/abap_compute_unit (standard: 1) |
|
|
03 Build/Assemble |
Build/Assemble |
1x abap/standard abap/hana_compute_unit (standard: 2) abap/abap_compute_unit (standard: 1) |
|
|
04 Build/Test |
Build/Test |
1x abap/saas_oem abap/hana_compute_unit (standard: 2) abap/abap_compute_unit (standard: 1) |
|
|
05 Provide |
Provide |
1x abap/saas_oem abap/hana_compute_unit (standard: 2) abap/abap_compute_unit (standard: 1) Application Runtime abap-solution saas-registry xsuaa |
Additionally, the following entitlements for SaaS application subscriptions are required:
- SAP Business Application Studio for UI development. See SAP Business Application Studio.
- Web access for ABAP for access to systems during 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 development for authentication/authorization, see Trust and Federation with Identity Providers. To restrict access based on certain criteria such as the IP address, you need to use the SAP Cloud Identity Services - Identity Authentication.
For in-depth information about the system landscape/account model, check out System Landscape/Account Model.
As a SaaS solution operator, you have to configure the global account for production.
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.
In the provider subaccount, the entitlement for an ABAP instance of service plan type
abap/standardneeds 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.
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.
Note that these service entitlements must be assigned to different subaccounts, according to the following structure:
|
Global Account |
Subaccount |
Space |
Services |
|---|---|---|---|
|
Global Account for Production |
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. To restrict access based on certain criteria such as the IP address, you need to use the SAP Cloud Identity Services - Identity Authentication.
For in-depth information about the system landscape/account model, check out System Landscape/Account Model.
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 Development |
01 Develop |
Develop |
Create an ABAP instance (abap/standard) DEV Set parameter |
|
02 Test |
Test |
Create an ABAP instance (abap/standard) TST Set parameter |
You don't have to create an ABAP instance in the03 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)). 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 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.
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.
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.
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).
For in-depth information about versioning and branches, check out Versioning and Branches.
Configure ABAP Test Cockpit Checks, Check Variants
By default, a check variant ABAP_CLOUD_DEVELOPMENT_DEFAULT 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 the default check. 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.
Configure ABAP Test Cockpit to Interrupt Transport Releases
We recommend enabling the blocking of transport releases in case of priority 1 (error) 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.
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.
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 and ABAP Lifecycle Management.
Automatic Import into Test System with ABAP Environment Pipeline
For in-depth information about the ABAP environment pipeline used for automatic import into a test system, see ABAP Environment Pipeline.
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.
One of the main use cases of the Landscape Portal is the building of product (add-on) versions. While the Landscape Portal hides much of the complexity involved in the process, it is required that a partner set up a suitable account model before starting.
The “Landscape Portal for SAP BTP ABAP Environment” booster is an automated process that automates the setup required to use the Build Product Version app in the Landscape Portal. Upon execution, it creates three new subaccounts corresponding to 00 Landscape Portal, 03 Build/Assemble and 04 Build/Test as described in Set Up a Global Account for Development.
The three subaccounts fulfil the following roles:
-
00 Landscape Portal: This subaccount will host your Landscape Portal subscription, which can be used for a wide range of lifecycle management tasks.
-
03 Build/Assemble: This subaccount will host ABAP environment instances that are used to build new add-on product versions.
-
04 Build/Test: This subaccount will host ABAP environment instances that are used to test the installation of new add-on product versions.
It is recommended to use a transient build system during the add-on build process. This means that with every build that is triggered, a new ABAP environment instance is provisioned and, after the process is finished, it is deleted again. The booster also offers the possibility to provision such an instance during the booster execution, which can be later used during the build process.
You can start the booster from your global account for development. A wizard queries the user for the necessary data for the configuration of the subaccounts.
-
Your global account for development should be assigned the necessary entitlements:
- Landscape Portal (1x standard)
- Continuous Integration & Delivery (1x standard)
- abap (2x standard, 2x abap_compute_unit, 4x hana_compute_unit)
- Web Access for ABAP (1x default)
-
Navigate to your global account for development in the BTP Cockpit.
-
Navigate to the Boosters tab.
-
Select the “Landscape Portal for SAP BTP ABAP Environment” booster and click Start.
-
Configure the 00 Landscape Portalsubaccount.
- Choose a subaccount name and subdomain.
-
Configure the 03 Build/Assemble subaccount.
- Choose a subaccount name and subdomain.
- Choose a Cloud Foundry organization and space name.
- Specify a technical user from your identity provider that shall be used for the provisioning of build systems.
- Specify whether to provision a build system.
- If a system shall be provisioned, choose a system ID.
-
Configure the04 Build/Test subaccount.
- Choose a subaccount name and subdomain.
- Choose a Cloud Foundry organization and space name.
- Specify a technical user from your identity provider that shall be used for the provisioning of installation test systems.
-
Configure the user groups.
- Specify a list of administrator users. These users will be assigned authorizations as described in Results down below.
- Specify a list of viewer users. These users will be assigned authorizations as described in Results down below.
SAP ID Service is configured as the identity provider in all three subaccounts. If you wish to use different trust settings for different subaccounts, you can adjust the configuration as necessary after the booster execution.
Currently,the Landscape Portal can only be used with SAP ID service as the application identity provider.
After successful execution, your global account for development should contain three new subaccounts with the following properties:
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 Administratorand 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, areCF 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 collectionSubaccount 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, seeConfigure 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 the04 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.