Deep Impact Analysis (0060) can be used to highlight the lower level dependencies between the repository objects contained within the transport(s) being analysed and other transports existing in the landscape. This can be used to avoid deployment errors where transports are imported without the necessary dependent objects being present in the target SAP system.
The process checks the objects included in the analysed transports and determines whether any of the objects referenced within those are either part of the group of changes being approved/imported or have already been imported beforehand.
For example, if a database table is being transported, a check would be made to ensure that all referenced data elements are not missing. The same would apply to a program being transported to ensure that any referenced data dictionary objects, function modules, classes, methods, etc. are not missing. This can then reduce the number of import failures due to hidden dependencies between changes and transports.
|CHECK_MISSING_OBJECT_IN_SOURCE||This parameter if set to ‘X’ then the analyser will also check if the reported missing dependency exists in the source system. If it does not also exist in the source system then it will not report the object as a missing dependency. This has been introduced as some custom includes statements are referenced within a table structure or within source code but the which have not yet been created in the source system and without this parameter set these will be reported as missing dependencies in the target system.|
|DEEP_IMPACT_RELEVANT_OBJECTS||With this parameter set to ‘X’ it is possible to only check dependencies on objects within a defined range. This range of object names needs to be defined in the table /BTI/TE_TVARV – please refer to online FAQ documentation for screenshot. These are possible entries but other can also be entered|
|EXISTS_IN_REF_TARGET||Can be set to the Reference Target system number in which the Dependency needs to be checked again. More information on this optional parameter and its usage can be found in this online Change Note.|
|GROUP_IMPORT_METHODS||(only relevant in import queues). The analyser already knows how to behave with standard AC import methods, assumes any unknown one to be sequential. Only set this if you use a non-standard fast import method.|
|INCLUDE_DUPLICATES||By default, when the Analyser find an object to be a missing dependency at the 1st level, it doesn’t check it at the 2nd level to save time. When this is set, Analyser keep looking at every level. Gives better results but slows down the analyser, particularly when levels is high.|
|LEVELS||Determines how many levels the Analyser should travel the dependency tree. High value are slow and give many false positives. Recommend to stay between 1 and 3.|
|MAX_LINKAGE_AGE||Number of hours after which transports for unreleased transports are considered stale. We recommend leaving this to 1 hour.|
|MAX_LINK_TIME||Maximum total time in seconds to wait for the links to be created on the fly. Recommendation is 60 seconds.|
|MAX_OBJ_TIME||Maximum time in seconds to be spent analysing an object. Recommendation is 2-3 seconds.|
|RELEASE_TASKS||Release tasks of unreleased transports during link creation.|