Activity Spec Structure

# FieldDescriptionDataTypeComment by YUAN HU
1 idIdentifier 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
2versionIdUUID 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
3nameName of the Activity Spec.  A user friendly name, used to display in ASDC UI defining the workflows or user monitoring a process in MSOstring
4descriptionDescription 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.

What does the workflow engine need to know about the Activity Implementation to enable it to invoke the right Activity Implementation in SO. Please point me to the BPMN 2.0 standard document and relevant section.

Is this required for workflow designer/editor or only workflow engine? Required by the workflow engine however the BPMN artifact generated by the workflow designer needs to have the Task Implementation details.

7categoryListCategory 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.

Fine to change the term, let's use a standard BPMN term. Where is "scenes" term coming from?

8inputs 

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.

Is the inputs structure different between restTask and serviceTask?


Objective was to keep the ActivitySpec structure abstract from the implementation of the Activity. This was the reason we didn't have type and content previously. If we agree with the objective, we do need some level of implementation details to support BPMN standard but let's not make this very much BPMN specific. We want ActivitySpec to support BPMN, BPEL, TOSCA and other standard/proprietary workflow engines.

----Yuan: In fact, regardless of whether the target workflow language is BPMN, BPEL, TOSCA or other standard, you need to specify the type of script and the contents of the script as a script activity. Similarly, you need to specify a class for a java/service activity. So that the target workflow engine can execute the script or call the java class correctly.


ActivitySpec has fields related to business and some related to implementation. Since in ONAP/R2 the solution is not matured enough to indicate if we would only need to support specific workflow languages we will revisit this in ONAP/R3 if any of the high-level principles or objectives of this project change.

Working on the datatype for this field. We will try and align with either BPMN standard or JSON.

Request Headers:

Connection: keep-alive

Accept: application/json

Content-Type: application/json

USER_ID: cs0008

Content-Length: 342

User-Agent: Jakarta Commons-HttpClient/3.1

Host: 10.147.97.237:8185

POST http://10.147.97.237:8185/v1.0/activity-spec

{

  "name": "ActivitySpecnameCKTFMBdbBj1",

  "description": "ActivitySpecdescriptionYMnjaHsjeucnCPfPWnHT1",

  "categoryList": [

    "app server"

  ],

  "inputParameters": [

    {

      "name": "host",

      "type": "string",

      "default": "started" 

    }

  ],

  "outputParameters": [

    {

      "name": "status",

      "type": "string",

      "value": "started"

    }

  ]

}


9outputsOutputs of the ActivitySpec to be sent to Workflow parameter[] The internal fields of the parameter should be defined.
10status

Status of the Activity Spec

 		string 

Status Transition Map

  1. draft - On creation by using createActivitySpec
  2. certified - On certification by using certifyActivitySpec
  3. deprecated - On certification by using deprecateActivitySpec

Sample ActivitySpec Management Flow


  • No labels

7 Comments

  1. Yuan Hu

    Base on the conclusion of the last meeting, I have the following comments,

    1. Need to add a 'type' field to indicate the associated BPMN task type for this activity, such as: serviceTask, scriptTask.
    2. To add 'content' field to indicate the associated BPMN task detal information, such as class(for serviceTask), scriptFormat/script(for scriptTask).
    3. Can 'inputParameters / outputParameters' be renamed to 'inputs / outputs'? They have the same meaning, but are more concise. And can these field be moved into the 'content' field for the input parameter definition of serviceTask is slightly different from restTask..
    4. Can all field names start with lowercase letters? Such as change 'Name' to 'name', 'UUID'  to ''uuid.
    sample for BPMN serviceTask 
    {
    "id":"extend-activity-id-stop-traffic",
    "name":"Stop Traffic",
    "description":"Stop Traffic",
    "type":"serviceTask",
    "content":{
        "class":"org.onap.activity.ext.StopTrafficServiceTask",
        "inputs":{
            "param1":{
                "type":"string",
                "default":"value1",
                "required":true,
                "constraints":[

                ],
                "displayName":"aaa",
                "show":true
            },
            "param2":{
                "type":"string",
                "default":"value2",
                "required":false,
                "constraints":[

                ]
            }
        }
    }
}
    sample for BPMN scriptTask 
    {
    "id":"extend-activity-id-stop-vnf",
    "name":"Stop VNF",
    "description":"Stop VNF",
    "type":"scriptTask",
    "content":{
        "scriptFormat":"groovy",
        "script":"test groovy script"
    }
}

    1. Srinivasa Vellanki

      We can definitely support, will reconfirm once I close it with our team. Note the field names, data-type will be confirmed this week.

      1. type
      2. content/info: which be a string and you can record anything there Class name, script name etc..
      3. inputs and outputs, we cannot have them in content or info. Also as indicated above will let you know the exact name later, if the suggested are based on some guideline we can definitely align.
      4. Also as indicated above will let you know the exact name later, if the suggested are based on some guideline we can definitely align.

      1. Yuan Hu

        Suggest to use the Camel-Case naming rule to name these fields.

        The first word starts with a lowercase letter, The rest of the words begin with an uppercase letter.

        Such as 'name', 'uuid', etc.


  2. Yuan Hu

    The 'content' field should describe the BPMN task information ralated to the extend activity.

    Here are some examples of BPMN tasks that follow the BPMN specification

    Example of BPMN Script Task:
    <scriptTask id="theScriptTask" name="Execute script" scriptFormat="groovy">
  <script>
    sum = 0
    for ( i in inputArray ) {
      sum += i
    }
  </script>
</scriptTask>
    Example of BPMN Service Task:
    <serviceTask id="javaService"
             name="My Java Service Task"
             camunda:class="org.camunda.bpm.MyJavaDelegate" />

  3. Yuan Hu

    The internal fields of 'content' for a serviceTask as follow:

    Name

    Data Type

    Required

    Description

    Comment

    classStringYesThe implement class of the bpmn service task
    Sample for BPMN serviceTask: 
    {
    "id":"extend-activity-id-stop-traffic",
    "name":"Stop Traffic",
    "description":"Stop Traffic",
    "type":"serviceTask",
    "content":{
        "class":"org.onap.activity.ext.StopTrafficServiceTask"
    },
    "inputs":{
        "param1":{
            "type":"string",
            "default":"value1",
            "required":true,
            "constraints":[

            ],
            "displayName":"aaa",
            "show":true
        },
        "param2":{
            "type":"string",
            "default":"value2",
            "required":false,
            "constraints":[

            ]
        }
    }
}


    The internal fields of 'content' for a scriptTask as follow:

    Name

    Data Type

    Required

    Description

    Comment

    scriptFormat

    String

    Yes

    The script format, For example: JavaScript, groovy


    script

    String

    Yes

    The script content.


    Sample for BPMN scriptTask 
    {
    "id":"extend-activity-id-stop-vnf",
    "name":"Stop VNF",
    "description":"Stop VNF",
    "type":"scriptTask",
    "content":{
        "scriptFormat":"groovy",
        "script":"test groovy script"
    }
}

  4. Yuan Hu

    The internal fields of 'parameter' should be defined as follow:

    Name

    Data Type

    Required

    Description

    Comment

    type

    String

    Yes

    data type of the input paramter. Such as: string


    default

    any

    No

    the default value of the input paramter.


    required

    boolean

    Yes

    Should the input paramter be necessary?

    true - necessary

    false - not necessary


    displayName

    String

    No

    Alias of the Input paramter only for displaying use.

    		If there is no alias, the original name will be displayed

    show

    boolean

    No

    Is it displayed in the UI?

    		If false, this input parameter will be hided on the UI and not exposed to the service user.

  5. Perry Dong

    Hi, is there a list of activities exported by SO? A quick search of "Create Activity Spec" or "createActivitySpec" or "activity" in the SO code-base results nothing. Thanks.