Troubleshooting

Empty or partially empty dashboard

When a dashboard is empty or partially empty, there are several possible reasons. To find the cause, you need to proceed step by step.

Check the elasticube

From the dashboard, go to the elasticubes:

Every Zetaly cube has :

• One main table called "fact table"
• Several tables named "dimension tables"

The fact table contains all the data, when the dimension tables contains the data used to request the main table.

Identify the fact table and explore it:

Sort and filter the table to find your data. If your data are present, it's a dashboard or dimension issue (see /v1/docs/troubleshootings#check-the-dimension-bifilter). If not, it's coming from the data loading (see /v1/docs/troubleshootings#check-view-data).

Check the dimension BiFilter

Most dimensions are simply an extraction from the fact table. If the dashboard is a Zetaly one, it can contains the table "Dim_BiFilter". If not, see /v1/docs/troubleshootings#check-the-dashboard.

When the dimension BiFilter is not properly initialized, the link between the dimension and the fact table can "hide" data in the dashboard. To verify the table, eplore the dimension. You should found some records. If not, you need to initialize the custom filter.
Go to Zetaly portal and log as administrator. Go to custom filters:

Go to datacenters and use the following button:

It should create your infrastucture.

If you already have some data or if it was not enough, you need to check data linked between the fact table and the dimension.

Go to the elasticube and check the relation between the two tables:

Using this example, we can see that the two table are linked using the "sid" column.

Explore each table and check if you have the same data.

Check the dashboard

If your cube analysis shows no error and all data is present, then you need to check that there are no parasitic filters in your dashboard. Go to the dashboard and open the filters panel

Disable every filters and check if your dashboard has data. If yes, enable filters one by one. When one of the filters hides data, check the filter and its purpose. If it's useless, delete it.
If there is no data or if you do not understand why a filter hides data, please contact the Zetaly support with the following elements:

• A screenshot of the dashboard with filters applied.
• A screenshot of the first rows of the main cube table (complete rows) and the statistics tab.
• If present, a screenshot of data from the "bi_filter" table
• An export of the cube model and a dashboard export.
• All your analyse

Check view data

If the cube doesn't contain the desired data, you'll need to check its presence in the Zetaly database.

In the cube, check the query used for the fact table. It can be accessed via the following menu:

Copy the request (it should be a simple SELECT).

Next, access to the Zetaly database and execute the request. If you're looking for specific data, you'll need to modify it accordingly. For example, the request:

SELECT * FROM "public"."fact_cics_activity_sample";

Becomes:

SELECT * FROM "public"."fact_cics_activity_sample" ORDER BY start_time DESC LIMIT 100;

If we have desired data, then it's a cube build problem. See /v1/docs/troubleshootings#check-the-cube-behavior.
If there's nothing, we'll check the database views and tables. See /v1/docs/troubleshootings#check-the-entire-database.

Check the cube behavior

In the cube, check the build behavior and the latest logs. If the builds are incremental, try a replace all build. If data appears, it's a problem of incremental management configuration. In which case, export the cube model and provide us with your complete analysis.

Check the entire database

The following actions are to be performed "in a loop" until a table is reached.

From the previous query, retrieve the table or view being queried. For example, for:

SELECT * FROM "public". "fact_cics_activity_sample";

The view is "public". "fact_cics_activity_sample".

Execute the following request (Be careful with spaces, case and keep quotation marks):

SELECT pg_get_viewdef('"fact_cics_activity_sample"’, TRUE);

There is several possible cases depending on the result:

• A SELECT request using another table/view without the use of a procedure.
• SELECT query using the "zc_gettablewithapplication" procedure
• No result

Example of the first case:

SELECT to_date(to_char("FACT_cicsHistApplication"."startTime", 'YYYY/MM/DD'::text), 'YYYY/MM/DD'::text) AS start_time,
        …
FROM "FACT_cicsHistApplication"
GROUP BY (to_char("FACT_cicsHistApplication"."startTime", 'YYYY/MM/DD'::text)), …;

Example of the second case:

SELECT res.scope,
    res."startTime",
    …
FROM zc_gettablewithapplication('cicsHist'::character varying, '(scope IN (0, 10, 12, 2)) AND (endTime >= CURRENT_DATE - INTERVAL ''7 day'')'::character varying) res(scope smallint, "startTime" timestamp without time zone,…);

If the first case, take the "FROM" clause and repeat the previous steps with this new table/view.
If the second case, then take the first argument of the procedure ("cicsHist" in the previous case) and repeat the previous steps.
If the third case, then we're on a table, proceed to the next step.

Execute a SELECT request on the resulting table to look for your data.

If you have results, then data are present, but filtered by views, see /v1/docs/troubleshootings#analyse-views.
Otherwise, no data is collected, see /v1/docs/troubleshootings#collecting-data.

Analyse views

Several cases are possible:

• Either the data is filtered, as only part of the data is used for the dashboard
• Or a filter is applied based on the age of the data.

Take your results from step "Check the entire database" (or redo them). For each view, make a "SELECT" query as seen above, and identify the view for which the data is "disappearing".
Once the view has been identified, check whether the "WHERE" clause contains a date filter. For example « endTime >= CURRENT_DATE - INTERVAL ''7 day'' ».
If this is the case, then it is possible that this limitation is a problem for the loading of your data, you need to modify the view, go to point TODO.
If not, check the other "WHERE" clauses. These clauses normally have a functional meaning and will explain why data is missing (see Data Collection Summary). If you don't understand the reason for the filter, please contact us with the complete results of your analysis.

Update view

It's not advisable to modify dashboards, cubes and views directly. If you wish to modify a view, then :

• Make a clone of the view to be modified with your modification, as well as of all "superior" views
• Create a cube clone and point to the equivalent of the previous view
• Create a clone of the dashboard and point to the previous cube

For example, if I have the following case:

zc_si.a.o_CICS_Activity_sample (dashboard) =>zc_si.a.e_CICS_Activity_sample (cube) => fact_cics_activity_sample (view) => FACT_cicsHistApplication (view)

I need to modify the last view by changing the date, so I get this:

zc_si.a.o_CICS_Activity_sample_clone (dashboard) => zc_si.a.e_CICS_Activity_sample_clone (cube) => fact_cics_activity_sample_clone (view) > FACT_cicsHistApplication_updatedClone (view)

Collecting data

If there is no data in the original table, it's a data loading problem. In this case, check that data is being harvested. On the LPAR, check that the option to harvest the desired SMF has been activated (see Data Collection Summary). If this is the case, then check in ZSA that data collection is actually taking place (see Monitoring).
If you have any problems here, please contact us with your analysis.