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 <[email protected]> To: [email protected] Date: 10/22/2012 11:25 PM Subject: [Oslc-Automation] Scenarios for outputParameter on Automation Request Sent by: "Oslc-Automation" <[email protected]> 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 [email protected] 919-254-4170_______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
