One more observation is that in 620 swagger (in global definitions sections) models for "ProductOfferingPriceRefOrValue" and for "POPCharge" are exact the same apart of the description. ProductOfferingPriceRefOrValue contains also one additional field "@referredType" (obviously needed for the ref pattern).
Somehow, I think that POPCharge is redundant and not used in swagger.
SES Astra S.A.
Original Message:
Sent: Mar 16, 2023 07:23
From: Alen Ruvic
Subject: ProductOfferingPriceCharge versus POPCharge
Hi,
thanks for the explanation.
I have a further/related question.
In 620 swagger in the global definition section there is one Model/Schema defined for POPCharge but it's never referenced via $ref
If you search in the whole 620 swagger for "#/definitions/POPCharge" there is 0 references to it.
I'm trying to understand why there is POPCharge defined separately from ProductOfferingPrice and never referenced.
For example, in the same swagger "POPAlteration" is defined as well but it's at least referenced via
"priceAlteration": {
"type": "array",
"items": {
"$ref": "#/definitions/POPAlteration"
}
},
in ProductOfferingPriceRefOrValue
Br,
------------------------------
Alen Ruvic
SES Astra S.A.
Original Message:
Sent: Mar 16, 2023 02:18
From: Dan d'Albuquerque
Subject: ProductOfferingPriceCharge versus POPCharge
Oh dear, I have opened up a can of worms here ;-)
The ProductOfferingPriceRefOrValue is used to support both ProductOfferingPrice managed entities (by using Ref) and also embedded ProductOfferingPrice resources (by Value). The embedded pricing resources look different from the separately managed, reusable, ProductOfferingPrice entities as, apparently, various operators wanted to keep using the pricing resource representations from earlier versions of the API.
Where it gets a bit confusing is that the embedded subclasses POPCharge (SID ProductOfferingPriceCharge) and POPAlteration (SID ProductOfferingPriceAlteration) are more closely aligned to the example pricing documented in SID. However, the OpenAPI has attempted to simplify the pricing resources by collapsing some of the POPCharge and POPAlterations fields into ProductOfferingPrice and adding a priceType to indicate usage charge, alteration, discount, recurring, etc.
There is no reason why the separately managed entity could not use the same or similar sub-classing though in order to add extension fields.
In terms of how to differentiate between ProductOfferingPrice or POPCharge, you just need to specified the @referredType metadata. ProductOfferingPrice (ref) will have an id, href, name fields and will need to be managed separately (a different POST command). The embedded with use @referredType: POPCharge and have the representation in the ProductOffering section of the document. Clearly the GET on the embedded resources may be returned by reference (or value) too depending on the expand and depth query parameters.
------------------------------
Dan d'Albuquerque
TO BE VERIFIED
Original Message:
Sent: Mar 15, 2023 08:03
From: Alen Ruvic
Subject: ProductOfferingPriceCharge versus POPCharge
Hi,
Very good questions and I have the same.
I would appreciate if someone can clarify it.
@Bostjan Keber Explained here (last post when you scroll down).
TMF620 and productOfferingPriceRelationship | Open APIs (tmforum.org)
how they implemented it.
I wonder how to use/read POPCharge object from the definitions section of the 620 swagger.
When to instantiate POPCharge object and when ProductOfferingPrice?
And how to refer to POPCharge and how to ProductOfferingPrice in ProductOfferingPriceRefOrValue of ProductOffering POST?
620 swagger defines it as:
{
"ProductOfferingPriceRefOrValue": {
"type": "object",
"description": "A new product offering price being created by value or a reference to an existing product offering price that alreasy created. The polymorphic attributes @type, @schemaLocation & @referredType are related to the product offering price and not to this ReforValue structure",
"properties": {
"price": {
"$ref": "#/definitions/ProductPriceValue"
}
}
}
}
It would be very helpful if someone can provide few JSON examples.
Br,
Alen
------------------------------
Alen Ruvic
SES Astra S.A.
Original Message:
Sent: Feb 13, 2023 22:54
From: Dan d'Albuquerque
Subject: ProductOfferingPriceCharge versus POPCharge
Hi All
TMF620 Product Catalog v4.1.0 contains example resource representations containing the new ProductOfferingPriceRefOrValue but with @referredType of ProductOfferingPriceCharge resource, whereas the related OAS for TMF620 contains a schema definition for POPCharge.
"productOfferingPrice": [
{
"id": "1747",
"href": "https://mycsp.com:8080/tmf-api/productCatalogManagement/v4/productOfferingPrice/1747",
"name": "Recurring Monthly Price for Business Firewall",
"@referredType": "ProductOfferingPriceCharge",
"@type": "ProductOfferingPriceRefOrValue",
"@baseType": "",
"@schemaLocation": "https://mycsp.com:8080/tmfapi/schemas/Product/ProductOfferingPriceRefOrValue.schema.json"
}
Is this just a typo in the example resource representations?
Just also noticed that the recurringChargePeriodType has been renamed as recurringChargePeriod as well in the description.
There is also an multi-valued association to POPAlteration called PriceAlteration in the new ProductOfferingPriceRefOrValue description which is not referred to in the ProductOfferingPrice section in the document. Isn't this meant to be the popRelationship (ProductOfferingPriceRelationship)?
Thanks
------------------------------
Dan d'Albuquerque
TO BE VERIFIED
------------------------------