Yes, the steps you wrote are correct. By the way, it seems you are still working on the "old" Views, since the new ones based on TrueSight console do not have this problem.
I strongly recommend to evaluate the migration of your custom views in TrueSight console. Beginning in version 10.7.00, you can use a better and simplified workflow in the TrueSight console for custom-view creation and management. See also:
- 11.0.00 enhancements - Documentation for BMC TrueSight Capacity Optimization 11.0 - BMC Documentation
- It's time to migrate your views! Catch the View Migration Toolkit and go!
Gaspare, Yes we're waiting on the completion of specific RFEs that would allow us to move to version 11. This could take serveral months.
Btw, I've already tried the above steps on the user's desktop. But she continues to have these parameters stuck. tried clear chache on Firefox, as well as tried IE. Still the same problem. What else can we do? Same view works fine on my desktop, as well as serveral others.
the root cause why the parameters continue to be wrong in that custom View should be investigated - most probably the configuration of one filter portlet is wrong and sets values in the wrong Page Parameter.
Page Parameters cannot be cleaned up by simply cleaning browser cookies or cache, because Page Parameter values in 10.7.01 are stored in the database and persisted to be available also after a user logout.
So I can propose two solutions to help you.
Solution (1) - Use a permanent link to cleanup the filters for current user
To clean up the filters for the currently logged user, use a link like this one in the browser:
Where you have to replace https://TSCOHOST:8443 with your actual TSCO host and port, 1046 with the ID of your custom View (you can query DB table DASHBOARD to obtain the ID from column DASHBOARDID) and 5 is the fifth page of your custom View, in this example (you can replace it as needed: you can use the Page Parameters portlet once to know all page numbers of you can try with 1, 2, 3 and so on. For more info see: Re: Custom Views: Access a Page Parameter from a different page ).
This will clear all the Page Parameters for the specified View and page for the current user. This removes also Page Parameters as "Community" scope for that View.
Solution (2) - Clean up filters for ALL users and ALL pages for a specific View, by removing filters from DB
This is more tricky and requires the Capacity Optimization restart.
1) Identify the custom View for which you need to clean up the filters and take the EXTERNALID column. Use for example this DB query:
SELECT externalid FROM DASHBOARD WHERE name = 'My Custom View'
This will return a number like 14326
2) Stop Capacity Optimization web component (./cpit stop web)
3) Delete from DB table dash_user_filter all entries that match the external ID found at point 1. So, assuming the externalid is 14326, you can execute:
DELETE FROM DASH_USER_FILTER WHERE name LIKE '14326:%' OR name LIKE '14326/%'; COMMIT;
4) Start TSCO web console (./cpit start web)
Note: values for columns DASHBOARDID to be used for solution (1) and EXTERNALID to be used in solution (2) are different, so be careful to use the right ID according to the solution you want to adopt.
Hope it helps,
1 of 1 people found this helpful
The number that is reported in the Page Parameter Portlet is the EXTERNALID for the page. The URL is Solution 1 requires the DASHBOARDID to be specified.
You can translate the "External ID" reported by the Page Parameter Portlet into the Dashboard ID via the following SQL run as the TSCO Database Schema Owner (BCO_OWN by default):
SELECT DASHBOARDID FROM DASHBOARD WHERE EXTERNALID LIKE '%1234567%';
Where 1234567 is the External ID of the page as reported by the Page Parameter Portlet.
The Dashboard ID returned by that query can then be used when you construct the URL.
I suggest to write the following query to retrieve all the IDs for the old custom Capacity Optimization Views (you can create a SQL Data Mart in Capacity Optimization for that):
SELECT NAME, DASHBOARDID, EXTERNALID FROM DASHBOARD WHERE DASHBOARDID >= 1000 AND TYPE IS NULL ORDER BY NAME
This returns a list like:
NAME DASHBOARDID EXTERNALID My Custom View 1 1001 10678 My Custom View 2 1002 10890 My Custom View 3 1008 10998
Use DASHBOARDID values for solution 1, EXTERNALID values for solution 2.
do you need any further help on this?
Please let me know,
This is helpful. Thanks. Need to find a way to prevent the issue to begin with.
1 of 1 people found this helpful
I suggest to use the Page Parameters portlet to debug which portlet is causing the wrong behavior.
So you should:
1) add the Page Parameters portlet in all pages of your View
2) use your custom View
3) As soon as you "break" your View, check in the Page Parameters portlet, under "All" tab, the values of all the parameters visible in the page. Check both Community Value and Page Values. Please remember that in case both Community Value and Page Value exist for a certain parameter, the Page values (more specific) are the one read by the portlets of that page. Sometimes you will need to refresh the Page Parameters portlet to see updated values.
I think the issue in your custom View is most probably due to a portlet that was configured to write the wrong value for a certain parameter.
A typical error is to configure a table to write in the "System" parameter the value taken from the "System Name" column instead of the "System ID" column.
Hope it helps,