Call Operation with Dynamic Options

[jharbison]

Is it possible to somehow call an operation with optional parameters without specifying the optional parameter names explicitly? Ideally I would like to be able to call an operation and pass in a map that contains the parameters. This would allow me to do something like the following where in reality %configuration is read in from an application variable that the user has access to change.

set %configuration = %{To: somebody, Subject: something important, Text: some text};
call Send-Email(%configuration);

Instead I have to know all optional parameters that might be set ahead of time resulting in something like

set set %configuration = %{To: somebody, Subject: something important, Text: some text};
call Send-Email(
To: $MapItem(%configuration, To),
Subject: $MapItem(%configuration, Subject),
Text: $MapItem(%configuration, Text)
);

This is fine for simple operations but when dealing with something like IIS::Ensure-AppPool that has over 40 parameters it quickly gets out of hand when different users need to specify a different subset of parameters. Currently all users need to specify all parameters with defaults even if they specifically only care about a couple.

Product: BuildMaster
Version: 5.6.8

[Guest]

Josh, this is an interesting use case, we haven't quite considered it. After discussing it a bit on our team, here's our idea:

Invoke-Operation
(
  Name: Send-Email,
  Arguments: %(To: somebody, Subject: something important, Text: some text)
);

Invoke-Operation ( Name: $OpName, Arguments: %OpArgs );

Basically, it's an operation that invokes another operation. It's relatively easy to implement, and is something we would do in a maintence release.

We definitely welcome your feedback.

[Guest]

An operation like that would be perfect. I had tried something along the same lines by constructing a string with the same structure as an operation call and using $Eval before noticing in the documentation that $Eval is only for variables and functions. This operation would fill that void.

[Guest]

This has been added as BM-3004, and is currently scheduled for 5.6.10.