Hello Lakshmi
We had same challenge in our implementation where we want to manage 'complex' characteristic for TaskFlow.
We took a different approach than yours and we came to the conclusion to manage
TaskFlowSpecification (Design time)where we can define the expected characteristic structure for a task.
For example, suppose a task need the user to fill product offering data (name, brand, description, isInstallable) , the taskFlowSpecification will define them:
"taskFlowSpecificationId": "4987b9c2-7188-4f47-973d-f1c3b8362156",
"taskFlowSpecificationCharacteristic": [
{
"name": "DefineProductOfferingIdentityData",
"id": "4987b9c2-7188-4f47-973d-f1c3b8362156-DefineProductOfferingIdentityData-0",
"valueType": "Object",
"minCardinality": 1,
"maxCardinality": 1,
"characteristicValueSpecification": [
{
"@type": "ObjectCharacteristicValueSpecification",
"isDefault": null,
"value": {
"DefineProductOfferingIdentityData": {
"required": [
"name",
"description"
],
"type": "object",
"properties": {
"name": {
"type": "string"
},
"brand": {
"type": "string"
},
"description": {
"type": "string"
},
"isInstallable": {
"type": "boolean",
"default": true
}
}
}
}
}
]
Then runtime, when the process is executed we provide to the system in charge of the task completion (the front end) this data in _links
Here is an extract from the POST ProcessFlow response where in the _links part the next task is described
{
....
"_links": {
"self": {
"href": "http://.../processManagement/v4/processFlow/5319685f-9623-4692-a8ba-c2b0f38b4c31"
},
"taskFlowList": {
"href": "http://g..../processManagement/v4/processFlow/5319685f-9623-4692-a8ba-c2b0f38b4c31/taskFlow"
},
"nextTaskstoBePerformed": [
{
"title": "ProductOfferingCreation.description",
"href": "https://.../processManagement/v4/processFlow/5319685f-9623-4692-a8ba-c2b0f38b4c31/taskFlow/4987b9c2-7188-4f47-973d-f1c3b8362156",
"state": "active",
"taskFlowSpecificationId": "4987b9c2-7188-4f47-973d-f1c3b8362156",
"taskFlowSpecificationCharacteristic": [
{
"name": "DefineProductOfferingIdentityData",
"id": "4987b9c2-7188-4f47-973d-f1c3b8362156-DefineProductOfferingIdentityData-0",
"valueType": "Object",
"minCardinality": 1,
"maxCardinality": 1,
"characteristicValueSpecification": [
{
"@type": "ObjectCharacteristicValueSpecification",
"isDefault": null,
"value": {
"DefineProductOfferingIdentityData": {
"required": [
"name",
"description"
],
"type": "object",
"properties": {
"name": {
"type": "string"
},
"brand": {
"type": "string"
},
"description": {
"type": "string"
},
"isInstallable": {
"type": "boolean",
"default": true
}
}
}
}
}
]
}
],
"method": "PATCH",
"accepts": "merge-json-patch"
},
....
],
"existingTaskEditable": []
}
}
Then, once the user complete task in the front, the front end just pass the valued characteristic:
PATCH http:.../processManagement/v4/processFlow/5319685f-9623-4692-a8ba-c2b0f38b4c31/taskFlow/4987b9c2-7188-4f47-973d-f1c3b8362156
{
"characteristic": [
{
"name": "DefineProductOfferingIdentityData",
"value": {
"brand": "Orang",
"name": "5GbyOrange",
"description": "5G Mobile access",
"isInstallable": true
},
"valueType": "Object",
"@type": "ObjectCharacteristic"
}
]
}
As I wrote previously, this is a different approach than yours but hope it can provide you some 'food for thought'
I've plan to contribute this requirement for ProcessFlowSpecification and TaskFlowSpecification to TMF
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------
Original Message:
Sent: Aug 18, 2021 06:33
From: Lakshmi Pillay
Subject: TMF701 TaskFlow characteristic
Hi,
Request your help with an issue around defining characteristic.
We were looking at TMF701 for modelling a process flow and have a query around how to model a task flow with multiple characteristics. As per the swagger spec (given below), we can use @baseType and @schemaLocation to qualify the value under characteristic. But we have 2 scenarios that require support of multiple characteristics.
1. Different tasks will have different characteristics. For e.g. Task 1 could have a shopping cart characteristic, Task 2 would have payment details under characteristic and Task 3 will have address details. When defining the swagger spec, if the type is defined as ObjectCharacteristic, is there a way to state that the object could be any of the defined types - shoppingCart, paymentDetails or addressDetails. And if so, how do I link multiple type locations under schemaLocation. We tried this using anyOf (as defined in swagger spec) but when we use openApiGenerate, it creates a single object which has properties for all the 3 objects.
2. Single task could have two different characteristics where both are different objects. Again couldn't find a way to define this in a strongly typed manner
Is there a clean way of defining the above 2 scenarios please.
Relevant extract of characteristic spec
"value": { "$ref": "#/definitions/Any", "description": "The value of the characteristic" }, "@baseType": { "type": "string", "description": "When sub-classing, this defines the super-class" }, "@schemaLocation": { "type": "string", "format": "uri", "description": "A URI to a JSON-Schema file that defines additional attributes and relationships" }, "@type": { "type": "string", "description": "When sub-classing, this defines the sub-class entity name" }
Thanks,
Lakshmi
------------------------------
Lakshmi Pillay
Tech Mahindra Limited
------------------------------