We all agree that it is important to know from the result what inputs were supplied and having a list of all parameters that were changed or supplied as input is needed.
For Automation Plan it is necessary that a consumer can determine which parameters must be set for execution. I guess it is possible that the parameters that will be set during execution can be defined as a parameter definition that is not required and if the user sets a value during input it is valid for the process to ignore it. I believe this is sufficient for the first release of the spec. Note, we have in the past used Build Forge projects and parsed them to determine the input parameters (defined by variables on the project) and we determined the output files by introspecting the step actions to see where variables were set (i.e., an output). So it is possible but not directly supported as you point out. :) Regards, Daniel Berg STSM, Master Inventor IBM Rational, DevOps Lead 1-919-486-0047 | Cell: 1-919-637-8570 From: Charles Rankin/Austin/IBM To: Daniel Berg/Raleigh/IBM@IBMUS, Cc: [email protected] Date: 07/26/2012 12:51 PM Subject: Re: [Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21 [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
