ExecuteProcess with too few parameters supplied

[Wim Gielis]

Hello all

- If you attempt to use the function ExecuteProcess() and you specify too many parameters, an error is generated.
- If you attempt to use the function ExecuteProcess() and you specify the correct number of parameters, but you have a typo in a parameter name, an error is generated. Good.
- If you attempt to use the function ExecuteProcess() and you specify too few parameters, NO error is generated.
The called process runs and uses the parameter values that it can find. The Message log shows INFO instead of ERROR.

What do you think? Is this good or bad? Do you make use of the fact that you don't need to supply all the parameter values?

Wim

[EvgenyT]

Hi Wim,

Good point... I think it should be consistent across every scenario.

I find error messages for ExecuteProcess quite vague to be honest... Process couldn't initialize makes sense if you know TM1 well, but if you are rather new then you would be scratching your head for a while, thinking what's gone wrong.

Do you agree?

ET

[Martin Ryan]

What does it do with the parameters not specified? If it uses the Default values specified when building the TI process then I don't think it's necessarily a bad thing. It makes the variables optional, like in VBA where you don't have to supply things if you just want the defaults to apply.

However if the defaults are not used and it just uses empty string for string parameters or 0 for numeric parameters then I'd go with "Bad".

[rmackenzie]

What does it do with the parameters not specified?

I'm pretty sure it picks up the defaults.

[lotsaram]

I'm also positive that ExecuteProcess picks up default values for any non-specified parameters. It may not be consistent with API external calls or RunTI.exe (or the chore scheduler for that matter which requires an explicit value for all parameters and ignores the defaults!) but I guess chalk it up to an advantage of using the internal TI function as opposed to those methods.

[Harvey]

I think this behaviour is correct. You can't specify parameters that don't exist, so 1 and 2 are definitely an error.

Omitting parameters is the only way to indicate to the ExecuteProcess command that you would like to use the defaults, so if that caused an error it would be very annoying.

Having written detailed TI libraries, I use that feature frequently, and need it to be available to users of my library. If they had to specify every parameter every time, it would get unwieldy. This would probably tilt my design toward minimizing parameters instead of maximizing features and flexibility.

[Wim Gielis]

Thank you for your comments!

[Darkhorse]

I think this behaviour is correct. You can't specify parameters that don't exist, so 1 and 2 are definitely an error.

Omitting parameters is the only way to indicate to the ExecuteProcess command that you would like to use the defaults, so if that caused an error it would be very annoying.

Having written detailed TI libraries, I use that feature frequently, and need it to be available to users of my library. If they had to specify every parameter every time, it would get unwieldy. This would probably tilt my design toward minimizing parameters instead of maximizing features and flexibility.

Could you not right the, as static variables within the prologue rather than use parameters that can be altered if ran by the user?

I too feel the lack of warning when not specifying all is annoying it only takes one mistake to mess up a huge amount of data and these are the easiest ones to make.

[dwigsy]

I used to think that you would need to supply all of the parameters too until I discovered this recently. I think its useful to have the ability to use default values and override only those which you need.

[Harvey]

Could you not right the, as static variables within the prologue rather than use parameters that can be altered if ran by the user?

The whole point of a library is to allow the user to alter the parameters, so that's not an issue. Note that these are reusable modular TI processes intended for the most part to be called from other processes. They are not likely to be run directly by end users.

I did at one point have a cube that provided default parameter and other values that could be changed, but I designed it such that, if the cube didn't exist, the TIs would still function with static defaults. I haven't found it worth the overhead for deployment to include the cube so far.

[jstrygner]

Bringing up a bit older thread but found no comment about a thing I think is crucial.

I also think taking defaults in case parameter is not specifically called is a good practice.
Of course you need to be aware changing defaults may cause a bit mess.

But this becomes crucial if for any reason you decide to introduce new parameter to the TI that is called from other processes.
This new parameter is usually set by default to an option that would not change anything in the sub-process so-far behavior and this will make any other "caller" processes to work without issues which I would see as desired.

I think a very nice example is introducing Bedrock 2.0 processes that sometimes take advantage of this behavior.

[java_to_tm1]

I LOVE this behavior in TM1 Execute Process.
Without this, I would never EVER add a new parameter to an existing process. The list of places (Cognos Insight button, Excel worksheets action buttons, other TI processes, command line batch files in 10.2) from where processes could be called is endless.
Finding (and then fixing) every one of these a logisitcal nightmare (for both developemnt and testing).

If IBM ever changes this behavior of ExecuteProcess, I'll remove all parameters from all Processes and simply pull these parameters from a cube.

[iansdigby]

I LOVE this behavior in TM1 Execute Process.
Without this, I would never EVER add a new parameter to an existing process. The list of places (Cognos Insight button, Excel worksheets action buttons, other TI processes, command line batch files in 10.2) from where processes could be called is endless.
Finding (and then fixing) every one of these a logisitcal nightmare (for both developemnt and testing).

If IBM ever changes this behavior of ExecuteProcess, I'll remove all parameters from all Processes and simply pull these parameters from a cube.

I thoroughly agree with this.