Target Properties – Import Options - ActiveControl - Administration Guide - 5.30

Property	Description
Import Order	When determining the ideal import order of a selection of transport requests, Transport Express normally considers any dependencies specified on a transport request’s transport form before sorting the transport requests chronologically according to release date and time. This option tells Transport Express to consider the order that transport requests were imported into a particular “predecessor” target before applying the standard import order rules.
Force transport dependencies when importing in the same order as predecessor system	If dependencies that are manually set on a transport form are to override the predecessor target import order then set this flag
Scheduled Imports	Assign a transport schedule to a target to automatically import any transport requests in its import queue. Transport requests are imported in their ideal import order (as explained above). A transport schedule defines the times when an automatically scheduled background job will run to import waiting transport requests into the target. Please refer to section Defining Transport Schedules to learn how to create a transport schedule.
Suppress import analysis during scheduled imports	If you enable this option, Transport Express will not perform its standard import analysis checks when the scheduled import background job runs. You should only enable this option if the checks have already been performed – for example, when the transport requests were approved into the target system.
Continue importing transport requests when an import error occurs	By default Transport Express continues importing a selection of transport requests when it detects that an import error has occurred (such as a syntax error). If this option is enabled Transport Express will stop importing the selection of transport requests when an import error occurs. Note that even when this option is enabled, Transport Express will stop the import process if a system error occurs (such as not being able to connect to the target SAP system).
Automatically create backup transport requests	When this option is enabled Transport Express will create a backup transport request for the selection of transport requests that are about to be imported into a target SAP system. A backup transport request contains a copy of all things that are about to be updated as they were immediately before the import occurs. If an unexpected error occurs as the result of importing a selection of transport requests, the state of the target system can theoretically be restored by simply importing the backup transport request. However, this is not an automatic guarantee as there are exceptional situations, such as the deletion of content from an application table, from which only a database restore can recover. Use of this option when importing a large selection of transport requests is not recommended, as it can significantly slow the import process. In these situations, it is recommended to rely upon database recovery techniques. Refer to the following section Backing Out Changes for further information on this topic.
Timeout for delayed imports (minutes)	The way TE works is that it calls the TP command to import the transport and waits for a response. In some cases (due to a very long running import) the TP command will time out and therefore TE has no other option but to report a system error as it doesn’t know what the actual status is. By setting a timeout for delayed imports TE will retry every minute for this many minutes and check if the import is now complete. Only after this time has elapsed will it then report a system error if the import is still not complete after that time.
Ignore System Id during import (CTS+ only)	For CTS+ systems the SAP system ID is different to the system that is the CTS+ domain controller. In this case the flag should be set to inform Transport Express that the target is a CTS+ system.
Before importing, check whether the same content has been changed in this SAP client	When this option is enabled Transport Express will perform an additional remote analysis check for transport requests that are to be imported into this target system. The remote import analysis checks whether the content that is about to be imported has already been changed in the target system. This option is particularly useful for branched SAP development systems, when changes from one development system must be applied to other development systems.
Client (in which to check for changes and in which merge transport requests will be created)	For performance reasons, the remote import analysis checks are only performed in one client of the target SAP system. Similarly, merge requests are only created in this client. You should specify the client of this target SAP system in which client-dependent configuration changes are made.
Require that transports with changes to SAP objects be manually merged	When this option is enabled, Transport Express will check if a transport to be merged contains changes to SAP standard development objects and if so, require that the transport be manually merged. This option is useful if you have branched development systems that are running different versions or patch levels.
Create a merge transport request in this SAP system after importing changes	When this option is enabled, Transport Express creates merge transport requests in this system for each selection of transport requests imported. This option is particularly useful for branched SAP development systems. Creating merge transport requests provides an easy way to apply the same changes to downstream systems of the branched development stream (e.g. the project QA system).
Fix renamed objects in merge requests	During import into BW systems some BW objects are automatically renamed. The default behaviour of the merge process is to copy the objects from the original transport into the merge transport but this doesn’t work for the affected BW objects. In this case Transport Express can run a rename process either ‘After Import’, ‘Before Release’ or ‘After Import & Before Release’ to perform the renaming process. This will edit the merge transport and renaming the objects to the new names in the merged system. ‘After Import’ is the default renaming method.
Add dependant routines and formulae for BW merges	Some BW objects should always be transported in their entirety. If, for example, a transformation was being transported this option would also add in all the dependent routines and formulas into the merge transport.
Default package for merges objects	When BW objects are renamed sometimes they are not assigned with an object directory entry (TADIR). The package specified in here can be used to create this to prevent warnings during merge transport release

Target Properties – General

Target Properties – Import Options II

Feedback

Post your comment on this topic.