Import Options
| Property | Description |
| Import Method | There are four standard TE Import Methods for importing transports i) Import one request at a time: this imports in the order that is displayed on screen. ii) Fast Import (Import All): this imports using standard SAP Block import, again based on the order that is displayed on screen iii) One request at a time – TE default sequence: will import in the TE calculated sequence (ie the numerical order detailed in the Order column), regardless of the sequence of transports displayed on the screen. iv) Fast Import (Import All) – TE default sequence: will import using standard SAP Block Import in the TE calculated sequence (ie the numerical order detailed in the Order column), regardless of the sequence of transports displayed on the screen. Basis Technologies would generally recommend (iii) and (iv) import methods, with the latter particularly useful for project cutovers involving large numbers of transports. (i) and ii) work fine as long you have your Import History view on “By Transport”, and are sorting on the Order column. If you are doing a View by Project and Task, then you could run the risk of importing in an incorrect sequence. For Merge Targets where you are doing 1:1 Merge, it is better to set the Import Method to one request at a time. |
| Try to import transport requests in the order that they were imported into the predecessor target. | When determining the ideal import order of a selection of transport requests, Transport Expresso 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 Expresso 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. |
| Optionally specify additional import schedules | If you assign a Import Schedule to a Target, you can use this option to add further Schedules to the Target |
| Suppress import analysis during scheduled imports | If you enable this option, Transport Expresso 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. |
| Import Jobs Scheduled by Transport Expresso | This option should be checked where TE Schedules have been created to automatically import transports |
| Orchestrated | This option should be selected where you want Transport Expresso to automatically continue an import after i) a dependant transport in another system has been imported or ii) a dependant manual step has been performed in the target |
| Continue importing transport requests when an import error occurs | By default Transport Expresso 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 Expresso will continue importing the selection of transport requests when an import error occurs. Note that even when this option is enabled, Transport Expresso will stop the import process if a system error occurs (such as not being able to connect to the target SAP system). For Merge Targets where you are doing 1:1 Merge, it is better to leave this option unchecked |
| Automatically create backup transport requests | When this option is enabled Transport Expresso 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. Please note that TE Backout is not relevant for BW or Java systems. It is currently only to be used in ECC/ERP type systems. |
| 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 Expresso that the target is a CTS+ system. |
Merge / Parallel Development Streams
| Property | Description |
| Perform conflict analysis against this target | When this option is enabled Transport Expresso 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 to be used during conflict analysis | 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 Expresso 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 Expresso 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 Expresso 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 |
| Inherit merge transport owner from original transport (CTS+ only) | Check for Java systems to ensure Merge transport owner is same person as the original transport (for 1:1 Merge scenario) |
Post your comment on this topic.