Hi all
I don't think that there is one right or wrong answer for this.
But, to my understanding, the Product/Service/Resource entity reflects the state and not the action. For the action, we have ProductOrder/ServiceOrder/ResourceOrder - in these Orders we have the OrderItem that includes action. So to add a feature, you would model the feature as a Service in the catalog, and then issue a ServiceOrder including an OrderItem with action
add for this Service. To remove the feature, use an OrderItem with action
remove.
As an alternative approach for features that don't have characteristics, you could model the feature itself as a characteristic of type Boolean; value
true would cause the feature to be active and value
false would cause the feature to be inactive. I don't like this approach so much, but I can understand why some people would find it attractive.
Hope it helps.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------
Original Message:
Sent: Jun 29, 2019 06:42
From: Koen Peeters
Subject: TMF641 - Handling Service Feature
Hi,
as you correctly state your features is usually modeled a a seperate CFS.
You fail to explain why this modeling doesn't suit you.
Regards
------------------------------
Koen Peeters
Ciminko Luxembourg
Original Message:
Sent: Jun 28, 2019 13:58
From: Stephane AH-KO
Subject: TMF641 - Handling Service Feature
Hi,Hi,
We are able to map our Characteristic or group of characteristics leveraging the proposed structure using valueType of "string" or "object"
Where we have issues are around Features. For us a feature is a "thing" that is actionable. - A characteristic "describes" the service (i.e. DownloadSpeed, UploadSpeed)
- A feature is a capability that can be added, removed or modified (i.e. CallForward, 3WayCall). Other would see those as different CFS, but in our modelling, those are features of a Voice CFS. We are planning to extend the characteristic object (composed of name, valueType, value...) to a new attribute (action). When "action" gets populated, it means a feature.
We would have something like:
- serviceCharacteristic- name: 3WayCall
- action: add
For complex feature structure (with characteristic), we would have something like:
- serviceCharacteristic- name: CallForward
- action: add
- valueType: "object"
- value:
- @type: CallForwardTN
- TN: 9052224444
Looking for some feedback if we are taking the right approach
Regards
------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------