[Oslc-Automation] Actions 2.0 - Dialog RDF

Martin P Pain martinpain at uk.ibm.com
Tue Nov 12 10:55:46 EST 2013


My thoughts so far are along these lines:

@base <http://example.com/>.
<results/1>
   a oslc_auto:AutomationResult ;
   oslc_auto:state oslc_auto:complete ;
   oslc_auto:verdict oslc_auto:passed ;
   oslc_auto:reportsOnAutomationPlan <plans/1> ;
   dcterms:identifier "result-1" ;
   action:action [
        a action:Action, new:StopAction ; 
        dcterms:description "Tear down the deployment";
        dcterms:title "Tear down";
        action:request [
            a                            http:Request ;
            http:requestURI              <requests/creationFactory> ;
            http:mthd                    http-methods:POST ;
            action:requestBodyParameters 
<plans/1.teardown?resourceId=result-1>;
            # Server hides resource ID within (opaque to client) URI
        ];
        action:request [
            a                            oslc:Dialog ;
            dcterms:title                "Tear down resource: result-1" ;
            oslc:dialog                  <requests/creationDialog> ;
        ];
   ];
. 
   

I think this achives scenario (A). I think any "execute later" scenarios 
are substatially different - they need to pick a particular implementation 
(e.g. AutoPlans, ResourceShape) by which it will be executed at the later 
time. This is different to scenario (A) where the dialog is the 
implementation.

(B) and (C) are specific to Automation profile, so they can reply on an 
AutomationPlan implementation of the action - but still need some way to 
find the dialog. (B) can be achieved by a templateDialog, which we could 
either say must be linked to from the AutomationPlan http:Request or by 
navigating serviceProvider links. (C) is harder, as we need a way for the 
consumer to inject the URL of the context (probably the Result) into the 
Request template produced by the template dialog, but hopefully we can 
provide some Automation-specific way of doing this, as it is an 
Automation-specific scenario anyway.

Any objections to exposing dialogs as above for scenario (A)?
Any objections to having these two different ways of finding dialogs? (One 
for "dialog performs the action" and one for "a dialog providing data for 
a particular implementation").

Please reply to the mailing list with any comments (rather than leaving it 
to the meeting).

Kind regards,

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:  




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU



From:   Martin P Pain/UK/IBM at IBMGB
To:     oslc-automation at open-services.net, 
Date:   07/11/2013 17:00
Subject:        [Oslc-Automation] Actions 2.0 - Dialog scenarios
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



Here are some scenarios for the usage of dialogs: 

------------ 

A) Executing an action through a UI 

Actors: user, consumer, provider 

Steps: 
1) The user navigates to a page on the consumer's UI which shows resources 
from the provider. 
2) The user selects a resource (e.g. AutomationResult) 
3) The consumer shows the user the list of actions that are available on 
that resource (e.g. including teardown) 
4) The user selects one to execute (e.g. teardown) 
5) The consumer displays, to the user, a dialog provided by the provider 
6) The user enters any parameters or input required (e.g. "This will 
<...>. Are you sure?") and clicks a button on the dialog to execute the 
action. 
7) The provider executes the action 
8) (Simultaneously) the consumer is notified that the dialog has closed. 

------------ 

B) Configuring an action through a UI, executing it later. (Specific to 
the Automation profile). 
(I want to consider these "execute later" scenarios in-scope, as they 
apply to the teardown scenario, but I hope that we can get the "for free" 
with minimal changes to the proposed spec, using the Automation Plan and 
template creation dialogs.) 

Actors: user, consumer, provider 

Steps: 
1) The user navigates to a page on the consumer's UI which shows resources 
from the provider. 
2) The user selects a resource (e.g. AutomationResult) 
3) The consumer shows the user the list of actions that are available on 
that resource (e.g. including teardown) 
4) The user selects one (e.g. teardown) and opts to execute it later (e.g. 
on a schedule) 
5) The consumer displays, to the user, a dialog provided by the provider 
6) The user enters any parameters or input required and clicks a button on 
the dialog to submit their input. 
7) The provider creates a temporary AutoRequest with the user's details - 
but does not queue it for execution - and returns the URL to the consumer. 
(Apologies for the technical details here, as most of these scenarios' 
steps are technically agnostic. For a technically agnostic scenario, just 
omit steps 7 through 9 and skip straight to 10.) 
8) The consumer retrieves the temporary resource and stores it. 

Later, when the scheduled time arrives (these steps are performed with no 
UI and no user present): 
9) The consumer submits the stored AutomationRequest to the provider. 
10) The provider executes the action (by executing the AutomationRequest). 


------------ 

C) Configuring through a UI an action that is not yet available, executing 
it later. (Specific to Automation profile) 

Actors: user, consumer, provider 

Steps: 
1) The consumer displays a list of deployment AutomationPlans from the 
provider to the user. 
2) The user selects one to add to a list of plans to execute at a later 
time. 
3) The consumer asks the user if they wish the deployment to be torn down 
when all the plans in the list have finished. 
4) The user indicates that they do. 
5) The consumer displays, to the user, a dialog provided by the provider 
which asks for parameters related to the teardown. 
6) The user enters the required information and submits the dialog. 
7) The user adds more plans to the list... 

Later, when the scheduled time arrives (these steps are performed with no 
UI and no user present): 
8) All the plans on the list are executed 
9) When the list is finished, the consumer requests that the provider 
performs the "teardown" action on the resource that was deployed by the 
plan selected in steps 2-6. 

----------- 

I've got ideas about how this can be covered in the spec, but I'm not sure 
about how to do the last one. We can discuss this on the call today, if we 
get time.



Kind regards, 

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair 

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:   




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131112/169308c0/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131112/169308c0/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131112/169308c0/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131112/169308c0/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131112/169308c0/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131112/169308c0/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131112/169308c0/attachment-0001.gif>


More information about the Oslc-Automation mailing list