Hi Abel
I would actually say the opposite :) (no emojis in this editor):
- There is no need to embed the value of a non-configurable characteristic within a Product (Service, Resource) Order (or within the PSR inventory), since its value can be deduced at all times from the catalog definition. Of course a specific implementation will likely choose to embed the value in the order (and in the inventory) as an optimization to avoid repeated calls to catalog GETs
- The value of a configurable characteristic must be embedded within the PSR Order (certainly if it differs from the default value, or if there is no default value), since how else will the value be known.
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: Sep 30, 2021 05:49
From: Abel Ruiz
Subject: 'Configurable' attribute in catalog APIs
Hi Jonathan,
So, thinking like an order management system, we might consider that:
- If a characteristic is non-configurable, it's value must be explicitly provided in the order, and that value will never change during the order execution.
- If a characteristic is configurable, means that it won't be present in the order, and its value will be calculated on the fly i.e., during the execution of the order.
Therefore, if the order management system runs a validation process to decide whether the order received through the API is acknowledged or rejected, if should check that:
- Non-configurable characteristics must be present in the order.
- Configurable characteristics must not be present in the order.
Am I right?
Thanks a lot for your answers.
Best regards,
------------------------------
Abel Ruiz
SATEC GROUP
Original Message:
Sent: Aug 15, 2021 06:16
From: Jonathan Goldberg
Subject: 'Configurable' attribute in catalog APIs
Hi Abel
Configurable means that at runtime, when the corresponding inventory object is instantiated, the value of the characteristic. For example:
- color characteristic of a set-top box product is unlikely to be configurable, since the color cannot be changed (this does depend on modeling strategy of variant tangible goods, so let's not go
- bandwidth characteristic of broadband product will typically be configurable, since the end-customer can choose which bandwidth she wants, the price will likely change as a result (again, this can depend on modeling strategy).
Why is it not in the SID, I have no idea. Maybe @Cecile Ludwichowski can enlighten?
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: Aug 12, 2021 11:06
From: Abel Ruiz Huerta
Subject: 'Configurable' attribute in catalog APIs
Hi Community,
I have a couple of doubts regarding the boolean attribute named 'configurable', used in the CharacteristicSpecification sub-resource of the product, service and resource catalog APIs:
- I didn't find such attribute in the Product/Service/ResourceSpecCharacteristic classes in SID. There is unique, there is extensible, etc. but there is no configurable. Is this for some reason, or just a mistake?
- The description of this attribute in the API documents is: A boolean. If true, the Boolean indicates that the target Characteristic is configurable. But, what does that mean exactly?
Thanks in advance for your answers.
Best regards,
------------------------------
Abel Ruiz Huerta
SATEC GROUP
------------------------------