the graphical example between TV Char values and Broadband char Value is indeed not supported, as confirmed above by Jonathan:
The way the characteristic relationship is currently defined for APIs, I don't think it meets your needs. It gives you a connection between characteristics, not between their values
On policy, while there is no "Policy" ODA component, yet, TMF describes the Policy Information model in great details:
- GB922- common has a complete chapter on policy, see "4.21. Policy ABE"
- GB922 - product has an complex pricing example of using policy. See "Figure Pr.14 - Product Offering Price Governed by Policy and subsequent pages."
So what's the goal/purpose of productSpecificationRelationship - characteristic? Could you please provide an example?
PS=ProductSpecification
let's define this ProductSpecificationRelationship: PS1 requires PS2
The CharacteristicSpecification under ProductSpecificationRelationship would represent the characteristics of the ProductSpecification involved in the relationship (either PS1 or PS2).
Based on the Swagger YAML file and the user guide, we cannot explicitly state which CharacteristicSpecification relates to which ProductSpecification (PS1 or PS2) in the relationship.
Specifically, when we say "PS1 requires PS2", it could mean 2 things for the CharacteristicSpecification:
-
- PS1 (the
ProductSpecification that requires another) may have certain characteristics that are required (in the case of a "requires" relationshipType) by PS2.
- Or, PS2 might contain characteristics that PS1 depends on. In this case, the
CharacteristicSpecification would represent the characteristics of PS2 that are necessary for PS1 to be valid or usable.
the only question left is to determine if the list of CharacteristicSpecification belong to PS1 or PS2. I think your implementation can make that decision, according to your needs.
As I'm not a developer and have little clue on this, I asked a generative AI to help identify best practices, common patterns in the API dev community that could help me understand if CharacteristicSpecificationentity belong to PS1 or PS2. Here is the answer:
If we were to make an educated guess based on common patterns used in APIs and the structure of relationships in similar domain models, here's how we might reason about which ProductSpecification the CharacteristicSpecification is related to in the context of a ProductSpecificationRelationship:
-
Pattern of Dependency Relationships:
- In many APIs, when there is a dependency between two entities, like PS1 requires PS2, the dependent entity (PS1) often needs the characteristics of the referred-to entity (PS2).
- In this case, PS1 requires PS2, so the characteristics that are relevant to PS1 would likely be the ones associated with PS2. This makes sense because PS1 might depend on certain attributes or features from PS2 in order to function properly.
-
Characteristics and data Ownership:
- Generally, characteristics are defined by the entity they belong to. If an entity (like PS1) requires another (like PS2), the characteristics specified in the required entity (PS2) are those that are needed by the requesting entity (PS1).
-
Standard API Modeling for Relationships:
- In APIs that define relationships between entities (e.g., dependencies, inclusions, exclusions), the characteristics of the secondary entity (PS2) are often the ones that are explicitly stated or referenced in the relationship.
- For example, in a product catalog API, if a product (PS1) requires another product (PS2), the characteristics of PS2 would likely be important to the functionality of PS1.
Based on my original diagram, I could then say:
TVProductSpec requires FiberBroadbanSpec with Bandwidth Char = {250 mbps...1000 mbps}...
...which could look like this (I simplified the TMF620 payload):
{
"name": "PS1",
"productSpecificationRelationship": [
{
"characteristic": [
{
"name": "Bandwidth",
"productSpecCharacteristicValue": [
{
"name": "Bandwidth",
"values": [
"250 Mbps",
"500 Mbps",
"750 Mbps",
"1000 Mbps"
]
}
]
}
],
"name": "PS2",
"relationshipType": "requires"
}
]
}
I now use the concept of policy for these kind requirements... It's just easier.
Have fun.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Tele AS
------------------------------
Original Message:
Sent: Feb 06, 2025 10:26
From: Jan Brnka
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs
Thank you Matthieu for the answer! Very useful and comprehensive (as always :) ).
The conclusion for me is that the example of "relationship between broadband and TV" is not covered by productSpecificationRelationship - characteristic. So what's the goal/purpose of productSpecificationRelationship - characteristic? Could you please provide an example?
Regarding the TMF Policy Component, I was unable to find detailed information. I did come across the TMF723 Policy Management API and found the Swagger file, but there is not a corresponding user guide. Although I found a brief reference in the GB922 documents, there was no concrete example like in other user guides. Could you please provide an example, particularly one illustrating the "broadband and TV" scenario?
------------------------------
Jan Brnka
T-Mobile Czech & Slovak Telekom, a.s.
------------------------------
Original Message:
Sent: Feb 04, 2025 05:41
From: Matthieu Hattab
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs
Hi,
As the TMF Product Catalogue only supports simple business rules, we opted not to use it for storing our business rules. Over time, we've realised that it has too many gaps and compromises, making it unsuitable for our needs.
Currently, all our business rules are implemented in code within TMF components such as the Product Configurator, Product Offering Qualification, Service Qualification, and Product Recommendation. However, this approach is not scalable.
We are actively investigating external rule engines, potentially something similar to the ECA model from the TMF Policy component. A dedicated policy component could support product, pricing, and eligibility rules without the constraints of the TMF Product Catalogue. Rules can be stored with Decision table, FEEL language which are a low-code/no-code solutions to manage rules' conditions.
Tools under consideration:
- Gorules
- Drools/Kogito/jBPM/OptaPlanner (suite)
- OpenRules
- Nected
- Camunda DMN
- ...
A key issue is that these rule engines are not self-contained. They require all relevant facts to be provided upfront in the API request, which violates TMF API compliance. One of the core ODA component principles is that they must be self-contained. And TMF API are not designed to provide relevant facts upfront in the API POST request.
To address this, we may need a hybrid approach, combining a rule engine with an event-driven orchestrator (e.g., n8n, Node-RED, Camunda, or Apache NiFi) to handle "missing" facts. Alternatively, we could implement built-in dynamic fact retrieval within the rule engine. Some developers have also suggested using introspection.
It's a complex challenge.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Tele AS
Original Message:
Sent: Feb 04, 2025 02:27
From: Jan Brnka
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs
Hi @Matthieu Hattab.
I was looking for any topic regarding productSpecificationRelationship - characteristic and found this discussion. Unfortunately your last question is not answered. Have you found the way how to model the relationship between broadband and TV since your last post?
------------------------------
Jan Brnka
T-Mobile Czech & Slovak Telekom, a.s.
Original Message:
Sent: Dec 04, 2023 11:17
From: Matthieu Hattab
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs
Hi,
the defintion in the API user guide says:
A characteristic that refines the relationship. For example, consider the relationship between broadband and TV. For a 4k TV it is important to know the minimum bandwidth to support 4k, so a characteristic Resolution might be defined on the relationship to allow capturing of this in the inventory
do you have a working illustration of the above definition?
I can't find a way to model the example provided in the user guide:
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Nov 29, 2023 15:05
From: Jonathan Goldberg
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs
Hi Matthieu
The way the characteristic relationship is currently defined for APIs, I don't think it meets your needs. It gives you a connection between characteristics, not between their values. The SID takes this one level further and gives you a relationship between characteristic spec values.
------------------------------
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: Nov 28, 2023 18:12
From: Matthieu Hattab
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs
@Jonathan Goldberg,
Using the characteristic relationship between ProductSpecificationRelationship and CharacteristicSpecification and the provided description, does it support creating relationship between charvalues of 2 different ProdSpec? Using the textual example in the API documentation, can we achieve this:
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Nov 26, 2023 07:46
From: Jonathan Goldberg
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs
It should probably be added to the inventory API, thanks for the catch Opher.
------------------------------
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.