Report Generator - Generate Reports with UI - Empty lists - Empty Application list

This page is a troubleshooting guide for the problem : Application list is empty in report generator after validating the login password as shown below

1. Check if you have any Exceptions in tomcat log during deploying the war
   1. Check if you have the exception IOException while loading persisted sessions : java.io.EOFexception in tomcat log files.
      
      1. If yes, then apply the solution given in this page and
      2. Restart the Report Generator for the applications to be visible in the list.
   2. If there are no errors/warnings and the log looks clean, go to next Step.
2. Navigate through the Rest API application to check whether issue is on the data retrieved or on the report generator display. We need first to ensure whether the issue is on the report generator display or on the retrieved information through the Rest API application. For this, we need to connect to the Rest API application first to check whether the same user is able to access the resource through Rest API interface. For this, perform the following:
   1. Open a browser (in chrome preferably)
   2. Connect to your Rest API application (for example: http://localhost:8080/DeployedRestAPIWAR/static/default.html)
   3. Put the same credential you are using to connect to the report generator and log in
   4. You should have a message: "session created" or "logged as XXX"
   5. You can than click on the submit button to access the available resources
   6. Go to the resource containing your application and try to navigate until the snapshot you want to generate the report for
   7. If all information are accessible through the Rest API application, then issue is on the report generator display. Contact CAST Technical Support with the r Relevant Input
   8. If during your navigation, the Rest API display a blank page or there is an error message, then issue is on the data information retrieved. You may check for  known inconsistencies in the Central Base and how to repair them.
3. If the issue is on the data retrieved from the CB, check for known inconsistencies in the Central Base and how to repair them. If you are not able to access information from the Rest API interface, you need to check for inconsistency in the central base that may lead to error in the log.
   1. First identify the aad.log file. It is located inside the application war currently deployed, check for last error in this log file.
      

      1. Check if the sub query returns more than one row.

         1. Check In the aad.log file, if you have a sub query which returns more than one row error, as shown in this example

            select t.METRIC_ID, (select n.METRIC_DESCRIPTION from DSS_METRIC_DESCRIPTIONS n where n.METRIC_ID = t.METRIC_ID and n.LANGUAGE = 'ENGLISH' and n.DESCRIPTION_TYPE_ID = 0 ) as DESC_METRIC_NAME, t.METRIC_NAME as TYPE_METRIC_NAME, (select s.METRIC_DESCRIPTION from DSS_METRIC_DESCRIPTIONS s where s.METRIC_ID = t.METRIC_ID and s.LANGUAGE = 'ENGLISH' and s.DESCRIPTION_TYPE_ID = -1) as METRIC_SHORT_NAME, t.METRIC_GROUP, ht.METRIC_PARENT_ID as METRIC_PARENT_ID, (select d.METRIC_DESCRIPTION from DSS_METRIC_DESCRIPTIONS d where d.METRIC_ID = t.METRIC_ID and d.LANGUAGE = 'ENGLISH' and d.DESCRIPTION_TYPE_ID = 2) as METRIC_DESCRIPTION, max(ht.SNAPSHOT_ID) as SNAPSHOT_ID from DSS_METRIC_TYPES t join DSS_METRIC_HISTO_TREE ht on ht.METRIC_ID = t.METRIC_ID where t.METRIC_GROUP in (0,1,5,6,10,13,15,99) group by t.METRIC_ID, t.METRIC_NAME, t.METRIC_GROUP, ht.METRIC_PARENT_ID

            here sub query returns more than one row
            

         2. Identify the sub queries. You need to investigate the details of this query on an SQL session in the faulty central, to identify which sub query is returning more than one row. In the example provided, there are 3 sub queries

            select n.METRIC_DESCRIPTION from DSS_METRIC_DESCRIPTIONS n where n.METRIC_ID = t.METRIC_ID and n.LANGUAGE = 'ENGLISH' and n.DESCRIPTION_TYPE_ID = 0
            select s.METRIC_DESCRIPTION from DSS_METRIC_DESCRIPTIONS s where s.METRIC_ID = t.METRIC_ID and s.LANGUAGE = 'ENGLISH' and s.DESCRIPTION_TYPE_ID = -1
            select d.METRIC_DESCRIPTION from DSS_METRIC_DESCRIPTIONS d where d.METRIC_ID = t.METRIC_ID and d.LANGUAGE = 'ENGLISH' and d.DESCRIPTION_TYPE_ID = 2

            
            

         3. Modify these queries to be able to run them and to identify the duplicate row as following

            Run sub queries to identify the duplicate row

            select s.METRIC_ID, count(s.METRIC_DESCRIPTION) from DSS_METRIC_DESCRIPTIONS s where s.LANGUAGE = 'ENGLISH' and s.DESCRIPTION_TYPE_ID = 0 group by s.METRIC_ID having count(s.METRIC_DESCRIPTION) >1
            select s.METRIC_ID, count(s.METRIC_DESCRIPTION) from DSS_METRIC_DESCRIPTIONS s where s.LANGUAGE = 'ENGLISH' and s.DESCRIPTION_TYPE_ID = -1 group by s.METRIC_ID having count(s.METRIC_DESCRIPTION) >1
            select s.METRIC_ID, count(s.METRIC_DESCRIPTION) from DSS_METRIC_DESCRIPTIONS s where s.LANGUAGE = 'ENGLISH' and s.DESCRIPTION_TYPE_ID = 2 group by s.METRIC_ID having count(s.METRIC_DESCRIPTION) >1

            
            

            Query results interpretation

            If one of the queries return some rows, it means that description appears twice for a particular rule,

            if we get
            

            Example

            select s.METRIC_ID, count(s.METRIC_DESCRIPTION) from DSS_METRIC_DESCRIPTIONS s where s.LANGUAGE = 'ENGLISH' and s.DESCRIPTION_TYPE_ID = 2 group by s.METRIC_ID having count(s.METRIC_DESCRIPTION) >1

            Example query results interpretation

            If the above query returns 5092 2
            It means that the rule 5092 has 2 descriptions when DESCRIPTION_TYPE_ID = 2 leading to this error in the log that prevent from retreiving the data from the central

            
            

         4. Clean up the faulty sub query (ies) identified.

            1. Clean up the central in order to remove the duplicate row.  For this, you need to connect to the central base and do the following:

               1. Create a temporary table containing unique description for faulty rows
               2. Delete the faulty row from the initial table
               3. insert the content of the temporary table to the intial table
               4. drop the temporary table
               Example

               If we keep the same example as before, the faulty query is the following

               select s.METRIC_ID, count(s.METRIC_DESCRIPTION) from DSS_METRIC_DESCRIPTIONS s where s.LANGUAGE = 'ENGLISH' and s.DESCRIPTION_TYPE_ID = 2 group by s.METRIC_ID having count(s.METRIC_DESCRIPTION) >1

               retruns 5092 2

               We need to update the rule 5092 to keep only one descption. Here are the steps to follow

               create table temp1 as   select distinct metric_id, description_type_id, language, metric_description from DSS_METRIC_DESCRIPTIONS where METRIC_ID = 5092 and DESCRIPTION_TYPE_ID = 2;
               delete from DSS_METRIC_DESCRIPTIONS where METRIC_ID = 5092 and DESCRIPTION_TYPE_ID = 2;
               insert into DSS_METRIC_DESCRIPTIONS  (metric_id, description_type_id, language, metric_description) select metric_id, description_type_id, language, metric_description from temp1;
               drop table temp1;
               commit;

               Then you can check that the duplicate have been removed, by running again this query and checking that it returns no row:

               select s.METRIC_ID, count(s.METRIC_DESCRIPTION) from DSS_METRIC_DESCRIPTIONS s where s.LANGUAGE = 'ENGLISH' and s.DESCRIPTION_TYPE_ID = 2 group by s.METRIC_ID having count(s.METRIC_DESCRIPTION) >1

               Once all sub queries do no longer return rows, you need to restart the tomcat application to empty the cache. Then, you will be able to access the rest API application and to access the application and snapshots in the report generator.

         5. Once all sub queries do no longer return rows
            

         6. Restart the tomcat application to empty the cache. Then, you will be able to access the rest API application and to access the application and snapshots in the report generator.

4. If the issue is on the report generator display or if the inconsistency is not a known one, contact CAST Technical Support with Relevant Input

 webcall 29984

Application Analytics Dashboard - AAD - Information - Rest API and Tomcat server interaction - CAST Internal

Report Generator - Generate Reports with UI - Empty lists - Empty Snapshot list