CAST Engineering Dashboard - Object - Incorrect Object Status - Same object seen as added deleted

When looking at the compare version page in the legacy CAST Engineering dashboard or in the Engineering or Health Dashboard, you can see that same object is seen in both added and deleted lists of objects.

This page help to understand why this object is seen as added/deleted.

1. Connect to the dashboard
2. Go to the compare version
3. See same object in both added/deleted lists

1. Known case
2. Relevant input
3. Investigate the compare version screenshot to validate the expectation. If the expectation is correct go to next step
4. Get the ID of the object in the central for both snapshot to make sure that ID has changed 
5. Check if the local site ID is the same for both ID identified in previous step. If the local site ID is the same, go to next step 
6. Look at the GUID of the objects in KB If the GUID did not change go to the next step .  
7. First check that no set of objects have been deleted in KB (drop analysis results) and then recreated by a new analysis between 2 snapshot. Indeed, in this case, objects will appear as added/deleted in dashboard, even if they are the same objects. This is  expected behavior.
8. If no analysis results have been dropped, Reproduce the issue (change of the object id without change of GUID), by restoring the previous KB and runing the analysis  on current source code
9. If issue reproduced,contact CAST Technical Support with input. 

Known Case

1. For the offline analysis of  PL/SQL and T-SQL, with the embedded CAST analyzer vs. the SQL analyzer extension: 
     If the instance or server name is changed between the two snapshots, then it lead to change of all DB objects fullname. As consequence, all DB objects will be seen as added/deleted.
   It is expected behavior. However there is workaround for the same. Please refer the below page for the work around.
   For PL-SQL : PL-SQL offline analyzer new - How to modify server name without generating added/deleted DB objects
   For T-SQL   :  CMS Snapshot Analysis - Run Analyzer - T-SQL - Information - How to modify schema name in T-SQL extraction before analysis  
   
   
2. For .NET Core projects when migrating from older CAST versions to 8.3.x:When migrating from older CAST versions to 8.3.x and you have .NET Core projects, you may see added/deleted objects show up in the results to dependency conflicts with .NET Core projects.  The best way of handling this is to make sure you are analyzing with the .NET extension version 1.1.x  or above which correctly handles .NET core projects and their dependencies.  An example of added/deleted objects in the TCC results is shown in the screenshot below (similar results can be seen in the dashboard and other areas of the product):

   
   

   

3. For Mainframe technology

   For an object in mainframe which is linked with two source files i.e one from cobol file and other from copybook file then the checksum computed for that object is calculated by using both the source files. Even if cobol file is not changed but the copybook file has been changed the checksum computed for the object will be changed and the object will come as mofidied in the dashboard which is an expected behavior.

   1. Added/Deleted objects for which the GUID has not changed between two versions. This is possible in below cases:
      a. When Version V2 is created, an Analysis Unit has been removed and when the analysis is executed the objects are dropped. Then, if the analysis unit is recreated manually, the objects are recreated after running the analysis with a new object ID even if the GUID has not changed.
      b. When, between the Version V1 and Version V2 the Site ID of KB has changed : the object ID does not change in the KB, but it has changed in the CB, then the object will be added/deleted.

   2. Added/Deleted objects when source code is not supposed to be changed, but GUID has changed: If in a method, a parameter type has been changed in Version V2 as compared to Version V1, the GUID will change.
      Example:
      
      

      V1

      99?com?99?customer?99?project?99?business?99?subproject?99?requisition?99?impl?620?s:/sources/main-cust/project/project/project-core/project-core-business/src/main/java/com/customer/project/business/subproject/requisition/impl/file_name.java?100?class_name?102?method_name(99?com?99?customer?99?project?99?modele?99?demande?100?Demande,99?com?99?customer?99?project?99?modele?99?subproject?100?EnvoiAnalyseDde,99?com?99?customer?99?project?99?modele?99?utilisateur?100?Utilisateur)

      V2

      99?com?99?customer?99?project?99?business?99?subproject?99?requisition?99?impl?620?s:/sources/main-cust/project/project/project-core/project-core-business/src/main/java/com/customer/project/business/subproject/requisition/impl/file_name.java?100?class_name?102?method_name(99?com?99?customer?99?project?99?modele?99?demande?99?requisition?100?Demande,99?com?99?customer?99?project?99?modele?99?subproject?100?EnvoiAnalyseDde,99?com?99?customer?99?project?99?modele?99?utilisateur?100?Utilisateur)

      The method is method_name. The parameter type has changed between the two versions. Indeed, in the method, the package of the type turn from :

       In V1 : import com.xyz.modele.commun.Domaine; to In V2 : import com.xyz.modele.demande.requisition.Demande;

      
      

Relevant input

• Screenshot of the compare version showing the issue (with url and the object fullname visible) 
• Sherlock  (KB corresponding to the current snapshot) 
• KB corresponding to the previous snapshot
• current source code

Investigate the compare version screenshot 

There is two points to check in the compare version screenshot:

1- The object full name need to be the same

You need to ensure that the full name of the object is exactly the same in the "Details of added" list and "Details of deleted" list. If the full name is not the same, this explains objects are not the same, hence it is normal to get it in the added/deleted list

2- The object still have the same complexity

You need to ensure that the object keep the same complexity in both snapshots. For example if the object appear in the "Details of added artifacts with high complexity" list and "Details of deleted artifacts with very high complexity" list, the object has no longer the same complexity. Hence it is normal to get it in the added/deleted list

Get the ID of the object in the central for both snapshot to make sure that ID has changed

Run the following query on latest version of your CB (the version associated to latest snapshots): 

select *
 from dss_objects dos
 join dss_object_info doi
 on doi.object_id = dos.object_id
 join dss_snapshots ds
 on ds.snapshot_id = doi.snapshot_id
 where lower(dos.object_name) like '%lowerofobjectname%'
 and doi.snapshot_id in (current_snapshot_id, previous_snapshot_id)
 order by functional_date desc

Where:

• current_snapshot_id is the latest snapshot of the application
• previous_snapshot_id is the previous snapshot of the application

This query should return 2 entries with 2 different objects ID corresponding to current_object_id and previous_object_id. For example:

select *
 from dss_objects dos
 join dss_object_info doi
 on doi.object_id = dos.object_id
 join dss_snapshots ds
 on ds.snapshot_id = doi.snapshot_id
 where lower(dos.object_name) like '%/x/bifm_afvc%'
 and doi.snapshot_id in (40,37)
 order by functional_date desc

368393;133010;"/X/BIFM_AFVC";"";"XXX/BIFM_AFVC";40;368393;133010;854921762;40;132851;"2016-01-07 23:46:00";3;"December_2015";"";"2016-01-07 01:59:08.914";"2016-01-07 01:51:49.931";"2016-01-07 02:15:55.389";2;0;40

286809;133010;"/X/BIFM_AFVC";"";"XXX/BIFM_AFVC";37;286809;133010;854921762;37;132851;"2015-12-10 19:37:00";3;"November_2015";"";"2015-12-10 21:57:48.048";"2015-12-10 21:50:17.829";"2015-12-10 22:06:58.985";2;0;37

In the results above:

• current_object_id =368393
• current_object_type_id = 133010
• previous_object_id=286809
• previous_object_type_id = 133010
• current_snapshot_id = 40
• previous_snapshot_id = 37

If your object has object_type_id = 30001 or 30002 please refer to the page - Transaction Configuration Center - Enhancement - Transactional Functions - Status Variation - Transactions status are ADDED and DELETED

Else if the object_type_id is different (other than 30001 or 30002) and if the object_ID has not changed between two snapshots (object_id returned by the query is same) then you do not have any added/deleted. Please check again if the object is having the same complexity in the compare version view. If it is the same then contact support with the requested inputs.

Check if the local site ID is the same for both ID identified in previous step

Run the following query on latest version of your CB (the version associated to latest snapshots): 

select *
 from dss_translation_table
where object_id in ( current_object_id,  previous_object_id )

Where:

•  current_object_id is the one given in previous query
•  previous_object_id is the one given in previous query

This query should return 2 entries. We have 2 cases:

1. Local Site ID is different

   If the local site ID is not the same, it means it has been manually changed in the Management base leading to added/deleted objects (as the central consider the objects as coming from 2 different KBS). In this case, it is an expected behavior
   
   If we continue with the same example:
   select * from dss_translation_table where object_id in (368393,286809)
   826493537;2175014;286809
   1101841681;2175014;368393
   
   We can see that local_site_id associated to  286809  object is 826493537 where local_site_id associated to 368393 object is 1101841681. This means that the local_site_id of the local DB associated to the application was intialy equals to 826493537 but has been updated in CMS. You can check this by restoring both MBs associated to both versions:
   
   
   In this case, the solution is to set the local_site_id to its initial value (in the example provided, it needed to be set back to 826493537), drop latest snapshot, and generate it again (by skipping analysis) to get the issue resolved
   
   

2. Local Site ID is the same 

Please get both current_site_object_id (site_object_id corresponding to current_object_id) and previous_site_object_id (site_object_id corresponding to previous_object_id) from the quey above and  go to next step to continue the investigation

Look at the GUID of the objects in KB

Run the following query on your KB : 

select o.idkey as OBJECT_ID, o.IdNam as GUID
 from Objects o
where o.IdKey in (current_site_object_id , previous_site_object_id  )

Where current_site_object_id and previous_site_object_id has been retreived from previous query

If the results are different, this explains why objects are seen as added/deleted. Indeed, depending on the technology your are analyzing, some configuration modification can explain this behaviour. For example when the techno is .NET, using different .net framework makes the objects marked as added/deleted. In the same way, the java version in J2EE, different version of external library in C/C++ makes the objects marked as added/deleted

Examples of GUID changes:

1. Changing framework version in .net

   Object GUID in previous KB,

   "methCS_Net?s:\xx\source\eers\source\xx\xx.csproj?proj_Net?citi?nmsp_Net?icg?nmsp_Net?gts?nmsp_Net?sfs?nmsp_Net?ais?nmsp_Net?xx?nmsp_Net?Program?clsCS_Net?Main(cls_Net?c:\windows\microsoft.net\framework64\v2.0.50727\mscorlib.dll?asm_Net?System?nmsp_Net?String[])"

   Object GUID in current KB,

   "methCS_Net?s:\xx\source\eers\source\xx\xx.csproj?proj_Net?citi?nmsp_Net?icg?nmsp_Net?gts?nmsp_Net?sfs?nmsp_Net?ais?nmsp_Net?xx?nmsp_Net?Program?clsCS_Net?Main(cls_Net?c:\windows\microsoft.net\framework64\v4.0.30319\mscorlib.dll?asm_Net?System?nmsp_Net?String[])"
   
   How to interpret results? .Net Framework changed in the analysis machine

   How to fix the issue? Use the same framework to fix the issue.
   
   

2. Resolution issue

   Object GUID in previous KB
   "99?rr?99?xx?99?xx?99?expres?99?ejb?104?Expres"
   
   Object GUID in current KB:
   "Expres"
   
   How to interpret results? The Expres class has been correctly resolved in previous analysis and not in the current one due to some change in the configuration (for example: missing classpath, missing source/jars, environment profile, etc).
   When looking into the last log file, you should find some Warning UNKNOWN ; Job execution can not resolve 'Expres' as type in package 'fr.xx.xx.expres.ejb' from package 'fr.xx.xx.expres.ajax'
   How to fix the issue? Review the configuration to fix all these "can not resolve" warnings in both versions of the analysis. 
    

3. Better object resolution after migration from 7.0.x (x<10) to 7.3.x

   Object GUID in 7.0.x  KB:
   XX.ORACLE.XXX.CAST_SQL_Schema.YYY.CAST_Oracle_PackageBody.PERIOD_UTIL.CAST_Oracle_Function.FIND_PERIOD(<RETURN VALUE>-YYY.CM_PERIODS,P_MOD_PROC_CODE-YYY.SC_MODULES_PROCESSES.MOD_PROC_CODE,P_PERIOD_ID-YYY.SC_PERIOD_DEF.PERIOD_ID)
   
   Object GUID in 7.3:
   ORACLE.XXX.CAST_Oracle_Schema.YYY.CAST_Oracle_PackageBody.PERIOD_UTIL.CAST_Oracle_Function.FIND_PERIOD(<RETURN VALUE>-YYY.CM_PERIODS,P_MOD_PROC_CODE-VARCHAR2,P_PERIOD_ID-NUMBER)
   
   How to inerpret resutls? The GUID of function 'find_period' changes because function parameter's type changes due to better resolution of %type.

   In CAST AIP 7.0.x, the product was not able to resolve parameters with a %type type.As consequence, the GUID of associated functions and procedure objects was constructed by using the parameter name that appears just before the %type.

   The non resolution of %type type parameters was considered an issue and was therefore corrected in a release of CAST AIP after 7.0.9. As a result of this fix, the construction of GUIDs for PL/SQL procedures and functions also changed - the real type name is now used in the GUID.

   Therefore when migrating from CAST AIP 7.0.x (x<10) to CAST AIP 7.3.x and after running a snapshot in CAST AIP 7.3.x, results may show a number of deleted and added procedures and functions. These objects are not new objects, they are the same objects. However, because their GUID has changed due to the bug fix on %type resolution,They are shown as new objects.
   How to fix the issue? Nothing to fix. Since this is due to an enhancement of the product

   
   

4. Missing source code in the source directory

   Object GUID in previous KB,

   "xxxx(xx,AttachmentType)"

   Object GUID in current KB

   "xxxx(xx,99?fr?99?xx?99?xx?99?xx?99?xx?99?types?100?AttachmentType)"

   How to inerpret resutls? in version v0, the type AttachmentType is not resolved. When looking at the job that should analyze the file containing the type, the job configuration could not be the same in both versions. In particular, directories/files can be missing in version v0. If the file containing the type is in the missing files or is belonging to a missing path, it has not been analyzed, hence it is normal to get it unresolved.

   How to fix the issue? Apply the same configuration between the 2 source versions to avoid such added/deleted objects
   
   

5. Change in Java Version in Job Configuration

   Object GUID in previous KB

   "xxxx(xx,99?java?99?util?104?List)"

   Object GUID in current KB

   "xxxx(xx,99?java?99?util?990?List{1})"

   How to interpret results? in the first version, java.util.List is resolved as an regular interface (like it would be the case in Java 1.4) and in the second version it is resolved as a generic interface java.util.List<?> (like it may happen in Java 1.5+).

   How to fix the issue? Apply the same configuration between the 2 source versions to avoid such added/deleted objects

6. Migration from 7.0.7 with javascript files analyzed in the J2EE analyzer

   Object GUID in previous KB on 7.0.7:

   "<filePath>xxx.js#1<methodname><filepath>"

   Object GUID in current KB on 7.3.X:

   "<filePath>xxx.js<methodname><filepath>"

   How to interpret results? This was due to a change in the analyzer in 7.0.8 to resolve some analyzer issues which resulted in this change in GUID.

   How to fix the issue? Cannot be fixed or resolved during migration or post migration. 

7. Change in the scope of the object

   Object GUID in previous KB "ORACLE.IPSQIPJP.CAST_Oracle_Schema.WEFTSAV.CAST_Oracle_PackageBody.GESTORACLEOBJ.CAST_Oracle_Procedure.KILLSESSIONUSER(PNOMUSER-VARCHAR)"

   Object GUID in current KB "ORACLE.IPSQIPJP.CAST_Oracle_Schema.WEFTSAV.CAST_Oracle_PackageBody.GESTORACLEOBJ.CAST_Oracle_PrivateProcedure.KILLSESSIONUSER(PNOMUSER-VARCHAR)"

   How to interpret results? In the current version you can see that the procedure is detected as Private procedure but in the previous analysis it was detected as public procedure. In the current source code check that there is declaration of the procedure KILLSESSIONUSER in the package header file. If there is no declaration then it is expected to have the procedure to be considered as private. If there is declaration of the procedure KILLSESSIONUSER in the package header file then please check in the analysis log files of the current version for warnings like - 'GESTORACLEOBJ' is found as invalid - Please check your code and recompile it if necessary. How to fix the issue? If you have such errors then please refer to the following page to resolve this issue - CMS Snapshot Analysis - Run Analyzer - Warnings - Oracle Server PL SQL with Core CAST AIP - Object 'XX_YY_ZZ' is found as invalid

8. Change in the parameter of the object Change in the deployment folder

   Object GUID in previous KB "updateTargetGroupFamilyStatus(99?java?99?lang?100?String,99?com?99?fanniemae?99?ccp?99?pu?99?dataaccess?99?das?104?DataAccessServicesHub,99?java?99?util?990?List{1},   ..."

   Object GUID in current KB "updateTargetGroupFamilyStatus(99?java?99?lang?100?String,99?com?99?fanniemae?99?ccp?99?pu?99?service?104?ServiceCommunicator,99?java?99?util?990?List{1},   99?java?99?util?990?List{1},   ..."

   How to interpret results?  As you can see in the GUID results above, some parameters have been changed in the definition of the method. Please check the declaration of the method in the source repository for both versions. If the parameter has changed, it is an expected behavior

   
   

9. Change in the deployment folder:

    Object GUID in previous knowledge base:

    "d:/cast/deploy/dossier_server/source code/dossierserver/dossierservices/src/main/java/com/cetelem/dossierserver/publication/v1/impl/dossierserverpublication.java?100?DossierServerPublication?102?callInstanceServer(99?com?99?cetelem?99?lib?99?util?99?remoting?100?Context,99?com?99?cetelem?99?dossierserver?99?publication?99?v1?99?model?100?DossierRequest)"

    Object GUID in current knowledge base:

    "d:/cast/deploy/dossier_server/source code/dossierserver/src/com/cetelem/dossierserver/publication/v1/impl/dossierserverpublication.java?100?DossierServerPublication?102?callInstanceServer(99?com?99?cetelem?99?lib?99?util?99?remoting?100?Context,99?com?99?cetelem?99?dossierserver?99?publication?99?v1?99?model?100?DossierRequest)" 

   How to interpret results?

   The deployment folder is not the same in the two knowledge bases, which results a different GUID between the two knowledge bases, this explains why objects are seen as added/deleted.

   How to fix the issue?

   You must to have the same deployment folder for the 2 analysis. For that you must to reanalyze your application while maintaining the same deployment folder as the first analysis. 

10. Characters/Numbers appended at the end of GUID

          Object GUID in previous knowledge base: 

13114;  "MSSQLServer.SQLEXPRESS2014.RUD_Dev_DB_UserAdmin.CAST_MSTSQL_Schema.dbo.CAST_MSTSQL_Procedure.SetVehicleBasicDetails_sp(@Flag-varchar,@iVehicleID-int,@VehicleReg-varchar,@VehicleID2-varchar,@Make-varchar,@VehicleTypeID-int,@Models-varchar,@ChassisVin-varchar,@BodyTypeID-int,@EngineSizeCC-int,@FuelType-varchar,@FuelCapacityLitres-int,@Colour-varchar,@TaxClass-varchar,@PayLoadLitres-int,@Cost-decimal,@Term-varchar,@ContractDistance-int,@ExcessPpm-varchar,@ExcessMileageCharge-decimal,@ConcessionAreaID-int,@BaseLocationID-int,@Operations-varchar,@OperationalCostCentre-varchar,@MobileNo-varchar,@MobexNo-varchar,@SimCardNo-varchar,@RadioCode-varchar,@TrailerID-varchar,@TrailerID2-varchar,@TrailerMake-varchar,@TrailerModel-varchar,@DateAttachedToVehicle-datetime,@TrailerTypeID-int,@TaxDueDate-datetime,@MotDueDate-datetime,@MotCertificateNumber-varchar,@TachoDueDate-datetime,@TankDueDate-datetime,@VehicleOdometerReading-int,@TrailerOdometerReading-int,@EngineSerial-varchar,@GearBoxSerial-varcha <#7cb8a779>"

 Object GUID in current knowledge base:

1233064;"MSSQLServer.SQLEXPRESS2014.RUD_Dev_DB_UserAdmin.CAST_MSTSQL_Schema.dbo.CAST_MSTSQL_Procedure.SetVehicleBasicDetails_sp(@Flag-varchar,@iVehicleID-int,@VehicleReg-varchar,@VehicleID2-varchar,@Make-varchar,@VehicleTypeID-int,@Models-varchar,@ChassisVin-varchar,@BodyTypeID-int,@EngineSizeCC-int,@FuelType-varchar,@FuelCapacityLitres-int,@Colour-varchar,@TaxClass-varchar,@PayLoadLitres-int,@Cost-decimal,@Term-varchar,@ContractDistance-int,@ExcessPpm-varchar,@ExcessMileageCharge-decimal,@ConcessionAreaID-int,@BaseLocationID-int,@Operations-varchar,@OperationalCostCentre-varchar,@MobileNo-varchar,@MobexNo-varchar,@SimCardNo-varchar,@RadioCode-varchar,@TrailerID-varchar,@TrailerID2-varchar,@TrailerMake-varchar,@TrailerModel-varchar,@DateAttachedToVehicle-datetime,@TrailerTypeID-int,@TaxDueDate-datetime,@MotDueDate-datetime,@MotCertificateNumber-varchar,@TachoDueDate-datetime,@TankDueDate-datetime,@VehicleOdometerReading-int,@TrailerOdometerReading-int,@EngineSerial-varchar,@GearBoxSerial-varcha <#a920b05c>"

How to interpret results?
As you can see at the end of GUID some characters are appended this happens when GUID length is more than 1-15 characters. In this case analyzer will compute the checksum and append it to teh end of GUID. IF this checksum
appended is different in both run that indicates that your object code has been changed.

How to fix the issue?
In this case check your object in both run to confirm it is changed. IF code is not same between 2 run then GUID change is expected.

Reproduce the issue (change of ID wihout change of the GUID)

If the GUID is exactly the same in both version of the KB, but you observe a change in ID for the object, you should first see if there have been changes to the analysis job which might have resulted in these changes.

If you run the query:

select * from anajob order by idjob

on the prior and current local databases, you can see if there have been changes made where new  jobs have been added or an analysis job has been deleted and re-added.

If not, will need to reproduce the issue by:

1. Restoring the previous KB

2. Run the query

   select k.idkey, k.keynam, o.IdNam as GUID
    from Objects o
    join Keys k
    on k.IdKey = o.IdKey
    and lower(k.keynam) like '%objectname%' 

3. Run the analysis  on current source code

4. Run the query again

   select k.idkey, k.keynam, o.IdNam as GUID
    from Objects o
    join Keys k
    on k.IdKey = o.IdKey
    and lower(k.keynam) like '%objectname%' 

   If the issue is reproduced, (no change in the GUID, but change in k.idkey), contact CAST Technical Support with input.

 See zendesk ticket 2912, 5656