[email protected] wrote on 07/25/2012 12:34:18 PM: > From: Daniel Berg/Raleigh/IBM@IBMUS > > The main reason for the separation of input and output parameters > was to provide an indication that the Automation Plan may "set" a > parameter that can be used in downstream activities which was not > and should not be included as an input the the request.
As-is, the spec doesn't support this. And, if this was the real intention all along, I think it got lost somewhere along the way. I'm actually not aware of any would-be automation providers that support this concept today. You can certainly get a final set of parameter values from some of them, but, again, I don't know of any that actually let you formally define the ones that are "officially" set at the end. It's a good forward looking concept, and one that I'd actually looked at adding to a home-grown automation solution I developed years ago (never got implemented there either, <grin>). > In my opinion the use case to check for changed input values is not > a common case. Agreed. > The suggestion to have all parameters defined in the output which > includes both input and output is fine as long as within the > AutomationPlan it is possible to distinguish between input parameter > definitions and output parameter definitions. More specifically I > need to know which parameters can be set by the user (required or > optional) and which ones will have a value supplied during the > execution of the plan (cannot be entered as an input parameter > value). Looking at the speck I don't believe we can make this > distinction based on the current definition of the > parameterDefinition on an AutomationPlan. > > Am I missing something? The input/output parameter distinction at the moment is only captured on the AutomationResult. The (or at least my) initial thought was that people might be interested to see what the original set of values passed into the automation were, particularly if the AutomationRequest was no longer available. So, inputParameters (on the AutomationResult) was added so that this information was available. Then, there was the need to know what the current set of all visible parameters and their values were. This is what we ended up putting in outputParameter, except it seems to have gotten morphed such that it was only supplying values that were changed. I'm suggesting that the set of outputParameters should be the complete set of parameters, regardless of whether they have changed. Any of that help clarify things? Charles Rankin
