The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.
I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.
In the Swagger of TMF620 I find:
In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.
However, in the Swagger of TMF637 I find:
In particular, ProductRelationship does not contain a "characteristic" attribute.
The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?
Thank you and best regards,
It should probably be added to the inventory API, thanks for the catch Opher.
I looked further into this, there is an existing JIRA for this waiting to be executed.
I am coming back to my original question.
Thank you, @Jonathan Goldberg, for the information.
This JIRA (https://projects.tmforum.org/jira/browse/AP-2928) is indeed related, but seems to be more focused on the RelationshipCharacteristicSpecification in TMF620 than on the RelationshipCharacteristic in TMF637.
The only reference to TMF637 I can find there is this comment at the end:
But I find it confusing, because, as I wrote in my original post, the Swagger of TMF637 does NOT contain RelationshipCharacteristic.
@Matthieu Hattab - with regards to your message: "The inventory API already has references to the Product Offering and Product Specifications, so one could easily find the PS relationships from the product catalogue." I do not exactly understand what you mean. The way I understand it, the common pattern is to have all specifications in Catalog Management, and all instances in Inventory Management. For example, you can have RelatedEntitySpecification in some catalog, and RelatedEntity in the corresponding Inventory. Shouldn't it be the same with RelationshipCharacteristicSpecification/RelationshipCharacteristic?
the product in the inventory has a reference to the Product Specification:
you can query that product spec with TMF620 V5 and then you can see the productspecificationrelationship and the characteristic that refines therelationship.I'm not sure the characteristic that refines the relationship should be instanciated in the product inventory. That characteristic is used to enforce a business rule.if possible we should keep the api payload as lean as possible.Why do you need it for?
Instantiation of such a characteristic addresses your other question. In your example:
A CharacteristicSpecification of the ProdSpecRelationship defines the options of required bandwidth, and an instantiation will define the bandwidth that is actually selected for the specific instance of TVProd.
Does this make sense?
the modification you've done on my diagram would work for TMF620. (I'm hoping Jonathan can confim it because that would mean I need to split my TVProdSpec:
However my model was really for TMF620.do you have a need ot see the characteristic under the productrelationship in TMF637?
My question was rather generic, about the pattern of CharacteristicSpecification under SpecificationRelationship and Characteristic under Relationship. I used TMF620/TMF637 as example, because version 5 of TMF620 has already been released. In the meantime version 5 of TMF634 (resource catalog) has also been released, and it also contains CharacteristicSpecification under SpecificationRelationship.
When I look at inventory management APIs, I see inconsistency. For example, TMF639 (Resource) and TMF637 (Product) do not have Characteristic under Relationship, but TM638 (Service) has:
The one I am really interested with is ResourceSpecification/Resource, but I believe we should adopt the same approach to all similar APIs.
The inventory API already has references to the Product Offering and Product Specifications, so one could easily find the PS relationships from the product catalogue.
I think the inventory should only have references of what customer has acquired (PO, PS, char, charvalues etc) and no data at all (product name, chosen offers, etc) except when the entity is not has a managed entity (like characteristic value) and then use TMF620 to get the accurate data (from product name to relationship etc).Keep the API simple, don't add Characteristic array under the Relationship!Interestingly, the benefit of TMF API is to have data in a single source of truth and avoid data duplication. This particular benefit was actually showcased by TM Forum to illustrate how a a Chinese telecom CSP has used TMF APIs and avoid storing data in different places (TMF said this CSP saved millions of dollars just by reducing data storage needs)
@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:
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.
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: