Skip to end of metadata
Go to start of metadata

Overview of "Define Executable Process" Use Case

Define, register and update an executable process, based on a source code or binary process definition.


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors System Process Developer, Process Operator (e.g., Data Process Operator)
References UC.R2.18 Visualize Data Product
UC.R2.19 Produce Matlab Visualization
Uses UC.R2.48 Schedule Process for Execution
UC.R2.44 Define Service Type During Runtime
UC.R2.51 Define Execution Engine
Is Used By UC.R2.45 Instantiate Service Anywhere During Runtime
Extends  
Is Extended By  
In Acceptance Scenarios AS.R2.04A Data Product Leads Drive Core Data Product Creation
Technical Notes See components "Source code representation services" and everything else in 1.2.3.13.2.2.
Lead Team CEI
Primary Service Process Catalog & Repository Services
Version 1.7.1
UC Priority 4
UC Status Mapped + Ready
UX Exposure EUC

Summary

This information summarizes the Use Case functionality.

System Process Developer creates a process definition that references a versioned process definition package. The user supplies this definition to ION. The definition or additional user inputs provide information about how the process is to be instantiated; with which inputs it may be executed; which outputs it creates; which execution modes it supports (e.g. stream based, schedule based, maximum frequency, one time); which parameters it supports; which provenance its outputs create; which additional resources are required; which anticipated resource use occurs; which error conditions and notifications are supported. After process definition, the system can schedule this process UC.R2.48 Schedule Process for Execution using the provided information. The appropriate outputs are distributed.

Assumptions

  • Processes can be data stream processes and service processes
  • Process definitions are available in packaged, versioned form on the software component repository
  • Process definitions may be source code or binary, with additional metadata descriptions
  • Each process declares which execution engine it supports
  • Processes are executed by execution engines
  • In Release 2, typical process types are Python (with science extensions) and Matlab

Initial State

The System Process Developer has a process definition script within a versioned process definition package.

Scenario for "Define Executable Process" Use Case

  1. The System Process Developer selects the Integrated Observatory capability to define a process.
    1. Via an operator console or an API function
    2. During operations of the system
    3. Note: processes may also be bundled with the system during integration time
  2. The System Process Developer enters or selects basic process metadata
    1. Producer and ownership information
    2. Name, version, description, type, use
    3. Supported execution engines, based on a given selection of available execution engines
  3. The System Process Developers provides the process definition or a reference to a process definition
    1. A reference to the versioned process definition package on an available software component repository; this can be the Integrated Observatory software component repository, GitHub, PyPi, or similar
    2. Alternatively the process developer can directly provide a process definition package in file format
    3. The system accesses the process definition and places it in a system internal repository
    4. The system checks basic validity of the process definition against supported execution engines, e.g., can it be installed without errors, does it have an included metadata manifest
  4. (optional) The System Process Developer declares process resource use metadata
    1. Which resources are required for process installation: Software packages, services, other processes; Licenses
    2. Which resources are required before process can be instantiated: Software packages, services, other processes; Operational unit size, network location, security, etc.; Local storage; Licenses
    3. Which resources are consumed during process execution and how does the process perform: Memory, temporary storage, network bandwidth; Execution time; Average throughput
  5. The System Process Developer or Process Operator declares process inputs, parameters and outputs
    1. Done as part of Transform Management Service.
    2. Provides instantiation mode (One time process, instantiate on use, stream process, scheduled activate [TF: is scheduled something the developer would have a say in?], service process; Singleton, worker pattern, concurrent)
    3. Declares process inputs: Which types of input data packets are produced
    4. Declares process parameters: Which parameter values (named, typed key-value pairs) can be provided during process instantiation (e.g. average over x packets)
    5. Declares process outputs: Which types if output data messages are produced
  6. (optional) The System Process Developer or Process Operator specifies instantiation and product use restrictions
    1. Instantiation restrictions (access control): Only in certain execution zone, Only by certain user groups/roles, Only when certain conditions are true
    2. Restrictions on product use, e.g. only for private consumption
  7. (optional) The System Process Developer or Process Operator can update process metadata
    1. If the process definition is changed, the system maintains the old definition and the new definition as separate versions with distinguishable provenance
  8. Users with appropriate access privileges can search for defined processes by their attributes.

Final State

Process is registered in the system resource registry and directory services, process definition is present in the system, and process can be instantiated.

Comments

These comments provide additional context (usually quite technical) for editors of the use case.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.