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.
------------------------------
Original Message:
Sent: Jan 21, 2022 07:58
From: Phil Moss
Subject: TMF677 Usage Consumption API - Conformance question
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
------------------------------