Automation Template Scenarios

Contents

• Automation Template Scenarios
  • Scenario
  • Variations
  • Proposal for Resource Template Creation Dialog
    • Resource Template Creation Dialog
    • Prefilling Resource Template Creation Dialogs

Scenario

The Core delegated creation dialog specification assumes that the resource is immediately created when the user exits the dialog. Automation added “execution” as an immediate consequence of Automation Request creation. In some scenarios the user may want one behavior without the other.

Scheduled execution

The user wants to use an orchestrator or a scheduler (consumer) to periodically execute an automation plan (on the provider).

1. The user opens the provider user interface to define scheduling rules and uses a dialog of the provider to define the automation request. This automation request does not have to be submitted for execution yet.
2. The scheduling rules and the “template” of the automation request are saved in a resource on the consumer
3. When the scheduling rules are matched, the orchestrator triggers the execution of the action by creating the automation request from the “template” the user previously defined.

Execution that requires an approval process

The user wants to execute an action that requires an approval process.

1. The user opens the ticketing interface and from this interface invokes a delegated dialog to define the automation request.
2. The “template” of the automation request and all the other information about the ticket (priority, due date…) are saved in a resource on the consumer.
3. Following the approval process, this ticket is processed by the approver, if the ticket is approved, the ticketing tool triggers the execution of the action by creating the automation request from the “template” the user previously defined.

Variations

1. The “scheduling smarts” could be in either actor, provider or consumer. The scenarios above are currently written to assume one of these, but this is exemplary, not limiting.
2. The template might be saved in either actor, provider or consumer. The scenarios above are currently written to assume one of these, but this is exemplary, not limiting.

Proposal for Resource Template Creation Dialog

OSLC Automation service providers support the selection and creation of Automation resources as defined by Delegated UIs in OSLC Core and extends the behavior of the delegated UI dialogs with a new type of dialog:the resource template creation dialog.

Resource Template Creation Dialog: when a user of a web application needs to create a new resource definition that can be used by the UI consumer for delayed creation of resources. In this case the web application asks the service provider to provide a UI for resource template creation and the provider notifies the application when the template creation has been completed or canceled by the user.

The resource template creation dialog returns a URI of a template resources. A GET on the template resource URI returns the representation of the resource to be provided to the creation factory. The consumer can store this resource representation for one or more subsequent resource creation.

The service providers supports requirements for delegated UIs is as follows:

Resource Template Creation Dialog

Resource Template Creation Dialog can be used when a UI Consumer wants to allow a user to create a new resource that is managed by an OSLC Service. Using either the Post Message or Window Name protocols defined above, the UI Consumer uses an iframe to embed a resource template creation dialog that is provided by the service, then awaits notification that the user has configured the resource to be created. To enable Resource Template Creation, an OSLC Service MUST provide in its dialog definition the usage “http://jazz.net/ns/ism/automation/scheduling#noCreate” (we may find a better name for this) like in the following example:

  <oslc:creationDialog>
          <oslc:Dialog>
            <oslc:usage rdf:resource="http://jazz.net/ns/ism/automation/scheduling#noCreate"/>
            <dcterms:title rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">Job Stream In Plan Creation Dialog</dcterms:title>
            <oslc:resourceType rdf:resource="http://open-services.net/ns/auto#AutomationRequest"/>
            <oslc:label>Job Stream In Plan Creation Dialog</oslc:label>
            <oslc:hintWidth>1130px</oslc:hintWidth>
            <oslc:hintHeight>720px</oslc:hintHeight>
            <oslc:dialog rdf:resource="http://host:34115/dialogs/resourceTemplate"/>
          </oslc:Dialog>
        </oslc:creationDialog>

Regardless of how the response from the UI Provider is conveyed to the UI Consumer, the response SHOULD be formatted as defined by oslc:results

Example:

{“oslc:results”: [ { “oslc:label”:”Automation Request”, “rdf:resource”:”http://host:port/context/automationrequest?plan=b5fa212f-9c18-384e-bdff-e287716bd464” } ] }

Example of a GET on the template:

GET /context/automationrequest?plan=b5fa212f-9c18-384e-bdff-e287716bd464”

<?xml version='1.0' encoding='UTF-8'?>
<rdf:RDF    
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'  
xmlns:dcterms='http://purl.org/dc/terms/'  
xmlns:oslc='http://open-services.net/ns/core#'  
xmlns:oslc_auto='http://open-services.net/ns/auto#'>    
<oslc_auto:AutomationRequest>
<dcterms:title>AUTOMATION REQUEST</dcterms:title>      
<dcterms:identifier>1</dcterms:identifier>
<oslc_auto:state rdf:resource='http://open-services.net/ns/auto#new'/>
<oslc_auto:executesAutomationPlan rdf:resource='http://host:34115/plans/b5fa212f-9c18-384e-bdff-e287716bd464'/>
</oslc_auto:AutomationRequest>
</rdf:RDF>

Prefilling Resource Template Creation Dialogs

Service providers MAY support receiving a POST request whose content body is a resource definition to the Creation or Resource Creation or Resource Template Dialog URI to retrieve a URI that represents the embedded page to be used. Service providers MUST respond with a response status of 201 (Created) with the response header Location whose value is the URI to request the newly created form. After some elapsed time, service providers MAY respond with a 404 (Not Found), 410 (Gone) or 3xx (Redirect) to an HTTP GET request for these URIs.

The following diagram shows the interactions to create a resource:

Important notes:

1. The resource template resource could be temporary and the consumer should get it within a limited period of time.
2. The resource template resources are not persisted and cannot be queried.
3. Implementation suggestion: the URI of the resource template could contain the resource representation of the resource, compressed and encoded.