There is a discussion in the forum about having product Specification for the Bundle entity.
It could make sense if the specifications are
static information (marketing information, some description etc), but not if you want use them to configure the bundle entity itself (e.g. characteristics with a list of discrete value).
GB922 product,
section 2.3.2. Figure Pr.05b - Product Spec - Product Offer Relationship attempts to explain why you should not have productSpec for the bundle itself.
as for naming convention, I've had these discussion many times before!
SID, GB922 uses Bundle
dProductOffering and SimpleProductOffering.
Bundle
dProductOffering confuses me because if it (verb in
past tense) implies the
entity is contained, therefore it's the component entity. that's also what TMF620 documentation use this term
so SID documentation and TMF620 contradicts each other
Bundl
eProductOffering would be better, it's not a verb and it implies the
entity is the container.
Bundl
ingProductOffering ? I'm not sure, ing (
present participle) implies
movement, action that are still happening. the term is never used in SID or API documentation.------------------------------
Matthieu Hattab
Altibox AS
------------------------------
Original Message:
Sent: Apr 06, 2022 10:39
From: Viktor Aleksandrov
Subject: Fields specific info for offerings
Yes, it would be much clearer if we could have BundlingPO, but as I could see from TMF620 API spec there's just an ordinary ProductOffering which could be a bundling or simple depending on isBundle property (see https://github.com/tmforum-apis/TMF620_ProductCatalog/blob/master/TMF620-ProductCatalog-v4.1.0.swagger.json#L5780).
BundledPO is used as an item in bundledProductOffering[] array (see https://github.com/tmforum-apis/TMF620_ProductCatalog/blob/master/TMF620-ProductCatalog-v4.1.0.swagger.json#L5839) and for me is just a holder for any other PO.
Then, any PO is able to have a ProductSpecification independently of being "isBundle" or not. My point is that your statement "BundledPO points to other POs, and has no ProductSpecification" (where you do mean bundling, yes?) is not true, and we may use PO's PS to provide Characteristics for this BundlingPO, or don't we?
------------------------------
Viktor Aleksandrov
OJSC "VimpelCom"
Original Message:
Sent: Apr 06, 2022 10:24
From: Jonathan Goldberg
Subject: Fields specific info for offerings
Hi Viktor
Unfortunately the SID naming is not clear - instead of Bundled it would have been better to call it BundlingProductOffering - the BPO represents a bundle of other offerings, which may themselves be bundles or simple.
And the option is on each relationship between the bundling offering and the offerings that it bundles.
Hope this is clearer
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Apr 06, 2022 08:16
From: Viktor Aleksandrov
Subject: Fields specific info for offerings
Jonathan, I just found your statement a bit confusing:
ProductOffering is an abstract class has two subclasses, SimplePO and BundledPO.
- BundledPO points to other POs, and has no ProductSpecification
- SimplePO has exactly one ProductSpecification
As far as I could understand the BundledProductOffering is an extension (subclass) to a PO which allows specification of bundledProductOfferingOption which describes the limits for this particular PO (or BundledPO) while being included in the "Bundle". The "Bundle" in its own turn is just a PO (not a BundledPO) with isBundle = true and bundledProductOffering[] array containing one or more BundledPOs.
Could you please tell if I am missing something here?
Thanks
------------------------------
Viktor Aleksandrov
OJSC "VimpelCom"
Original Message:
Sent: Apr 06, 2022 07:55
From: Jonathan Goldberg
Subject: Fields specific info for offerings
Matthieu, thanks for weighing in here. But an important clarification on the SID here, subject to confirmation by @Cecile Ludwichowski:
ProductOffering is an abstract class has two subclasses, SimplePO and BundledPO.
- BundledPO points to other POs, and has no ProductSpecification
- SimplePO has exactly one ProductSpecification
The 1..* relationship in the base (abstract) class is an artificial construct allowing you to represent the totality of specs used in the offering structure. It is in fact (if I understand correctly) what UML terms a derived relationship, in the diagram illustrated by backslash / character (/ProdSpecMadeAvailableAs).
In the API, we prefer to have as few subclasses as possible, and so we collapse these into a single ProductOffering entity, with 0..1 specs.
- If it represents a bundled PO, it will have 0 specs
- If it represents a simple PO, it will have 1 spec
So the Open API precisely follows the SID in this area.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Apr 06, 2022 04:55
From: Matthieu Hattab
Subject: Fields specific info for offerings
Hi,
Using the CharacteristicSpecification/CharacteristicSpecValue pattern is an astute idea because the model is infinitely extensible. We used this technique to support a few business rules in the past but before we knew it, we had hundred of them and it was a maintenance nightware and performance went bad.
This approach will effectively implement your business rule in the productSpecification, not in the productOffering.
Therefore, you will need to create a productSpecification specifically for that productOffering.
If you have 10 productOffering and each one needs its own unique business rule (and dedicated Characteristic), you would have to create 10 productSpecifications. Then you risk technical debt.
This is not the intented purpose of productSpecification (which describe what you want to sell and what functionality and characteristics are available to the market).
A benefit of ProductSpecification is its reusablity: If you create an Internet product specification, you want to use it for all your Internet product offerings.
This being said, SID supports multiple ProductSpecifications (1...*) per product offering, so you could have 1 InternetProdSpec that you use for all Internet product offerings and one additional BizRuleProdSpec just for this one product offering. It still violates the spirit of ProductSpecification but at least you limit the maintenance costs.
But TMF620 does not follow SID guideline in this case and only allows one ProductSpecification per product offering.
Maybe your product Catalogue software could "aggregate" all ProductSpecification before exposing them through the API.
If your requirement is a one-off instance, go ahead with your implementation. but keep an eye so that your implementation don't over use it.
PS: depending on your product Catalogue software, you may have the ability to sub-class productSpecifications and use inheritance to expose ProductSpecification in the API.
------------------------------
Matthieu Hattab
Altibox AS
Original Message:
Sent: Apr 05, 2022 03:36
From: Vojtech Pustowka
Subject: Fields specific info for offerings
Hi Jonathan,
it seems you answered my question. It is actually exactly what we need, to control the UI using optional/mandatory metadata. Now I am more confident that the data we need to store belongs to the characteristics in TMF620.
Thank you for the help.
BR,
Pustowka Vojtech
------------------------------
Vojtech Pustowka
Telia Company
Original Message:
Sent: Apr 03, 2022 10:34
From: Jonathan Goldberg
Subject: Fields specific info for offerings
Hi Vojtech
Can you make your example more explicit? For instance, when you say a field in the order, what do you mean exactly? A characteristic in a product within the order, or an attribute of order/order item? A concrete example would be best if you can manage without leaking Telia IP.
The Open API characteristic model in TMF620 includes, at the spec level, metadata that could be used to control a UI (mandatory/optional, configurable, valid value restrictions, etc.).
Bear in mind that the model is an exposure model, says nothing about internal storage. So perhaps you could use business rules expressed internally, which would run as part of your GET of the offering, and populate the metadata accordingly in the output.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Apr 01, 2022 07:03
From: Vojtech Pustowka
Subject: Fields specific info for offerings
Hi,
we are trying to find a way to store field-specific (sort of UI) info connected with offerings. For example, we have an offering that when ordered has to have a special order field filled. It is mandatory. For other offerings, it might be optional. This info is strictly connected with the offerings. We thought about storing it as a product specification characteristic in the Product Catalog Management API (TMF620). But after reading the API guidelines, this info does not feel like a characteristic.
Does it make sense to store this info in the Product Catalog Management API (TMF620) or is there a more suitable API for providing this information?
Thank you for all the opinions and advice in advance!
Best Regards,
---------------------------------
Vojtech Pustowka
Telia Company
---------------------------------
------------------------------
Vojtech Pustowka
Telia Company
------------------------------