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.

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.

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?

Inputs of the ActivitySpec to be received from

Workflow

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"

    }

  ]

}

Status of the Activity Spec