Transport

An environment is the smallest unit that you can include in a transport.
You cannot select only sections of an environment or deltas. To ensure consistency, a whole environment has to be transported.
Database records of Model Tables are included automatically if they are configured as transportable.
Changes are not recorded automatically.
To transport environments, you have to explicitly mark the environments and include them in a transport in the environment list screen.
During the After Import phase of the transport import for the environment configuration in the target system, the system activates the following functions:
- Model Table, Model View, Model BW, File Adapter and Model RDL
- Functions that are added as activities of a process template
- Functions with the processing type “Executable”
- Functions that are a remote adapter (only the RFA types HANA R Script and HANA Stored Procedure are not activated)
- Functions that are an input of a view using an iterative type (loop).
The environment generation strategy for environments is client-specific. All HANA objects (tables, procedures, and so on) are generated dependent on the client to which this environment is imported.

The advantage of this generation method is that you can work with multiple clients in the same system.

The disadvantage is that generated objects do not have fixed names (the names are based on function identifier and client).

Note

You need to take this into account when you use these generated objects for custom development. Furthermore, some customer implementation configurations that refer to generated objects (for example, generated content views consumed by SAP Lumira reports) need to be adjusted after a transport or client copy. Generated objects are for usage by SAP Profitability and Performance Management internally and it is not recommended to use these generated objects directly.
As of now, a modeling user can make changes even if the client has been set to “No changes possible”. Changes in the modeling environment must be controlled by means of authorizations.
Numbers generated from the corresponding number range objects are used as identifiers for the creation of various entities/functions. Each system client in the landscape should, therefore, have its own distinct number range interval defined during system client setup.
Transporting environments across systems/clients where number range interval definitions for /NXI/* number range objects are identical could lead to serious inconsistencies. When you are setting up the landscape, you therefore need to make sure that the number range intervals do not overlap and are distinct.
Ensure that the source system client and the target system client have their own distinct number range intervals before you transport any environments between these systems to avoid any serious inconsistencies.
After an environment is transported, the settings of that environment in the target system are always overwritten by the settings from the source system.