Title: CA Clarity Tuesday Tip: Time Slicing 101 - Part 2
CA Clarity Tuesday Tip by Shawn Moore, Sr. Principal Support Engineer for 5/10/2011
In this post, well look at a more realistic example and how the data goes from the source data (the parent object) to the slicing tables. We'll also start looking at some characteristics of slice tables as well.
So how does that slice get into the slice table?
Let's start by taking a look at an assignment table record example. I picked a record that had 8 hours in the practsum field. (the values in the practsum fields are multiplied by 3600 within the database, so 8 hours would show up as 28800) The practsum represents the sum of the actuals for the blob belonging to that assignment.
Any time an update is made against this assignment, the slice_status field will be marked with a 1. A value of 1 means the object (the assignment) has been marked for reslicing.
In Clarity if the assignment was updated (i.e. typically from posting or some activity from a scheduler), the slice status would be set by the application. For the sake of this discussion, we will manually force the value using the following update:
update prassignment set slice_status = 1 where prid = 5054447
Now that the assignment has been marked for reslicing, nothing will happen until the time slicing job runs. When time slicing runs it will process each parent object and perform all the slicing for that object. Since we have marked an assignment, the time slicing logic will reslice the data associated with an assignment (i.e. ETC, Actuals) for each of the requests defined in the PRJ_BLB_SLICEREQUESTS table. (Keep in mind a request is just a definition of how Clarity should represent the sliced data. i.e. we could define the request as representing the assignment data, sliced by week, starting on May 5th, 2011 for 52 weeks)
Slicing activity will show up in the bg-niku.log as the bg server identifying what type of object based on a certain update. (In this case assignments were modified.) After identifying the statement used to find records for processing, Clarity will insert new slice values in batches of 1000.
i.e.
DEBUG 2011-05-10 15:24:23,827 [Dispatch Thread-18 : bg@myserver] niku.xql2 (none:none:none) PMD statementSetDescriptor: blobcrack.modifyAssignment_set
DEBUG 2011-05-10 15:24:24,202 [Dispatch Thread-18 : bg@myserver] niku.xql2 (none:none:none) PMDRecordSet.singleRecordSet returned page # 0 page size 1000 total rows 1000
In our example, we can look at the prj_blb_slices table to view some of the slices created.
i.e.
select id, slice_request_id, prj_object_id, slice_date, slice from prj_blb_slices where prj_object_id = 5054447
The SQL query result would be:
ID SLICE_REQUEST_ID PRJ_OBJECT_ID SLICE_DATE SLICE
------------------------------------------------------------------------------
49650925
2
5054447
2010-MAR-03 00:00:00 8
The fields are defined as follows:
ID: This is the unique identifier for the record
SLICE_REQUEST_ID: This ID corresponds to the ID of the request defined in the PRJ_BLB_SLICEREQUESTS table. This is the same data displayed on the UI in the slice definitions page.
PRJ_OBJECT_ID: This ID represents the ID of the parent object that was sliced. Since this slice record was an assignment slice (SLICE_REQUEST_ID = 2), this would be the PRID of the record in the PRAssignment table.
SLICE_DATE: This is the date the slice value or the "point" in the curve.
SLICE: This is the actual value in hours.
So for this example there were 8 hours tracked on March 3rd 2010, on the PRAssignment.prid of 5054447.
Next week, we'll cover more on Time Slicing.
-shawn