Hello Rupen,
I'd like to propose an alternative based on our current implementation.
First, I would be cautious using TMF620's "configurable" to represent "visible" because:
- "Configurable" is static (its value doesn't change at runtime), whereas you need a dynamic attribute (true/false value changes based on client context or business rules).
- "Configurable" and "visible" convey different information, according to TMF definitions, and you likely need both.
- TMF620 is a Ressource API, it's a dumb data store that only allows you to GET data.
We heavily inspire our architecture based on recommendation from IG1228. we use TMF760 to expose products and product offerings with "configurable characteristics and characteristics values". TMF760 provides more granularity and is a Task API:
{"ConfigurationCharacteristic":[{"name":"Bandwidth","isConfigurable":true,"isVisible":true,"configurationCharacteristicValue":[
{"isSelectable":false,"isSelected":false,"isVisible":false,"name":"5000/5000 Mbits"},
{"isSelectable":true,"isSelected":true,"isVisible":true,"name":"1000/1000 Mbits"},
{"isSelectable":true,"isSelected":false,"isVisible":true,"name":"750/750 Mbits"}]}]}
In TMF760, attributes values are dynamic; their visibility and configurability depend on use cases.
Examples:
- At char level:
- In a contract renewal (ConfigurationAction=Renew), the SSID characteristic is
"isConfigurable": false
(customer cannot change their phone number during renewal) but remains "visible".
- In a new sales scenario (ConfigurationAction=Add), the SSID characteristic is
"isConfigurable": true
, allowing customers to port their existing number or choose a new one.
- At char value level:
- When we sell FTTH, visibility and selectability of bandwidth values or are contingent on TMF645 SQ results: "visible=false" and "isSelectable=false" if ineligible (red), but opposite if eligible (green or orange).
My opinion is that TMF APIs should remain unbiased/unopiniated. If your visibility needs are UX-focused rather than rule-based, I endorse Jonathan's suggestion to consider a (headless) CMS, as UX is outside core commerce functions and aligns with party management ODA block. In that case, you need a layer (DXO, DXC, BFF...) to add an opinion on top of the TMF API.
There are other options depending on requirements
My two cents.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
------------------------------
Original Message:
Sent: Jun 24, 2024 04:48
From: Rupen Dewan
Subject: TMF 620 Product Catalog Attribute visibility
Hi All,
Is there a characteristic to control product attribute visibility in TMF 620?
I presume product specification characteristics should control whether the attribute needs to be made visible whilst selling or can be visible and/or editable for regrade scenarios.
------------------------------
Regards,
Rupen Dewan
Tata Consultancy Services
------------------------------