Carl explains, that in a three-system landscape, the following steps can be performed in the respective SAP systems:
As a business process configuration expert, you scope the business scenarios in the workspace of SAP Central Business Configuration, deploy the workspace to the customizing tenant of the Development system, and fine-tune the configuration content via implementation activities. For instance, you may scope the Enterprise Management with the United States Generally Accepted Accounting Principles (US-GAAP) scenario and maintain fiscal year variants. When deploying the business configuration to the customizing tenant, the system records the changes on a customizing transport request for deployment in SAP Central Business Configuration, whereas fine-tuning changes are recorded on customizing transport requests for fine-tuning changes. Once you have finished content authoring, you can release the customizing transport requests using the Export Customizing Transports SAP Fiori app.
As a key user, you customize applications in the customizing tenant using SAP Fiori-based key user apps. For instance, you may add a custom field to the SAP-provided sales order business object using the Custom Fields SAP Fiori app. Once this is done, you can add the extensions to a software collection and export the software collection using the Export Software Collection app.
As a developer, you implement custom ABAP code in the development tenant using ABAP Development Tools (ADT). For instance, you may create a custom business object using the ABAP RESTful application programming model. All the changes are recorded on workbench transport requests. Once you have finished the implementation, you can release the workbench transport request by using the Transport Organizer view in ABAP Development Tools.
As an administrator, you import the customizing transport requests, the software collection, and the workbench transport request into the test tenant using the Import Collection SAP Fiori app.
As a tester, you run the customized business processes in the test tenant. For instance, you may create a custom business object instance that was implemented by a developer or maintain data for the custom field that was added to the sales order business object by a key user.
After successful testing, as an administrator, you forward the customizing transport requests, the software collection, and the workbench transport request to the production tenant from the test tenant using the Import Collection app. Afterwards, you import them into the production tenant using the Import Collection app.
As a rule, you can't perform any extensibility or business configuration change directly in the test and production tenant. However, there are certain cases in which you, as a business configuration expert, have to configure settings in the test and production tenant – the so-called system-specific settings – for example, for maintaining number ranges.
Note
Adam: we will talk about types of transport requests in a later lesson.Carl says to Adam and Devin: SAP has set up the Change and Transport System (CTS) in your SAP system landscape, so that you can transport your changes between the Development, Test, and Production system.
With the Export Customizing Transports app, business process configuration experts can manage business configuration changes recorded in requests. You can use this app to:
Display a list of customizing transport requests.
Create new customizing transport requests.
Display the customizing tasks and objects of a customizing transport request.
Display the objects recorded in a customizing task.
Display the table keys recorded for an object.
Check customizing transport requests.
Release customizing transport requests.
Assign a transport request to your user.
Create tasks for other users.
Change the transport category.
Take over tasks and transport requests from other users and assign them to your user.
Check consistency of all open transport requests
Business configuration changes are recorded in transport requests, depending on the category to which the customizing objects belong. Unlike ABAP repository objects, customizing objects recorded in a transport requests are accessible to other business users.
Carl explains the Default Customizing Request:
Since configuration changes recorded in transport requests of the type Customizing Transport Request are not lockable, it might happen that several business users record their configuration changes in different requests.
This also happens for requests of the type Cross-Client Customizing.
Recording the configuration changes in different transport requests might create dependencies between these transport requests, however to avoid such dependencies, a new transport category is introduced.
Any new request created from this app is categorized as Default: In a client, there can be only one open default transport request of the type Customizing Request.
There can also only be one open default transport request of the type Cross-Client Customizing Transport Request.
Business users can record their configuration changes to this default transport request to avoid any dependencies.
If you need to perform an emergency fix, record the configuration changes in a transport request which is not categorized as Default.
Carl explains to Adam and Devin: CTS is the central tool for managing changes that you make in the development and customizing tenant. Whenever you create a developer extension in the development tenant or change the business configuration in the customizing tenant, CTS records all the changes in transport requests. Developer extensions are recorded on workbench transport requests, whereas changes of the business configuration are recorded on customizing transport requests.
The changes in transport requests can be linked together logically or be independent of each other. Developers in one team can use a common transport requests. You can create documentation for a transport requests, where you can describe your changes in more detail. This makes it easier to check which data was changed by which user, and for what purpose.
When you have finished your work, or have reached a certain stage, you can release the transport request. The transport request is then used to transfer the changes to the test and production tenant, where the changes can be imported via the Import Collection app. This procedure is known as a transport. Transports of changes by the CTS allow you to develop in one environment, test your development work in a test environment, and finally, if the tests are successful, use it productively. This ensures that productive operations are not placed at risk by incorrect settings or program errors.
Carl mentions that there is an approach to test automation. Without explaining any details, Carl just shows a blog for further information: https://blogs.sap.com/2021/09/07/sap-s-4hana-cloud-test-automation/
Carl end with explaining that you need the following tools and apps for transports:
Transport Organizer in Eclipse-based ADT for managing workbench transports for developer extensibility development. With this tool, you can create, manage, and release workbench transports. See Transport Organizer.
SAP Fiori app Export Software Collection: With this app, you can create collections of extensibility objects (items) and export them. See Export Software Collection.
SAP Fiori app Export Customizing Transports: With this app, you can manage and export a customizing transport. It displays customizing transports, their project assignment, and piece list (client dependent objects only). See Export Customizing Transports.
SAP Fiori app Import Collection: With this app, you can import software collection versions. It allows you to import workbench transport requests, customizing transport request, and software collections into the test or productive system. See Import Collection.