[Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21

[Daniel Berg]

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 at IBMUS,
Cc:	oslc-automation at open-services.net
Date:	07/26/2012 12:51 PM
Subject:	Re: [Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 21


oslc-automation-bounces at open-services.net wrote on 07/25/2012 12:34:18 PM:

> From: Daniel Berg/Raleigh/IBM at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120726/450aadc3/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120726/450aadc3/attachment.gif>