Open APIs

Hello Team,

We have below usecases and both the TMF 654 and TMF 677 is able to cater to the usecases especially related to bucketing operations.
The usecases for TMF 677 is more of a querying and have no capability to create buckets ( as no POST operations to create one )  and TMF 654 has the feature to create the buckets and perform other monetary operations.  From TMF 677 the advantage seen is it has more than one counter's for each bucket, unlike in TMF 654.

Below are our possible usecases : 

* add bucket 
* update bucket 
* search bucket
* update balance

Request to provide any sequence flows or nay detailed material on the usecases.

------------------------------
Kartik N Maringanti
Verizon
------------------------------

TMF635 specifically relates to prepay buckets or balances, and the operations there support all the common manipulations needed on a prepay balance (topping up, reserving, transferring, etc.).
TMF677 is a read-only API that gives a wider picture of the customer's usage.
The two APIs do not overlap, at least not intentionally.
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.
------------------------------

Thank you @Jonathan Goldberg

But the currently we have operations to add, update ( though TMF 654 does not support it on bucket )  and delete ​on bucket, the difference we have seen is, TMF 677 has support to multiple counters and TMF 654 does not have it. So if we want to support above features then we are to go with TMF 654. But if we want to have multiple counters also, then our thought was to go with the extension of TMF 654 Bucket and support by composing one more many ConsumptionSummary schema. 

Can we say that the TMF677 domain, since its a query only, does this query the data from the tables where the data of TMF 654 events are parsed and stored ?

Let know if our understanding is correct. 


------------------------------
Kartik N Maringanti
Verizon
------------------------------

Original Message:
Sent: Jan 09, 2023 07:16
From: Jonathan Goldberg
Subject: TMF 654 vs TMF 677

TMF635 specifically relates to prepay buckets or balances, and the operations there support all the common manipulations needed on a prepay balance (topping up, reserving, transferring, etc.).
TMF677 is a read-only API that gives a wider picture of the customer's usage.
The two APIs do not overlap, at least not intentionally.
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.
------------------------------

Hi Kartik, 

We have also noticed similarities between the two APIs and trying to work out the differences. The only use cases I have found are the ones in the API docs. 654 is currently undergoing a review to fix bugs and some smaller improvements and although it is called Prepay today, the central part of this API is the management of buckets no matter what customer type. We also noted a data model issue with it that we have reported in another thread  found here. 

I would like to better understand your issue with the multiple counters to be able to assess and see if we should post this as an issue/improvement and fix it as a global issue. Can you elaborate on the extension and point out the limitations you are struggling with? If it is easier, I am up for a chat. 

Thank you, 
Elisabeth

------------------------------
Elisabeth Andersson
MATRIXX Software
------------------------------

Original Message:
Sent: Jan 09, 2023 07:25
From: kartik maringanti
Subject: TMF 654 vs TMF 677

Thank you @Jonathan Goldberg

But the currently we have operations to add, update ( though TMF 654 does not support it on bucket )  and delete ​on bucket, the difference we have seen is, TMF 677 has support to multiple counters and TMF 654 does not have it. So if we want to support above features then we are to go with TMF 654. But if we want to have multiple counters also, then our thought was to go with the extension of TMF 654 Bucket and support by composing one more many ConsumptionSummary schema.

Can we say that the TMF677 domain, since its a query only, does this query the data from the tables where the data of TMF 654 events are parsed and stored ?

Let know if our understanding is correct.


------------------------------
Kartik N Maringanti
Verizon
------------------------------


Original Message:
Sent: Jan 09, 2023 07:16
From: Jonathan Goldberg
Subject: TMF 654 vs TMF 677

TMF635 specifically relates to prepay buckets or balances, and the operations there support all the common manipulations needed on a prepay balance (topping up, reserving, transferring, etc.).
TMF677 is a read-only API that gives a wider picture of the customer's usage.
The two APIs do not overlap, at least not intentionally.
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.

Hi Elisabeth,

The concern is with the buckets primarily, where in we have possibility of multiple counters for data & sms and as you also faced the same, for 654, cardinality is only 1. If cardinality is more than 1, it would be easier to have multiple counters. But considering the 677 and the 654 GET bucket API's, was thinking to feel some similarities. Yes we could get it to the notice.

------------------------------
Kartik N Maringanti
Verizon
------------------------------

Original Message:
Sent: Jan 10, 2023 04:14
From: Elisabeth Andersson
Subject: TMF 654 vs TMF 677

Hi Kartik,

We have also noticed similarities between the two APIs and trying to work out the differences. The only use cases I have found are the ones in the API docs. 654 is currently undergoing a review to fix bugs and some smaller improvements and although it is called Prepay today, the central part of this API is the management of buckets no matter what customer type. We also noted a data model issue with it that we have reported in another thread  found here.

I would like to better understand your issue with the multiple counters to be able to assess and see if we should post this as an issue/improvement and fix it as a global issue. Can you elaborate on the extension and point out the limitations you are struggling with? If it is easier, I am up for a chat.

Thank you,
Elisabeth

------------------------------
Elisabeth Andersson
MATRIXX Software
------------------------------


Original Message:
Sent: Jan 09, 2023 07:25
From: kartik maringanti
Subject: TMF 654 vs TMF 677

Thank you @Jonathan Goldberg

But the currently we have operations to add, update ( though TMF 654 does not support it on bucket )  and delete ​on bucket, the difference we have seen is, TMF 677 has support to multiple counters and TMF 654 does not have it. So if we want to support above features then we are to go with TMF 654. But if we want to have multiple counters also, then our thought was to go with the extension of TMF 654 Bucket and support by composing one more many ConsumptionSummary schema.

Can we say that the TMF677 domain, since its a query only, does this query the data from the tables where the data of TMF 654 events are parsed and stored ?

Let know if our understanding is correct.


------------------------------
Kartik N Maringanti
Verizon


Original Message:
Sent: Jan 09, 2023 07:16
From: Jonathan Goldberg
Subject: TMF 654 vs TMF 677

TMF635 specifically relates to prepay buckets or balances, and the operations there support all the common manipulations needed on a prepay balance (topping up, reserving, transferring, etc.).
TMF677 is a read-only API that gives a wider picture of the customer's usage.
The two APIs do not overlap, at least not intentionally.
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.