Programmatic control over Chore execution frequency
Posted: Tue Mar 18, 2014 10:26 pm
Hi,
(Apologies for providing background on this again, two different enhancement requests arising from the same use case)
I'd like to be able to conditionally turn chores on and off and also manage the execution frequency from within a TI job. (actually I'd be happy to be able just turn them on and off but lets shoot for the whole piece!)
We are using PI to export and load data using 20 chores that are scheduled to run every 30 seconds. These chores only do work around 8 times a day when a master TI interacts with a schedule cube and sets various flags that indicate to the chores that there is work to do. This works v well and we are able to rapidly process data and minimise the read lock when loading data into the cube. We have not been able to note a performance down side to having the chores set-up like this.
There probably is one though, its just that TM1Top doesn't work in granular enough time for us to see the chores flicking on and off continuously.
As noted the high volume of logging this generates causes a problem (http://www.tm1forum.com/viewtopic.php?f=19&t=10156).
If we could turn the chores on in the master TI that signals that there is work to do this would solve a couple of problems.
1. Stop all the noise in the logs.
2. More importantly I think it would remove peoples nervousness around using chore driven PI TI execution and remove the need to go outside of TM1 to get to PI TI as they would have the fine control required.
Requests for programmatic access to chore settings have been bouncing around for a while now, especially from those who work across multiple time zones with daylight savings. Whilst this can be a big pain and lead to some dramatic issues if you don't remember to reschedule everything, I think that enabling easy access to PI really ought to raise the profile of this feature. PI TIs can be a real game changer but are currently challenging to implement.
Many places I have worked at, including my current employers, just won't consider introducing third party tools onto the hardware or giving developers access to the hardware. We have to use a chores.
Cheers,
Steve
(Apologies for providing background on this again, two different enhancement requests arising from the same use case)
I'd like to be able to conditionally turn chores on and off and also manage the execution frequency from within a TI job. (actually I'd be happy to be able just turn them on and off but lets shoot for the whole piece!)
We are using PI to export and load data using 20 chores that are scheduled to run every 30 seconds. These chores only do work around 8 times a day when a master TI interacts with a schedule cube and sets various flags that indicate to the chores that there is work to do. This works v well and we are able to rapidly process data and minimise the read lock when loading data into the cube. We have not been able to note a performance down side to having the chores set-up like this.
There probably is one though, its just that TM1Top doesn't work in granular enough time for us to see the chores flicking on and off continuously.
As noted the high volume of logging this generates causes a problem (http://www.tm1forum.com/viewtopic.php?f=19&t=10156).
If we could turn the chores on in the master TI that signals that there is work to do this would solve a couple of problems.
1. Stop all the noise in the logs.
2. More importantly I think it would remove peoples nervousness around using chore driven PI TI execution and remove the need to go outside of TM1 to get to PI TI as they would have the fine control required.
Requests for programmatic access to chore settings have been bouncing around for a while now, especially from those who work across multiple time zones with daylight savings. Whilst this can be a big pain and lead to some dramatic issues if you don't remember to reschedule everything, I think that enabling easy access to PI really ought to raise the profile of this feature. PI TIs can be a real game changer but are currently challenging to implement.
Many places I have worked at, including my current employers, just won't consider introducing third party tools onto the hardware or giving developers access to the hardware. We have to use a chores.
Cheers,
Steve