Activity Spec Structure
| # | Field | Description | DataType | Commit by YUAN HU |
|---|---|---|---|---|
| 1 | id | Identifier generated by ASDC per each Activity Spec. Remains same across various versions of ActivitySpec. Used by SDC and ECOMP components to identify ActivitySpec. Not expected to be used by users to identify ActivitySpec, is not human readable. | string | |
| 2 | versionId | UUID generated by ASDC per each version of the Activity Spec. Used by SDC and ECOMP components to identify ActivitySpec. Not expected to be used by users to identify ActivitySpec, is not human readable. | string | |
| 3 | name | Name of the Activity Spec. A user friendly name, used to display in ASDC UI defining the workflows or user monitoring a process in MSO | string | |
| 4 | description | Description of Activity Spec, which can be used in future as help text displayed to users. | string | |
| 5 | type | Type of Activity Spec. e.g. Service, Script, etc.. | string | The valid value should be 'serviceTask', 'scriptTask' according to bpmn specification. In ONAP/R2 there will be no validations on this field. It the system that is registering ActivitySpec will nee to use valid values. Do we need this field to be mandatory, currently it is optional and we prefer to keep it optional. We will try to keep it optional with default value of "ServiceTask" or make it Mandatory for consumer to specify. ZTE prefers to have it Mandatory and we all agree it should be mandatory eventually. |
| 6 | content | Implementation details of the Activity Spec possibly represented in JSON or any other format as preferred by workflow execution engine. | string | The format of the 'content' field should be JSON Object and its internal fields should be defined. For the WF Designer will parse the internal fields of content And convert these fields to a real bpmn task combine with activity's id and name. At the same time, the WF Designer may display these fields on the UI, so that The user can modify or conform the value of these fields. For example, the user can modify the 'script' field of a scriptTask. |
| 7 | categoryList | Category of the Activity Spec. Should be able to filter the Activities User can use based on context of workflow. Expect an ActivitySpec can be part of multiple Categories. Category will have list of valid-values configurable and for an Activity-Spec we could assign one or more categories. Categories have values like Service, VNF to indicate ActivitySpec applies to VNF and/or Service. | string[] | If you want to filter the Activities based on context of workflow, I suggest to use the filed name 'scenes' to replace 'categoryList'. For the 'category' is usually indicate the display group of the activities, not for filter use. |
| 8 | inputs | Inputs of the ActivitySpec to be received from Workflow | parameter[] | The internal fields of the parameter should be defined. Expect to move the inputs and outputs into the content field, for the inputs field of restTask have some special properties which should not be found in the serviceTask's inputs, such as 'location' which indicate it's a path parameter or query parameter. |
| 9 | outputs | Outputs of the ActivitySpec to be sent to Workflow | parameter[] | The internal fields of the parameter should be defined. |
| 10 | status | Status of the Activity Spec | string |
Status Transition Map
- draft - On creation by using createActivitySpec
- certified - On certification by using certifyActivitySpec
- deprecated - On certification by using deprecateActivitySpec
