Page tree
Skip to end of metadata
Go to start of metadata

Summary: an explanation of Execution Groups and how they work. Available in v. ≥ 1.17.

Introduction

Execution Groups are an advanced level feature of the AIP Console that represent how auto-generated Analysis Units (i.e source code and configuration details) are analyzed. Depending on a variety of factors, multiple Analysis Units may be grouped together into one Execution Group, or one Execution Group may be created for each Analysis Unit.

Their objectives are as follows:

  • to improve analysis performance - i.e. by grouping multiple Analysis Units together in one "analysis execution," analysis time can be improved.
  • to allow a group of Analysis Units in one Execution Group to be analyzed in one go, manually.
  • to reduce the risk of an analysis crashing - an Execution Group has an upper limit on the amount of source code that can be analyzed in one "analysis execution" (this differs per Technology) and this limit is designed to prevent an analysis crashing due to an out of memory error
  • to ensure links between Analysis Units are not missed, particularly links determined by the inference engine.

How do they work?

The contents of an Execution Group (i.e. which Analysis Units are grouped together) is determined automatically by AIP Console using internal algorithms specific to each technology type and information (source code size, dependencies between projects) identified during the source code delivery process. For the most part, you should let AIP Console manage Execution Groups - however, it is possible to configure them yourself if you find that the automatic management strategy provided by AIP Console is not providing an optimum result.

Auto-management of Execution Groups

CAST will automatically manage and define Execution Groups on an Application basis for each supported Technology as listed in the table below:

Oracle PL/SQL and Microsoft T-SQL (from a database extraction)A source code package corresponds to one RDBMS extraction (that could contain multiple schemas and therefore multiple Analysis Units), as such all Analysis Units belonging to the same source code package are analyzed together in one Execution Group, with no upper source code limit.
ASPOne Execution Group is created per Analysis Unit.
C/C++One Execution Group is created per Analysis Unit.
Oracle Forms/ReportsOne Execution Group is created per Analysis Unit.
MainframeOne Execution Group is created per Analysis Unit.
JEEOne Execution Group is created for ALL Analysis Units.
.NETOne Execution Group is created for ALL Analysis Units.
SAPOne Execution Group is created per Analysis Unit.
UniversalOne Execution Group is created per Analysis Unit.
Note that as soon you create custom Execution Groups, the auto-management strategy will be deactivated.

Manually customizing Execution Groups

Manually customizing Execution Groups entails overriding the default rules that AIP Console uses to group Analysis Units into Execution Groups. This is a highly technical feature and should only be used when you know exactly what you want to achieve. Currently, customizing Execution Groups is only possible for the following technologies:

  • C/C++
  • JEE
  • .NET

To customize Execution Groups, you need to have at least two Analysis Units present in the version for the given technology. The example below shows one Analysis Unit in a default Execution Group (Default execution group) and two Analysis Units that have been moved into a custom Execution Group (TEST)

Click to enlarge

Manually run an analysis for the entire Execution Group - i.e. analyze all Analysis Units in the Execution Group.

Modify the Execution Group for the current Analysis Unit. This option will show the following popup:

Entering a new name for an Execution Group will do the following:

  • If the name entered into the box does not exist yet, a new Execution Group will be created using the chosen name and the current Analysis Unit will be moved to this new Execution Group.
  • If the name entered into the box matches an Execution Group that already exists, the current Analysis Unit will be moved to this existing Execution Group.
  • If there is only one Analysis Unit in the Execution Group, the existing Execution Group will be renamed to the name entered into the box.

Enable/disable the analysis of the current Analysis Unit (this is valid when running an analysis for the Execution Unit or whether running an analysis at Application level).

Only visible on custom created Execution Groups:

  • Rename the current Execution Group.
  • Ungroup the Execution Group - in other words, delete the Execution Group and move all Analysis Units back into the default Execution Group.

Things to note

Ungroup

Analysis Units that are grouped manually in a given Execution Group should always, from that point onwards, be analyzed together in the same Execution Group to retain the integrity of analysis results. If, however, the total source code size of the Analysis Units in the Execution Group exceeds the Execution Group max size threshold in Version N+1, AND the analyzer starts to crash (because the threshold has been exceeded) then there is no alternative but to "ungroup" an Analysis Unit from the Execution Group so as the Execution Group max size threshold is not exceeded. You should be aware that this could change the results of your analyses and should be avoided if possible.

Impacts of source code size increase between versions

Take the following example:

  • In V1 only one Execution Group (A) was created for all Analysis Units in the Application
  • In V2, the source code size has increased and exceeds the Execution Group max size and CAST now decides to create additional Execution Groups  (A and B) to accommodate the new source code size

If an Analysis Unit was part of Execution Group A in V1 and is now part of Execution Group B in V2, then objects in the Analysis Unit will appear as removed and newly added in the CAST Engineering Dashboard.

Impacts of source code size decrease between versions

Take the following example:

  • In V1 two Execution Groups (A and B) were created for the Analysis Units in the Application because the source code size of all Analysis Units exceeded the Execution Group max size
  • In V2, the source code size has decreased and is now within the Execution Group max size - CAST now decides to create only one Execution Unit (A)

If an Analysis Unit was part of Execution Group B in V1 and is now part of Execution Group A in V2, then objects in the Analysis Unit will appear as removed and newly added in the CAST Engineering Dashboard.

  • No labels