Open APIs

 View Only
Expand all | Collapse all

Handling "recurringChargePeriodType" and "recurringChargePeriodLength" on "ProductOfferingPrice" resource for non recurring prices

  • 1.  Handling "recurringChargePeriodType" and "recurringChargePeriodLength" on "ProductOfferingPrice" resource for non recurring prices

    TM Forum Member
    Posted Mar 01, 2024 06:10

    Hi all,

    While going through TMF 620 Product Catalog Management API User Guide, we could find that there are 2 fields "recurringChargePeriodType" and "recurringChargePeriodLength" on "ProductOfferingPrice" resource.

    As we understand, these fields should never be applicable to non recurring prices.

    How does TMF recommend to handle these scenarios? - Should we be always mentioning both these fields with empty string in TMF Open API request/response or should these be fields be excluded wherever not applicable like in case of non recurring prices?

    Varun Pandhi

  • 2.  RE: Handling "recurringChargePeriodType" and "recurringChargePeriodLength" on "ProductOfferingPrice" resource for non recurring prices

    TM Forum Member
    Posted Mar 05, 2024 07:37

    Hi Varun

    Firstly, an observation. In the Information Framework (the SID), there are many different subclasses of ProductOfferingPrice, with a deep hierarchy, allowing distinguishing between onetime (non-recurring) charges (OC), usage, recurring (RC), discounts, and more. So properties that apply only to RC will be in the appropriate subclass that reflects RC.

    The Open API pattern (in all parts of the model, not just here) is to dispense with extreme normalization and deep class hierarchies, in favor of simplicity. As a side-effect, you will find that some fields are not relevant in all cases.

    I see no reason to place these fields in the payload if they are empty, neither in input nor in output. Let's try to minimize the size of payloads where possible.

    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.