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

This page provides the details about a known issue related to the configuration of Engineering Dashboard.

This issue in the configuration leads to an error that comes up on the login page of the ED and does not allow the user to login and work on ED.

Following is the screenshot of the error that comes up on the login page to make the issue more clear:

In the above screenshot, the error is clear and it appears on the login page of ED preventing the user to login and work on ED.

Observed in CAST AIP
Release
Yes/No
8.3.x(tick)
Observed on RDBMS
RDBMS
Yes/No
CSS(tick)
Step by Step Scenario

Below is the step-by-step scenario leading to the problem:

  1. Run Analysis + Snapshot for an application.
  2. Open ED (Engineering Dashboard).
  3. Try logging in through the credentials (username and password).
  4. Encounter the error : "DBMS CONNECTIONS HAS FAILED OR ALL DOMAINS LOADING HAVE BEEN ABORTED" as shown above in the screenshot.
Impact of the Problem

The impact of the problem on the dashboard is: The user will not be able to login and access the dashboard due to this error.

Action Plan

CASE-1:

Context.xml configuration issue :

This problem is encountered when the Web Application Server being used is Apache Tomcat 8, because there is a small change in the configuration of ED for Tomcat 7 and Tomcat 8. Following is why the problem has happened:

During the configuration of ED, the Central Base name is supposed to be configured in the META-INF\context.xml.

In case of Tomcat 8, there is a separate syntax to configure the central base which is mentioned in the context.xml itself.

This problem occurs when the connection string to the database (central base) is not correctly configured.

In Tomcat 7: This is how it is in Tomcat 7: 

<Resource name="jdbc/domains/ED" url="jdbc:postgresql://localhost:2280/postgres"
 initConnectionSqls="SET search_path TO test_php_800_central;"
 username="operator" password="CastAIP"

 In Tomcat 8: This is how it is in Tomcat 8:

<Resource name="jdbc/domains/ED" url="jdbc:postgresql://localhost:2280/postgres"
 connectionInitSqls="SET search_path TO cb800_5140_abh_sup_central;"
 username="operator" password="CastAIP"

Everything is similar, except the Parameter "connectionInitSqls" which is different in Tomcat 8.

Note, that the parameter "connectionInitSqls" is not supposed to have C in Upper Case. If it does, then the parameterization becomes wrong and it won't work.

Below Wrong and Correct configuration is provided for better understanding:

Wrong:

<Resource name="jdbc/domains/${domainName}" 
			url="jdbc:postgresql://${host}:${port}/postgres"
			ConnectionInitSqls="SET search_path TO ${schema};"
			username="${user}" password="${password}" 

			auth="Container" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
			validationQuery="select 1" initialSize="5" maxTotal="20" maxIdle="10" maxWaitMillis="-1"/>

Please note, that the "C" in "ConnectionInitSqls" in above screenshot is in Upper Case. This is wrong configuration.


Correct:

<Resource name="jdbc/domains/${domainName}" 
			url="jdbc:postgresql://${host}:${port}/postgres"
			connectionInitSqls="SET search_path TO ${schema};"
			username="${user}" password="${password}" 

			auth="Container" type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
			validationQuery="select 1" initialSize="5" maxTotal="20" maxIdle="10" maxWaitMillis="-1"/>


To fix the problem, proceed as follows:

  1. Open META-INF\context.xml
  2. Scroll to the connection details.
  3. Check if every parameter is in the same way it is supposed to be(mainly schema name and db server name)
  4. If there is "ConnectionInitSqls" instead of "connectionInitSqls", then fix it by putting a "c" in lowercase as shown in the above screenshot and making the parameterization perfect.
  5. Then either restart the tomcat service or reload the application. Then login.

Here is the screenshot after applying the above solution and launching the application again.


NOTE

Please note, that the template for the configuration for tomcat 8 is already present in the context.xml. So it's recommended to copy that template and configure it for tomcat 8 accordingly.

CASE-2:

DB server is down:

This issue might occur when your db/pg server is down. So check the connectivity of db server to ensure it is working fine. If not, you can try restarting the server once.

You can also refer the Postgres log to see the connection issues. You can get the log by using query Query

CASE-3:

Measurement schema is empty :

There is a possibility that measurement schema is not activated in CAST-MS and you have uploaded the snapshot to measurement during snapshot computation. In this case, no data will be stored in measurement base and if you configure the same in AAD/HD war and try to login, you will end up with the above error.

To resolve the issue please activate the measurement schema in CAST-MS as shown below and upload the snapshot again.

CASE-4:

For Peoplesoft and Siebel Application:

If you are facing this error for Siebel or Peoplesoft application then, most likely the cause will be you are trying to access the dashboard from Vanilla schema. The Vanilla schemas are used in the discrimination process, which is used to identify differences between the standard installation (also called Vanilla) and the project environment. 

So you need to access the dashboard from Project schema to access the result. Below is the architecture to understand the flow better :

CASE-5:

Check if there are corruptions in central :

i] Run below 2 queries on central. If any one of this query gives  results, then there are corruption in central:

select object_id,object_type_id, object_name, object_description, object_full_name, count (1)
from dss_objects
group by object_id,object_type_id, object_name, object_description, object_full_name
having count(1) > 1


select previous_object_id,next_object_id,link_type_id, count (1)
from dss_links
group by previous_object_id,next_object_id,link_type_id
having count(1) > 1


If you find the corruption then please run the below queries on central in same order:

update dss_links
set previous_object_id = -previous_object_id;


insert into dss_links (previous_object_id, next_object_id, link_type_id)
select distinct -previous_object_id, next_object_id, link_type_id
from dss_links;


delete
from dss_links
where previous_object_id < 0;


ii] If the issue still persist, then check the rest-api log for below error, if you find the same then please run the provided corruption removal queries on central :

Log error:

StatementCallback; bad SQL grammar [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]; nested exception is org.postgresql.util.PSQLException: ERROR: more than one row returned by a subquery used as an expression

Queries:

update dss_metric_descriptions
set metric_id = -metric_id
where language = 'ENGLISH';


insert into dss_metric_descriptions (metric_id,description_type_id,language,metric_description)
select -metric_id,description_type_id,min(language),metric_description
from dss_metric_descriptions
where language = 'ENGLISH'
group by metric_id,description_type_id,metric_description;


delete from dss_metric_descriptions
where language = 'ENGLISH'
and metric_id < 0;


CASE-6:

If the above steps did not help then, issue can be due to the fact that DB host name is not resolving to IP address properly. So you can confirm this by changing host name
in context.xml file of your war to IP address of that host followed by restarting tomcat instance.


The impact of the Solution

The impact of the solution on the analysis or the dashboard is: The user will be able to login into the dashboard and will be able to work on it.


Notes/comments

Related Pages


  • No labels