Dear Community Members,
In this week's Learn PPM with Rego, we'll explore five CA PPM questions and answers.
1. Is there a known issue in CA PPM 14.2, when including Attributes in the Data Warehouse (DWH)?
2. For tracking interface changes, should we use Custom Object instead of OOB Auditing?
3. What might cause a duplicated Project in a List View?
4. Anyone having trouble using a full sync to update a username in the Jasperserver?
5. Can we post future transactions to the WIP?
Please feel free to comment on any alternative answers you've found. We love your input (always).
1. Is there a known issue in CA PPM 14.2, when including Attributes in the Data Warehouse?
Yes. If you added attributes from your object properties' main page, with the checkbox on the side, your attributes may not be included . . . even if the UI is showing the attributes are included in the DWH.
Answer 1
To work around this issue, go into each attribute's properties > uncheck Include in Data Warehouse > Save & Return.
Now, go back into the same attribute's properties > check Include in Data Warehouse > Save & Return.
Answer 2
You can also check the CA PPM database (dwh_meta_columns table) to see if the is_deleted flag is set to ‘1’ for each attribute. We also suggest resetting the is_deleted to ‘0’ via the UI.
select * from dwh_meta_columns where is_deleted = '1'
NOTE
You MUST run a full load on the Data Warehouse each time attributes are included or excluded.
Typically we don't suggest using Custom Object unless you can't use the OOB audit information. This might occur in scenarios such as the following:
1. To track information on who approved action items and when.
2. To cater to and track a complex portlet requirement displaying audit information.
If you use Custom Object, you must create a purge strategy that includes anticipating how much data (and at what level) the custom object holds, to determine how many days of data it would hold.
3. What might cause a duplicated Project in a List View? There's only one DB entry for the investment, and all changes made to one reflect in the other.
Check for duplicated baselines, as in the screenshot below.
If two baselines are marked as current for a project in the prj_baseline_details table, it can trigger a duplicate record in the ev history table because the project list joins the details table.
Going into one of the records and saving a change appears to correct the issue. (In the screenshot below a period is added to the revised name.) We also verified the duplicate was removed from the project list view and prj_ev_history table.
4. Anyone having trouble using a full sync (Load Users / Access Rights) to update a username in Jasperserver? It's making it difficult to implement security in the query going against the transactional DB.
Answer 1 | On Premise Environments
To workaround this issue, try removing records from the table. Synchronized users' internal IDs are stored in CMN_JASPER_SYNCED_USERS.
We also recommend using the cmn_jasper_synced_users table to get the user id, based on the username in Jaspersoft, and then proceeding with the security check.
5. Why can't we check a manual transaction entry for non-labor actuals, and then post it to WIP? Are future transactions dates eligible?
Many people think it's impossible to post future transactions to the WIP. By default, after you hit Apply, the filter refuses to bring them in.
But if you supply the filter with a future date range and then hit apply, it will pull in the transactions. This is one of the quirky things about the old financial filter architecture.
For the record, we don't recommend posting actuals in the future.
Feel free to share your feedback and thanks for participating.
Your guide,
The Rego Team