CA PPM: How Should I Configure My Time Slices?

Document ID : KB000027257
Last Modified Date : 21/06/2018
Show Technical Document Details
Introduction:

We want to know if there are any best practices in configuring our Time Slices page.
 

Background:

 

 

 

Instructions:

Based on the amount of data and the reporting needs of each implementation, the time slices need to be configured properly.

Make sure the environment performs optimally by ensuring the time slice definitions are set as follows:

1. Configure the following DAILY time slice IDs:

The idea is to limit the number of DAILY slice records.This will create fewer records for reporting historical data within the recommended configurations.

Note: If you need past historical data to be sliced for dates further back than what is recommended above, it is recommended to consult our CA Services team for advice on alternative configurations OR use monthly time slices.

Make sure there are not any daily slice definitions that cover a range of over 2 years, especially the team slices.

A. Estimates (1 year range)

DAILYRESOURCEESTCURVE

From Date = Start of the current month (There is no need to slice estimates far in the past)

Number of periods = 400 days

B. Actuals (2-year range)

DAILYRESOURCEACTCURVE

From Date = Start of the current month, going back 1 year

Number of periods = 740 days

C. Baseline (2-year range)

DAILYRESOURCEBASECURVE

From Date = Start of the current month, going back 1 year

Number of periods = 740 days

D. Availability (2-year range)

DAILYRESOURCEAVAILCURVE

From Date = Start of the current month, going back 1 year

Number of periods = 740 days

Note: When a Resource has a Hire Date and/or Termination Date, the Availability slices are bound for the resource within this date range.

E. Allocation (2-year range)

DAILYRESOURCEALLOCCURVE

From Date = Start of the current month, going back 1 year

Number of periods = 740 days

If you are not maintaining allocation at the Project level company wide, you may have no need to maintain slice data for allocation. This is by far the largest portion of slice data, and if it is not entirely valid it can be dramatically reduced. We recommend that if you do not set project level allocation you should set the Number of Periods to four (4) for Allocation slice request. This will minimize the amount of data that is being stored for Allocation slices and also populate in the Datamart tables.

If you are truly using this allocation data it should also be in the same range as Baseline and Availability Time Slice definitions. We recommend that you enforce setting project allocations company wide and be sure to properly zero out any remaining/unused allocations. If allocations are set properly on active projects only valid data will be stored in timeslice therefore dramatically reducing the amount of records needed to maintain allocations.

We also recommend that you zero out "Remaining Allocation", as seen on the Project Roster/Team page, for inactive/closed projects. To zero out the resources "Remaining Allocation", we recommend that you set the allocation finish date to the last date the resource worked on the project. "Remaining Allocation" takes into account the last date the actuals were tracked by the resource. This date should be set as the allocation finish date if the resource is no longer working on the project. Zeroing out any unnecessary Remaining Allocation will reduce the amount of data stored in timeslice, and make your data more realistic. The easiest way, although less accurate way to release unused resource allocation, is to ensure ETC is zero and then click "Allocate From Estimates" button on the Roster/Team page. This method of using the "Allocate from Estimates" button for resource with zero ETC is provided as a quick and easy method to zero out allocation. If this doesn't meet your specific needs, use the recommended method, stated above, because it more closely reflects reality.
 

2. Configure the following FISCAL time slice IDs:

A 7-year range is acceptable.

From Date = Start of the current month, going back 1 year

Number of periods = 72 months

3. Once the changes are made and saved, resume or unpause the Time Slicing job to allow it to regenerate the data.

Additional Information:

Frequently Asked Questions:

Q. Why do deadlock errors occur in the bg-ca.logs?

The following:

Error processing slices com.niku.union.persistence.PersistenceDeadlockException:
SQL error code: 60
Error message: [CA Clarity][Oracle JDBC Driver][Oracle]ORA-00060: deadlock detected while waiting for resource

is caused when there is large amount of XOG activity that takes place while the Time Slicing job is running.

It is best to pause the Time Slicing job or set the process calling XOG, as there is such large amount of XOG activity that needs to be processed by the Time Slicing job, which is typically set to run every minute.

The failure is not critical, as the job will recover and process the records the next time it runs.