Has anyone tried to update the Roll Over interval on DAILYRESOURCEAVAIL time slice request. ( slice_request_id=1 ). If you have tried, what are the impacts ? Did it work consistently?
Purpose of the request - To be able to set the time slice request roll over on weekends instead of a monthly (determined by from_date). So we are planning to set the From date to a Saturday , and update the Roll Over = Monthly to Weekly ( This is not possible currently in the UI ). Time periods is set to 730 and slice = Daily.
Please check/update below stored procedures in clarity schema..
Please try altering above procedures in dev first..
Just thinking aloud
So that would do the rollover of that particular rollover 4 - 5 times a month instead of once.
I guess that would be OK if it were off peak hours which is what you are after, and on coinciding with the rollover of other slices.
Should something go wrong it is 4 -5 more likely to happen.
You could try calculate how many slices are involved.
I'd also be concerned with the allocation slices which can have a high number of records.
The daily availability is not really system but OiOTB and changing the definition is possible in the GUI in supported manner.
People have been changing the number of periods all the time.
Changing the rollover should just change what data is he available and when (inconsistent during slicing, but not a problem if it is off peak hours.) but otherwise it is business as usual.
On the other hand....
Clearing the expiry date will cause regeneration of the slices. Just wondering if manually or with a process setting it to a weekend date will will cause renegeration or just change the expiry date. If it just did the latter would that be an option or you.
It's not possible to set the roll over period in the UI for DAILYRESOURCEAVAILCURVE
Thanks for the Time slice record estimator excel. It's an excellent to guage time slicing data and helps in db sizing.
If I recall correctly (haven't done much slicing lately) -
A rollover doesn't regenerate slices, but removes 'expired' slices and adds new ones to fill the range. Please don't quote me on that, you can do a test to see if records do get deleted and recreated - just watch the created date on prj_blb_slices.
The Expiration Date can be set from the UI but the system resets it during rollover. This would mean that any manual intervention will have to occur every week to force the rollover to a date that you want.
-Connie (as a time slice user)
We don't want to reset the expiration date manually, instead modify the Roll over interval from monthly to weekly.
"The Expiration Date can be set from the UI but the system resets it during rollover. This would mean that any manual intervention will have to occur every week to force the rollover to a date that you want."
If you set the manually the expiry date will the result be the same as if you clear it and save the slice definition?
The expiration date is set by the system. It sets it to the next time the roll over would happen
I am not disagreeing with that, but is a user editable field so if the user so wishes he or she can write there something -eg something that skips a rollover or two.
Just wondering what will happen in such a case.
Clearing the field the way to reset the definition and to force regeneration of the slice records for that definition.
The system would override it, I guess
You can check and let us know as well
Rollover interval = Monthly and it's disabled. What happens if that is changed to Weekly in the backend ? The purpose being to tell the system to slice on a weekend instead of a nth day of the month every month. nth day in a month could fall on any weekday and it becomes extremely troublesome if time slicing does not complete and runs into business hours. This is going to impact Report generation , interfaces depending on time slices and so on. I am also thinking a good idea would be introduce relative dates in time slice settings. For eg. First Saturday of the month.
So you're looking to do two things:
to change the rollover interval from monthly to weekly
to set the expiration date to be a weekend date - by default weekly rollover starts at 0 hour on Mondays
#1 is 'use at your own risk', #2 is not a one time change (this should be tested and confirmed if you would like. take a test server, find a slice request, shrink the number of periods in the slice definition, set exp date to be tomorrow so that rollover will occur, check tomorrow what the new exp date is set to once rollover is done). When changing the rollover interval, you would also want to consider how much weekly rollovers the system is already doing so as not to over burden the system on Monday early mornings.
I think the ability to set expiration date using a relative date is an awesome idea! And I don't see why you can't request for the interval to be open for edit. I'd vote for it if you enter the idea!!
"find a slice request" -> i meant to say 'find a daily slice request'
There are some practical examples athttps://communities.ca.com/message/90177329#90177329
Agreed that you cannot change the rollover period in the GUI which means there is no supported way of doing that.
If you open the definition view of a timeslice
- the expiry date is automatically cleared
- a user entered valued is overwritten by the expiry value calculated by the system
For weekly rollover the expiry date is seven days later from the current date
For monthly rollover the expiry date is at the start of the next full slice period,
if the slices start the 1st of the month then the expiry is the next 1st of a month
if the slices start the 15th of the month then the expiry is the next 15th of a month
- the rollover period is editable for custom slices but not for system slices
- changing the rollover period in the database has the same effect as changing it in the GUI
that is the slices do not change only the expirydate in the prj_blb_slicerequests table
- the expiry date is not automatically cleared
For weekly rollover the expiry date is the next day
In both versions you can delete the custom timeslice definitions
Just wondering if you are going to mess with the database would changing the value of the field is_system for dailyresourceavailcurve from 1 to 0 change the rollover period to editable in the GUI??
Is that any less risky?
You are right. is_system = 0 makes the Roll Over field editable in UI. It could be less risky now.
Why don't you open a case with support and propose that. Then you'll expert opinions.