- Consumer prepares for execution (Automation Job creation)
- GETs catalog
- looks up service providers
- GETs desired service provider and looks up/saves
- Automation Plan query capability
- Automation Job creation factory
- Automation Job creation resource shape
- GETs all Automation Plans (could also get a specific plan, if known)
- select the Automation Plan to be executed
- GET the parameters expected when a Job is created for this plan (intentionally left vague, see discussion below)
- Consumer creates the Automation Job
- Build an Automation Job RDF document
- POST the Automation Job to the provider and receives a response with a code (TBD) and reference to the Job, if successful.
- Automation provider runs the Job
- Provider receives the POST request
- Provider-specific processing for execution occurs
- During execution, the Job is possibly updated with status, contributions (e.g. log, output)
- Could be updated by the provider or by a worker the automation was handed off to
- The consumer who created the Job can poll for progress, if desired, by GETting the Job
- Job completes
- Job is updated to indicate it is complete
- Job is updated with a final verdict
- Job can possibly be updated with extra data (TBD, examples might be links to associated artifacts such as test results or approval records)
- Consumers can GET the final Job.
The workgroup discussed the issue of passing parameters/environments to the provider when an Automation Job is created. An approach using resource shapes was discussed - the creator of the Automation Job would request the resource shape for Automation Jobs and use that to provide the necessary input. However, since an automation provider may have many Automation Plans, each could require a different set or type of inputs. Just having a resource shape for an Automation Job creation factory would be insufficient.
Conceptually, what is needed is a way to request the Automation Job creation resource shape for a given instance of an Automation Plan.
- Is there a need for a new artifact (Automation Environment) for the consumer to use to specify input? This may just push the issue off to another layer.
- For the purposes of OSLC, limit the specified inputs - is there a common set?
- What is done in other domains for generic parameter passing?
Items for the next discussion of this scenario.
