Open APIs

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

Thank you Sir for your feedback,

Irrespective of whether we follow API based/publish model, the downstream systems (like billing, charging) are expected to import/expose API's (in conformance with TMF620) to capture relevant catalogue resources into the local catalogue. Is this understanding correct?

Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

The whole area of catalog federation, which is effectively what you are discussing, is actually rather complex. TM Forum has a rather aged white paper on that, which I think largely predates the Open API effort (I don't have the reference to hand, perhaps @Dave Milham can assist).

Conceptually at least, you could run an ExportJob in the master catalog, and then an ImportJob in your slave catalogs - both of these task resources are specified in TMF620 swagger and user guide.

Hope it helps.

Thank you Sir for your feedback,

Irrespective of whether we follow API based/publish model, the downstream systems (like billing, charging) are expected to import/expose API's (in conformance with TMF620) to capture relevant catalogue resources into the local catalogue. Is this understanding correct?

Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

The whole area of catalog federation, which is effectively what you are discussing, is actually rather complex. TM Forum has a rather aged white paper on that, which I think largely predates the Open API effort (I don't have the reference to hand, perhaps @Dave Milham can assist).

Conceptually at least, you could run an ExportJob in the master catalog, and then an ImportJob in your slave catalogs - both of these task resources are specified in TMF620 swagger and user guide.

Hope it helps.

Thank you Sir for your feedback,

Irrespective of whether we follow API based/publish model, the downstream systems (like billing, charging) are expected to import/expose API's (in conformance with TMF620) to capture relevant catalogue resources into the local catalogue. Is this understanding correct?

Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

AS per Jonathan's comment:
Catalog  federation was addressed in this early document: 

GB978 Catalog to Catalog Interface R17.5.1

The reason this happened at least in the past is multiple Catalogs embedded in CRM, Ordering and billing applications that needed to be synchronised. It is possible that this is avoided with use of ODA Components but may still be needed with Open APIs added to best of breed applications.

We touched on this also in the early ODA Architecture work. see IG1222 Part 4: ODA Technical Architecture ODA Patterns v1.0.0 - Published Deliverables - TM Forum Confluence  Sections 2 3 and especially section 4.

The whole area of catalog federation, which is effectively what you are discussing, is actually rather complex. TM Forum has a rather aged white paper on that, which I think largely predates the Open API effort (I don't have the reference to hand, perhaps @Dave Milham can assist).

Conceptually at least, you could run an ExportJob in the master catalog, and then an ImportJob in your slave catalogs - both of these task resources are specified in TMF620 swagger and user guide.

Hope it helps.

Thank you Sir for your feedback,

Irrespective of whether we follow API based/publish model, the downstream systems (like billing, charging) are expected to import/expose API's (in conformance with TMF620) to capture relevant catalogue resources into the local catalogue. Is this understanding correct?

Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

Thank you Sir for your feedback,

Irrespective of whether we follow API based/publish model, the downstream systems (like billing, charging) are expected to import/expose API's (in conformance with TMF620) to capture relevant catalogue resources into the local catalogue. Is this understanding correct?

------------------------------
Janakiram Renganathan
OMANTEL

Original Message:
Sent: Feb 28, 2024 10:47
From: Jonathan Goldberg
Subject: TMF620 and Billing Catalogue

Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.

------------------------------
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: Feb 28, 2024 01:05
From: Janakiram Renganathan
Subject: TMF620 and Billing Catalogue

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

------------------------------
Janakiram Renganathan
OMANTEL
------------------------------

Hi Janakiram,

Conceptually you are right. And more important than the API structure is the topic of federation and the decisions to be made around the first point of PO creation. There are various approaches.

One approach can be the way you described. And there are slightly different ones where in mass market retail scenarios with frequent price changes and launch of time based promotions a slightly different approach for federation is followed. 

Once this is decided, the mapping of the entities between the UPC and Billing and the attributes needs to be done.

Regards,

------------------------------
Sri-Jagadish (Jag) Baddukonda
Bell Canada

Original Message:
Sent: Feb 29, 2024 02:42
From: Janakiram Renganathan
Subject: TMF620 and Billing Catalogue

Thank you Sir for your feedback,

Irrespective of whether we follow API based/publish model, the downstream systems (like billing, charging) are expected to import/expose API's (in conformance with TMF620) to capture relevant catalogue resources into the local catalogue. Is this understanding correct?

------------------------------
Janakiram Renganathan
OMANTEL

Original Message:
Sent: Feb 28, 2024 10:47
From: Jonathan Goldberg
Subject: TMF620 and Billing Catalogue

Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.

------------------------------
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: Feb 28, 2024 01:05
From: Janakiram Renganathan
Subject: TMF620 and Billing Catalogue

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

------------------------------
Janakiram Renganathan
OMANTEL
------------------------------

@Sri-Jagadish (Jag) Baddukonda

Thanks for responding,

This is for consumer/residential related product offering/catalogue.

If a billing vendor claims that his platform is in conformance to ODA/Open API's and the platform also has API's to accept the product federation/cascading from UPC, then is it appropriate for me to expect this API to follow/adhere to TMF620 resource model/entity structure?

Hi Janakiram,

Conceptually you are right. And more important than the API structure is the topic of federation and the decisions to be made around the first point of PO creation. There are various approaches.

One approach can be the way you described. And there are slightly different ones where in mass market retail scenarios with frequent price changes and launch of time based promotions a slightly different approach for federation is followed. 

Once this is decided, the mapping of the entities between the UPC and Billing and the attributes needs to be done.

Regards,

------------------------------
Sri-Jagadish (Jag) Baddukonda
Bell Canada

Original Message:
Sent: Feb 29, 2024 02:42
From: Janakiram Renganathan
Subject: TMF620 and Billing Catalogue

Thank you Sir for your feedback,

Irrespective of whether we follow API based/publish model, the downstream systems (like billing, charging) are expected to import/expose API's (in conformance with TMF620) to capture relevant catalogue resources into the local catalogue. Is this understanding correct?

------------------------------
Janakiram Renganathan
OMANTEL

Original Message:
Sent: Feb 28, 2024 10:47
From: Jonathan Goldberg
Subject: TMF620 and Billing Catalogue

Seems reasonable in general, but I'm not sure that it is OK to expect a UPC to deliver a tailored subset to each possible downstream system. To me, it makes more sense that UPC publishes a full model, and each downstream system takes what information it needs.

------------------------------
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: Feb 28, 2024 01:05
From: Janakiram Renganathan
Subject: TMF620 and Billing Catalogue

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

------------------------------
Janakiram Renganathan
OMANTEL
------------------------------

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

Hi

@Janakiram Renganathan Not clear for me why billing/charging system would need to expose TMF620 Product Catalog API. I don't yet see any other ODA component than TMFC001 Product Catalog that exposes this API. I'm interested in understanding the need.

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream

hope this is more clear now.....So if a billing vendor claims that their platform is exposing open API's in conformance with TMF, I expect that platform to following TMF620 for product related aspects

Hi

@Janakiram Renganathan Not clear for me why billing/charging system would need to expose TMF620 Product Catalog API. I don't yet see any other ODA component than TMFC001 Product Catalog that exposes this API. I'm interested in understanding the need.

1. Business user creates a product offering from Unified product catalogue (UPC)
2. As per TMF620, UPC will export and publish this change in UPC; However, in our ecosystem, all downstream applications are asked to publish catalogue API's so that UPC can invoke the API's in real time and cascade the product information (create/modify/update))
3. Our understanding is that the catalogue API's exposed by the billing/charging system is also expected to adhere to the same TMF620 guidelines (with same resource model - productOffering, productSpecification, productOfferingPrice, productTerm, etc.) and UPC will send only the relevant info to the downstream