Open APIs

Hi,

As the TMF620 specification says, Product Offering elements exist independently of the catalog(s),  so what should happen to the elements exposed by a catalog when its status (LifecycleStatus) move from, for instance from "Launched" to "Retired"?

Also, what is the purpose of the version property? Lets says we have a catalog in version 1, does it mean that, by design, it will only expose elements that are at the same version?

Hi Anselme

Great questions, I don't have a firm answer, only my intuition. So ...

The lifecycles of the catalog items (offering, price, spec) are independent of the catalog(s) that expose(s) them. So if you decide to retire a catalog, this has no effect on the items exposed there, since they can continue to be exposed in other catalogs.

I would not read too much significance into Catalog.version - but it's up to you as an API implementor to decide otherwise.

Hi,

As the TMF620 specification says, Product Offering elements exist independently of the catalog(s),  so what should happen to the elements exposed by a catalog when its status (LifecycleStatus) move from, for instance from "Launched" to "Retired"?

Also, what is the purpose of the version property? Lets says we have a catalog in version 1, does it mean that, by design, it will only expose elements that are at the same version?

Hi,

As the TMF620 specification says, Product Offering elements exist independently of the catalog(s),  so what should happen to the elements exposed by a catalog when its status (LifecycleStatus) move from, for instance from "Launched" to "Retired"?

Also, what is the purpose of the version property? Lets says we have a catalog in version 1, does it mean that, by design, it will only expose elements that are at the same version?

There are multiple benefits of using catalogue life cycle (state and validfor). Some examples I've seen and used:

• spring/summer, year xxxx collection: such catalogue could represent product offerings that should only be available during a certain time of year.
• when product offerings selling period is different per sales channel, segment, etc
• when you need catalogue specific prices (this is designed in SID but not in API, though)
• in a B2B context, you can define a product catalogue for a specific customer or group of customers for a certain period of time (framework agreement)

You can consider the catalogue lifecycle as a lifecycle for a group of product offerings. It's so much easier to manage the lifecycle of a collection of product offering rather than at individual product offerings. Especially when product offerings simultaneously need different lifecyles.

I've also seen catalogue category lifecycle.

as for versioning, it's very useful if you use federated catalogues, or if you syncronise catalogues with your suppliers, distributors, your partners, with other systems. With versioning, there is a path to rollback.
The API documentation has several use cases on how to use lifecycle.

Hi,

As the TMF620 specification says, Product Offering elements exist independently of the catalog(s),  so what should happen to the elements exposed by a catalog when its status (LifecycleStatus) move from, for instance from "Launched" to "Retired"?

Also, what is the purpose of the version property? Lets says we have a catalog in version 1, does it mean that, by design, it will only expose elements that are at the same version?