Could you provide an example of your product model, ideally using TMF product catalogue semantics?
Additionally, could you explain how your product varies for different domain consumers and their unique requirements?
It would also be helpful if you could clarify the terms "domain consumers" and "domain function."
Original Message:
Sent: Nov 05, 2024 19:35
From: Ishan Joshi
Subject: TMF620 GET /productOfferingPrice
Thank you for your quick response, Matthieu,
I am considering adding subclassing to my list of options. However, I want to ensure I fully grasp the concept. Given our scenario where the same characters/values are utilized by various domain consumers to satisfy their unique requirements, would you say subclassing is a viable approach? Furthermore, does this imply that we would need to create a new subclass for each distinct domain function to cater to their specific needs?
Kind Regards
------------------------------
Ishan Joshi
Original Message:
Sent: Nov 04, 2024 12:04
From: Matthieu Hattab
Subject: TMF620 GET /productOfferingPrice
Ishan Joshi,
I wouldn't automatically recommend adding a new attribute like you suggested ( "isChargable": "true"). If you use TMF APIs, you will notice that they have a small number of attributes. Adding a new attribute can be done assuming it serves a purpose for all data in that entity.
For example, for the party entity, you're not going to add attribute "first name" just because some party records do have a first name. Instead you sub-class Party and create sub entity "Individual" and there you add your "first name" attribute.
Instead of adding a new attribute, you could also explore polymorphism (see TMF630) for the productSpecCharacteristic entity:
- @baseType would be "CharacteristicSpecification"
- @Type would be "BillableCharacteristicSpecification"
(you can do the same with characteristicValueSpecification)
But Dan from post #2 is right, the valueUse relationship between a POP and your char/charValue is a good option to define price(s) applicable for a given char/charValue(s).
My 2 cents
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Nov 04, 2024 02:53
From: Dan d'Albuquerque
Subject: TMF620 GET /productOfferingPrice
The Characteristic Specification is an extensible entity so there is no reason why you can't add extended fields, in fact we have also done this in our model.
That said... the prodSpecCharValueUse field within the POP is typically used to provide a specific price for a particular configuration of a product, e.g. 20 USD for a 100GB configuration (characteristic), 30 USD for a 200GB configuration. So, your billing related characteristics may be better placed at the ProductOffering -> CharacteristicSpec level.
Original Message:
Sent: 11/3/2024 11:54:00 PM
From: Ishan Joshi
Subject: RE: TMF620 GET /productOfferingPrice
Hi Dan
Thanks for responding.
We have a couple of char configuration use cases like "Bill Description" which are not price impacting but still required by our down stream for rating and invoice generation function. In this case the billing would like to know the chars which they can use to derive the rate and use the rest as a derived data.
Regards
------------------------------
Ishan Joshi
Original Message:
Sent: Nov 03, 2024 21:15
From: Dan d'Albuquerque
Subject: TMF620 GET /productOfferingPrice
Hi Isham
Within the POP (Product Offering Price), the relationship to a specific characterstic/value within the prodSpecCharValueUse in indicative of a price relating to that specific characteristic value/configuration. Not sure why you would need to use an "isChargeable" concrete extension field in addition to this existing model. Please can you provide an example (real use case) characteristic to explain the purpose of this extension?
------------------------------
Dan d'Albuquerque
Individual
Original Message:
Sent: Nov 03, 2024 18:03
From: Ishan Joshi
Subject: TMF620 GET /productOfferingPrice
Hello Experts,
We have a requirement to expose product char metadata on a TMF620 product offering price resource for the consumers of the API to perform charging domain function. As we do not have such metadata available on the standard spec we are exploring below options :
1) Uplift spec with TMF630 recommended Schema Based enhancements for Chars.
2) Uplift the API spec with bespoke enhancements to reduce the number of steps for the consumers.
To explain it further , in the example below the expectation is to provide metadata flag on each char to identify if the char is rate determining or not.
"prodSpecCharValueUse": [
{
"name": "Char Name",
"productSpecCharacteristicValue": [
{
"value": "Char Value"
}
"isChargable": "true",
]
I would like to request guidance from the community on enhancement approach for such requirements. We also anticipate more such requirements in future from the consumers of the Catalog API for additional metadata.
Thanks in advance .
------------------------------
Ishan Joshi
------------------------------