Open APIs

Hi All,


------------------------------
shubham saraswat
Hansen Technologies
------------------------------

Hi Shubham
validFor is a time period, either constrained at both ends (start and end are both populated) or open-ended (only one of start or end is populated).
The time period refers to the entity itself, but of course the interpretation will vary for each entity.
In your example, let's suppose that you have a sales effective period for each product offering - the validFor for product offering will perfectly fit this.

For the validity of a product in the inventory (owned by customer), I can think of these possibilities why the lifetime might be limited:

• The product has a limited lifetime since it is a promotion or other special offer that applies (say) for only three months after initial purchase/installation
• The product has a limited lifetime since the customer asked for termination in advance, e.g. communication services for an exhibition
• The product has a limited lifetime since it is a promotion or other special offer that applies (say) only until a certain date (for all customers, regardless of purchase date)
• The underlying network will no longer support the product after a certain date so the product needs to be terminated or upgraded

For the first two cases, there is no meaning for a validity period at the catalog level, since it will be different for each product in the inventory. For the last case, you could express this with a validity period on the product specification. So we are left just with the third case, which I am not sure how to model at the catalog level, but I am not sure if this is a real business case anyway.

P.S. note that product inventory does not currently have a validFor attribute, you could add it as an extension.

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.
------------------------------

Hi,

I follow the concept that validFor indicates the period that the productOffering/productOfferingPrice/productSpecification is available for purchase.
This interpretation means that the validFor is thighly linked to the lifecycleStatus.

One solution is therefore to have an automated timestamp management:

• validFor.startDateTime: receives an timestamp when the lifecycleStatus transitions to "active" (or "launched" ?)
• validFor.endDateTime: receives an timestamp when the lifecycleStatus transitions to "retired"

Using this approach means the dates are internally managed in the catalog and probably should be read-only.

An alternative approach for a catalog that supports scheduling is to allow users of the API write the valdFor dates as a way to schedule the lifecycleState transition in the future. The catalog application can then perform the transition autonomously.

The TM-Forum does currently not prescribe any of these approaches.

Regards

------------------------------
Koen Peeters
OryxGateway
------------------------------

Original Message:
Sent: Mar 15, 2022 03:15
From: Jonathan Goldberg
Subject: TMF620 - Clarification on the attribute "validFor"

Hi Shubham
validFor is a time period, either constrained at both ends (start and end are both populated) or open-ended (only one of start or end is populated).
The time period refers to the entity itself, but of course the interpretation will vary for each entity.
In your example, let's suppose that you have a sales effective period for each product offering - the validFor for product offering will perfectly fit this.

For the validity of a product in the inventory (owned by customer), I can think of these possibilities why the lifetime might be limited:

• The product has a limited lifetime since it is a promotion or other special offer that applies (say) for only three months after initial purchase/installation
• The product has a limited lifetime since the customer asked for termination in advance, e.g. communication services for an exhibition
• The product has a limited lifetime since it is a promotion or other special offer that applies (say) only until a certain date (for all customers, regardless of purchase date)
• The underlying network will no longer support the product after a certain date so the product needs to be terminated or upgraded

For the first two cases, there is no meaning for a validity period at the catalog level, since it will be different for each product in the inventory. For the last case, you could express this with a validity period on the product specification. So we are left just with the third case, which I am not sure how to model at the catalog level, but I am not sure if this is a real business case anyway.

P.S. note that product inventory does not currently have a validFor attribute, you could add it as an extension.

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.
------------------------------

Since the topic is raised, I had this question in a corner of my head.
I had a customer with the following product ABE dates, that didn't want to bother with a status field.

Quotable Start Date + End Date
Sellable Start Date + End Date
warranty Start Date + End Date
Serviceable Start Date + End Date
End of life End Date

could we model these with entitySpecification pattern?

------------------------------
Matthieu Hattab
Altibox AS
------------------------------

Original Message:
Sent: Mar 15, 2022 06:18
From: Koen Peeters
Subject: TMF620 - Clarification on the attribute "validFor"

Hi,

I follow the concept that validFor indicates the period that the productOffering/productOfferingPrice/productSpecification is available for purchase.
This interpretation means that the validFor is thighly linked to the lifecycleStatus.

One solution is therefore to have an automated timestamp management:

• validFor.startDateTime: receives an timestamp when the lifecycleStatus transitions to "active" (or "launched" ?)
• validFor.endDateTime: receives an timestamp when the lifecycleStatus transitions to "retired"

Using this approach means the dates are internally managed in the catalog and probably should be read-only.

An alternative approach for a catalog that supports scheduling is to allow users of the API write the valdFor dates as a way to schedule the lifecycleState transition in the future. The catalog application can then perform the transition autonomously.

The TM-Forum does currently not prescribe any of these approaches.

Regards

------------------------------
Koen Peeters
OryxGateway
------------------------------


Original Message:
Sent: Mar 15, 2022 03:15
From: Jonathan Goldberg
Subject: TMF620 - Clarification on the attribute "validFor"

Hi Shubham
validFor is a time period, either constrained at both ends (start and end are both populated) or open-ended (only one of start or end is populated).
The time period refers to the entity itself, but of course the interpretation will vary for each entity.
In your example, let's suppose that you have a sales effective period for each product offering - the validFor for product offering will perfectly fit this.

For the validity of a product in the inventory (owned by customer), I can think of these possibilities why the lifetime might be limited:

• The product has a limited lifetime since it is a promotion or other special offer that applies (say) for only three months after initial purchase/installation
• The product has a limited lifetime since the customer asked for termination in advance, e.g. communication services for an exhibition
• The product has a limited lifetime since it is a promotion or other special offer that applies (say) only until a certain date (for all customers, regardless of purchase date)
• The underlying network will no longer support the product after a certain date so the product needs to be terminated or upgraded

For the first two cases, there is no meaning for a validity period at the catalog level, since it will be different for each product in the inventory. For the last case, you could express this with a validity period on the product specification. So we are left just with the third case, which I am not sure how to model at the catalog level, but I am not sure if this is a real business case anyway.

P.S. note that product inventory does not currently have a validFor attribute, you could add it as an extension.

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.