Deep Impact Analysis (New) (0060)

Please note that Deep Impact Analysis (New) (0060) replaces the original Deep Impact Analysis (0023) analyser (from ActiveControl 7.0 onwards)

Deep Impact Analysis 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.

Deep Impact Analysis is used to perform technical / repository checks so therefore doesn’t include configuration objects in its analysis.

Note that there is some pre-requisite Diffuser configuration setup that needs to be performed for Deep Impact Analysis to run correctly. The exact steps are detailed in online forum. Similary there are several ways of setting up Deep Impact Analysis, in terms of when it runs in the process. The typical configuration is detailed in online forum.

Parameters:

• 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.