Open APIs

 View Only
  • 1.  TMF677 Usage Consumption API - Conformance question

    TM Forum Member
    Posted Jan 21, 2022 08:54

    Hi All,


    We're implementing the Usage Consumption API and looking for a little clarification to help scope our initial solution.


    The specification contains 2 resources: 

    • UsageConsumptionReport (Mandatory)
    • UsageConsumptionReportRequest (Optional)

    We aim to support synchronous generation of Usage Consumption Reports and so at this point plan to implement UsageConsumptionReport only (given UsageConsumptionReportRequest is for async generation).


    The scoping question we have is whether we need to store previous synchronously generated Usage Consumption reports for subsequent retrieval. The Conformance Profile document includes wording which suggests this is optional:

    • "We could accept to use a GET operation in this context because the server calculates the data given in the usage consumption report without necessarily store it"
    • "This operation could be used only if the server has recorded the usage consumption report on its database after calculation."

    On the other hand, the operation which supports the retrieval of historic UsageConsumptionReports (GET /USAGECONSUMPTIONREPORT /{ID}?FIELDS=…&{FILTERING} ) appears to be mandatory. We'd ideally like to avoid storing these reports as the data is already returned in the API response. 


    Any advice here would be greatly appreciated.

    Phil Moss
    MATRIXX Software

  • 2.  RE: TMF677 Usage Consumption API - Conformance question

    TM Forum Member
    Posted Jan 23, 2022 04:59
    Hi Phil
    The Usage Consumption API includes is an example of what we refer to as Task operations (i.e. something that can't be expressed by the CRUD verbs of HTTP). You initiate a task by POSTing the task resource.
    Tasks can be executed synchronously or asynchronously - clearly an asynchronous task must be persisted at least until the task is complete. A synchronous task may or may not be persisted, that would be an implementation choice when implementing the API.
    Specifically for Usage Consumption, perhaps we have a logical inconsistency in the conformance, referring to @Lara Silva and @Steve Harrop for additional comment.
    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.

  • 3.  RE: TMF677 Usage Consumption API - Conformance question

    TM Forum Member
    Posted Jan 24, 2022 12:31
    There are three TMF APIs in this "area":
    1. Usage: Like the CDR, this is the Usage record, created by Services and Resources being ...used. This API also exposes the UsageSpecification - that defines the structure of a Usage record for (say) a voice-call, different to a Web page visit or an SMS sent.
    2. UsageConsumption: This is implemented by the OCS/CCS which processes/rates the Usage and provides the snapshot of bucket balances.
    3. PrepayBalance: This is a bit of a misnomer now that we know that buckets are not only used for "prepay phones", but it allows you to transfer value into bucket balances.

    I would have expected the UsageConsumption to only be expected to hold a "snapshot in time" of the bucket balances - and I can't think of a "get a historic snapshot" use-case, so I agree with @Jonathan Goldberg that ​​something is not quite right. To comply to the current specification - maybe you could implement the GET /USAGECONSUMPTIONREPORT /{ID} - but only cache it for a couple of seconds (in case there is a short-term burst of interest in that report), before returning a 404?

    Stephen Harrop
    Integration Architect
    Vodafone Group

  • 4.  RE: TMF677 Usage Consumption API - Conformance question

    TM Forum Member
    Posted Jan 24, 2022 12:55
    Hi @Jonathan Goldberg, @Steve Harrop​​,

    Thanks for the feedback - your responses align with our thinking. I'll take this back internally to determine how to proceed.

    Phil Moss
    MATRIXX Software