I have noticed a very annoying thing: when one of the TI's in the chore has a parameter and you forget to set a default value (silly me), then the chore errors out and an error a Temp log file gets created for the failed process...like TM1ProcessError_processname.log$. Annoying thing is that the file "hangs" (hence $ indicates that) and you cant delete it until you re kick the server.
While solution is obvious - don't forget to set the parameter... I just find it to be rather irritating error-handling procedure....
I agree, it's annoying (although I never ran into that situation of erroring out).
My preference is to have 1 TI process that kicks off other TI processes.
The first TI could be scheduled in a chore, but I dislike having say 15 TI's in 1 chore, all with similar parameter values (scenario, year, period, ...)
Possibly, store the parameter values in a cube and get them from there.
My 2莽.
I know there are several work-arounds, but from error-handling perspective its very annoying and not intuitive at all, plus you cant open the error log since its a corrupted $ file
Basically trial and error, approach here...
Perhaps its been fixed in 10.2, but I havent looked at bug fixes list as yet or tested new version.
I must confess to having wondered about this thread, because I know that in 9.0 SP3 U9 I couldn't create one without a default either, though I haven't tried in 9.5.2. Which means that it was presumably something that was broken between 9.0 and 10.1, then fixed again in 10.2. That is, until it gets broken again.
Curiously just recently I was reading a process with the API (one of the Iboglix-defined processes in one of the sample databases, no less) and it spat the dummy when reading the parameter defaults. Instead of a string the value capsule held an error value telling me that the parameter wasn't defined. So it's not just end users who forget...
my 2c this is a ridiculous inconsistency between various interfaces
ExecuteProcess needs named parameters and doesn't care about parameters that aren't passed and assumes the default value in this case. Values passed and default values can be empty strings.
Chores require an entry for each parameter, the parameter value can't be an empty string even if this is the default value.
Tools connecting vie the API (RunTI, ProcessExecute, Cubeware IMRUN, etc.) require a parameter array with the correct number of params for the process, each param requires a value but values can be empty.
IMO the approach with chores is wrong. Be consistent with either ExecuteProcess and take the default if the value is empty or allow a null value.
|手机版|小黑屋|企业绩效管理网
( 京ICP备14007298号 ) 
发表于 2014-3-16 23:45:58
