[Oslc-Automation] Scenarios for outputParameter on Automation Request

[Pramod K Chandoria]

The scenarios to consider which demands parameter on automation request 
resource
Scenario 1:
1. User submits an Automation Request for execution
2. Automation Request is picked up by one of the [worker] 'client' of 
Automation Provider
3. 'client' start initiating the automation
4. 'client' needs to change certain parameter or provide additional 
parameter during the course of initiating, executing and completing the 
automation
4. Upon completion of the automation, 'client' POST Automation result, 
passing parameters from Automation request.

Scenario 2: Chaining the execution: First specification version has not 
addressed it explicitly, but still providers can implement it's own 
chaining mechanism
1. User submit request for execution of 'Group of Automation Plan', [kind 
of sequential workflow].
2. Automation service provider generates automation request for the first 
Automation Plan
3. 'client' executes the first Automation Request and completes it
4. Automation provider upon completion of first Automation request, 
triggers execution of next Automaton Plan in sequence.
5. It creates Automation Request for next step, passing all parameters 
from previous step. This passing of parameters continue from step to step.

I think the reason we are perceiving that outputParameter is not that 
important from end user scenario perspective who is looking for final 
result after submitting the request.
However if look from little different "how" perspective, how provider will 
execute the automation, it might make sense. I am assuming most of the 
automation providers will need some sort of 'client' to execute the 
automation.
The current specification enforces implementers should create the 
Automation Result as early as Automation Request is submitted for 
'clients' to participate in contributing to the parameters

Regards
-|- Pramod Chandoria



From:   Michael F Fiedler <fiedler at us.ibm.com>
To:     oslc-automation at open-services.net
Date:   10/22/2012 11:25 PM
Subject:        [Oslc-Automation] Scenarios for outputParameter on 
Automation      Request
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



In last Thursday's automation workgroup meeting we discussed the recent 
mailing list thread [1] on the possible need for an outputParameter (or 
perhaps other name) attribute on Automation Requests.   Pramod agreed to 
consider documenting a scenario he had thought of on the list for 
consideration.   Some of the points from the workgroup meeting were:

- It is understood that the purpose of the outputParameter attribute on 
the Result is a means recording what parameters went into producing the 
result without saying anything about when they were introduced.
- it is understood that a provider could add such an attribute itself, 
even if not defined in the spec, if it is useful for its scenarios. 
Drawback would be generic consumers might not look there for it.
- the scenario around using an attribute in the Request as a placeholder 
or means of carrying parameters across the execution was probably not 
sufficient in itself.   But Pramod had put some thought into future 
chaining or composite automation where it may be useful or required and 
will document.

If anyone else has scenarios around this where you feel having 
outputParameters (or some attribute to hold new/changed parameters on the 
request), please bring them up on the list.

[1] - 
http://open-services.net/pipermail/oslc-automation_open-services.net/2012-October/000326.html



Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20121023/c632c3e0/attachment-0003.html>