|Summary: CAST AIP 8.3.21 introduces a number of features and changes as listed below.|
During an upgrade to CAST AIP ≥ 8.3.21, a consistency check has been implemented to ensure that the index.xml file located in the folder Delivery\plugins and the plugins (i.e. sub-folders) present in the Delivery\plugins folder are consistent. This check has been added to avoid situations where, for example, the version of a plugin (e.g. discoverer or an extractor) located in the Delivery\plugins folder and the reference to that plugin version in the index.xml file, differ.
If any inconsistencies are detected during the upgrade, these will be logged in a new log file called ServMan-Utils produced by CAST Server Manager, located here (if the default settings are used):
Click to enlarge
Where possible, inconsistencies are repaired. When this is not possible, the upgrade stops with and an error is logged in the main CAST Server Manager log file, located in the same folder as above, for example:
Syntax coverage has been improved when using data from JCL. The following is now supported:
The following syntax is now supported:
A change has been to the SAP/ABAP Analyzer in order to improve analysis performance (execution time) particularly for very large analyses. For those upgrading to 8.3.21 and for new "out of the box" installations, in the following file:
the following line:
<analyzer name = "ABAP Analyzer" showProgress = "false" maxMem = "1000" maxInstancesForFlat64bits = "200000"/>
has been replaced with:
<analyzer name = "ABAP Analyzer" showProgress = "false" maxInstancesForFlat64bits = "400000"/>
|If you are analyzing large SAP/ABAP projects and regularly find that analysis execution time is very long or gets stuck, CAST recommends gradually increasing the value of maxInstancesForFlat64bits to a point where performance is acceptable.|
A change has been made in the CAST Delivery Manager Tool to the exclusion rule Exclude Eclipse project located inside the output folder of another Eclipse project. In previous releases this exclusion rule in fact addressed two different things:
To provide more flexibility, this rule has now been split in to two separate rules to address both exclusion scenarios handled by the original rule, as follows:
|Rule name||Notes||Position of option "out of the box" in 8.3.21||Position of option after upgrade to ≥ 8.3.21 position|
|Exclude Eclipse project located inside the output folder of another Eclipse project||Same name as in previous releases but this rule no longer excludes projects that share the name of another Eclipse project.||Enabled||Same position as prior to the upgrade.|
|Exclude Eclipse project sharing the name of another Eclipse project|
New rule to address this specific scenario.
|Enabled||Same position as original rule prior to the upgrade to ensure consistency of results.|
Transactions are more and more frequently used for purposes other than AFP/AEP counting. However, the concept of "Transaction" was until now strongly Function Points-oriented, meaning Transactions which did not access any Data Entity or End Point did not always have their objects saved. This new feature aims to change the way such Transactions are collected and managed.
All Transactions are still identified by their Entry Points, but objects that are part of Transactions which do not access any Data Entity or End Point can now be saved, whichever enhancement measure is selected for their application: EFP (Enhancement Function Points) or AEP (Automated Enhancement Points) - see TCC - Enhancement node - Right hand panel.
In terms of AFP, saying that a Transaction is not valid can still be done by using the existing Delete or Ignore action. If a Transaction does not make sense, then the corresponding Entry Point must be removed.
Transactions considered as valid for AFP counting but neither accessing any Data Entity nor End Point will still have both their FTR and DET properties set to 0.
Having this type of empty Transactions in AFP/AEP counting is controlled by the new Function Point computation setting called Save objects of empty Transactions. The value of this setting will by default be set to "ALWAYS" for a new application, whichever enhancement measure is enabled (EFP or AEP), meaning that objects of its empty Transactions will always be saved.
To prevent variations in computation duration and volume of saved data for an application whose AIP version has just been upgraded to ≥ 8.3.21, the value of this setting will be set to "ONLY AEP" by the upgrade process. This setting value means that objects of empty Transactions will always be saved if the application enhancement measure is AEP, and never be saved if it is EFP, which is the behavior up to and including 8.3.20.
Before computing a new Snapshot or launching a Function Points computation, the Save objects of empty Transactions setting value can be changed in the following dialog boxes of the CAST Transaction Configuration Center:
To prevent variations in computation duration and volume of saved data for an application whose AIP version has just been upgraded to ≥ 8.3.21 - the version where objects of empty Transactions can be saved - the upgrade process will set the value of the Save objects of empty Transactions setting to "ONLY AEP". However, since for new applications the default value of this setting is "ALWAYS", then the value of this setting in the Global Computation Settings dialog will be set to "ALWAYS" too. Consequently, where the upgraded application uses Global Computation Settings (instead of Application Computation Settings) it is necessary to override these global settings, which is indicated by a "*" in front of the setting along with a change in the label of the "[x] Use Global Computation Settings" check-box:
If objects of empty Transaction are saved and there are any, their call graph and their full call graph can be viewed in the same way as for those of non-empty Transactional Functions. Below is an example of what such a call graph looks like:
The Function Points computation report (generated during the Compute action) has been refined to provide information regarding:
Below is an example of the Function Points computation report in previous releases, taking the example of FPs computed for 3 applications in a single shot (2 applications are using AEP, 1 application is using EFP):
Number of applications with full call graph : 2 (#33949, #34110) Number of applications with reduced call graph : 1 (#34065) Number of relevant objects in repository : 5323 Number of OMG AFP-links in repository : 11043 Number of DF records / TR end points : 248 Number of transactions : 150 Number of empty / estimated transactions : 13 Number of links -> DF records / TR end points : 1864 Number of links -> other objects in full graph : 6039 Number of transaction links generated (sum) : 7903 Number of objects in largest transaction : 180 Number of elements in largest SCC group : 12 Saving graph results... Saved full call graphs of transactions in application #33949 (6563 details). Saved call graphs of transactions in application #34065 (164 details). Saved full call graphs of transactions in application #34110 (1176 details). Computation finished.
Below is an example of the Function Points computation report in ≥ 8.3.21, taking the same applications as above:
Number of applications with full call graph : 2 ( #33949 (empty TRs saved), #34110 (empty TRs saved) ) Number of applications with reduced call graph : 1 ( #34065 (empty TRs not saved) ) Number of relevant objects in repository : 5323 Number of OMG AFP-links in repository : 11043 Number of Data Entities + End Points : 248 Number of empty Transactions with estimated FP value : 2 Number of non-empty + empty Transactions : 150 ( = non-empty: 137 + empty: 13 ) Number of links -> Data Entities + End Points : 1864 ( = DE+EP: 812 + intermediate objects: 1052 ) Number of links -> other objects in full graphs : 6039 ( includes 81 links in empty Transactions ) Number of Transaction links generated (sum) : 7903 ( = 1864 + 6039 ) Number of objects in the largest non-empty Transaction : 180 Number of objects in the largest empty Transaction : 22 Number of elements in the largest SCC group : 12 Number of elements allowed in SCC groups : 1000 at most Number of elements in largest used SCC group : 3 Number of ignored SCC groups (too large) : 0 Saving graph results... Saved full call graphs of transactions in application #33949 (6563 details). Saved reduced call graphs of transactions in application #34065 (164 details). Saved full call graphs of transactions in application #34110 (1176 details). Computation finished.
It is now possible to configure the CAST Transaction Configuration Center to assess Function Points for all Transactional Functions for which the call graph does not reach a data entity nor an end-point based on existing Function Points that have been computed.
CAST Transaction Configuration Center determines the average number of nodes in the call graph of non-empty Transactional Functions corresponding to one DET. This ratio allows CAST Transaction Configuration Center to assign the number of DET to empty Transactional Functions, depending on the number of nodes in their associated call graph. The Function Point value will be then assessed based on that number of DET and with an FTR=1.
A new value (ASSESS) is available to assess the Function Point value in the Compute settings:
It is not possible to set ASSESS when Save objects of empty Transactions is set to NEVER:
When computing Function Points with the parameter set to ASSESS empty transactional functions will no longer exist. Their number and Function Point counts are displayed in the AFP Calibration page (see the lines in blue):
The average number of objects per DET ratio is computed on the number of object details in the non-empty transactional functions call graph and the corresponding DET. This ratio is then applied to empty transactional functions to determine their DET. A tooltip is available on blue lines:
The Transactional functions panel will distinguish transactional functions with an "assessed" Function Point from the others by the icon displayed in the Default FP column:
The origin of the Function Point value is sent to AFP metrics as:
10204 274356 1 "4" "DET: 5, FTR: 1 (Output or Inquiry):Assessed" 0 -3 0
This makes it visible in the Enhancement panel for Transactional functions via the column Source that indicates if the Function Point value has been assessed:
The Impact of using ASSESS, is in the enhancement measure. All transactional functions which were empty in a previous snapshot after setting ASSESS will no longer be empty in the next snapshot, so they will be seen as new Transactional functions in the Enhancement panel with a status ADDED. This will increase the AFP value and consequently increase the AEP/EFP values.
If the enhancement measure for the application is set to the legacy EFP and the empty transactional function's detail is saved only for AEP then no assessment will be done, even though the ASSESS is set in computing settings.
It is now possible to see the list of objects called by a transaction in AFP Calibration > Transactional functions using the right click View objects option. This also allows you to understand the Function Point value for assessed transactional functions:
Click to enlarge
This will open a dialog box with the list of objects called by the associated transaction. This list contains all objects called by the transaction with the name, fullname, object type, and the role in the transaction graph:
Click to enlarge
An assessed transactional function is originally an empty transactional function, which has no data function. When using the View datafunctions called by this transactional function right click menu option in AFP Calibration > Transactional functions:
a message is displayed to show that the transaction is assessed and has no data function:
Previous releases of CAST Transaction Configuration Center did not recognize certain object types to be datafunctions of a given transaction. This has now been updated and the following objects are correctly recognized as datafunctions of a given transaction:
See also Changes or new features - 8.3.21.
The User Input Security feature has been updated and improved as follows: