Function definitions
Function definitions describe the functions available for the workflow to execute and the name of the adapter and activity that should be invoked by the engine when that function is invoked. While the Serverless Workflow specification supports various types of functions, CWM supports only those custom type functions that map to activities exposed via Adapters.
The following properties of function definitions are supported.
Parameter |
Definition |
---|---|
name |
Name of function definition. |
operation |
Defines the adapter name and activity name that should be invoked by the engine. Format is <adapter name>.<activity name>.
For example: The NSO Adapter has an activity called |
metadata |
Allows modelling of information beyond the core definition of the Serverless Workflow specification. The "worker" key is used to define which Taskqueue the activities will be executed on. CWM supports the concept of Workers that execute an Activity and are assigned Taskqueues that they listen to. To schedule an activity to run, the workflow engine places the activity on a Taskqueue. A worker process picks up the tasks to execute from the Taskqueue and executes the activity. |
Example:
"functions": [
{
"name": "NSO.RestconfGet",
"operation": "restconf_Get"
"metadata": {
"worker": "defaultWorker"
}
},
{
"name": "NSO.RestconfPut",
"operation": "restconf_Put"
"metadata": {
"worker": "defaultWorker"
}
},
{
"name": "NSO.RestconfPost",
"operation": "restconf_Post"
"metadata": {
"worker": "defaultWorker"
}
},
{
"name": "NSO.RestconfPatch",
"operation": "restconf_Patch"
"metadata": {
"worker": "defaultWorker"
}
},
{
"name": "NSO.RestconfDelete",
"operation": "restconf_Delete"
"metadata": {
"worker": "defaultWorker"
}
},
{
"name": "NSO.SyncFrom",
"operation": "device_SyncFrom"
"metadata": {
"worker": "defaultWorker"
}
},
{
"name": "REST.Post",
"operation": "rest_Post"
"metadata": {
"worker": "defaultWorker"
}
} ]