Hi Amita
Please be aware that there is a new API being designed for resource reservation. Refer to
this thread for additional discussions.
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: Mar 04, 2021 08:58
From: Amita Giriya
Subject: TMF639 vs TMF685
Hi Kiyotaka Mizuno,
We are looking at TMF685 v1.0.1 for resource pool and reservation concept.
As you have mentioned in the thread above, the data model will be changed drastically with the new version of the api.
We would like to know if the new version will have any conceptual changes as well? Is there any expected release date of the new version of this api?
Thanks,
Amita
------------------------------
Amita Giriya
Telstra Corporation
Original Message:
Sent: Sep 27, 2020 03:16
From: Kiyotaka Mizuno
Subject: TMF639 vs TMF685
Hi @Liyaqat Mugjenkar,
About relatedParty, I think it will be changed like following which defined TMForum DataModel.
https://tmforum-schemas.readthedocs.io/en/latest/EngagedParty/RelatedPartyRef/
I think it's better to use new version of the API, but the release date of the new one is not yet decided.
------------------------------
Kiyotaka Mizuno
NTT Group
Original Message:
Sent: Sep 25, 2020 03:48
From: Liyaqat Mugjenkar
Subject: TMF639 vs TMF685
Hi @Kiyotaka Mizuno
Thanks for the prompt response, does this apply to generic objects ? As an example in the document it says:
"relatedParty": {
"partyRole" : "EnterpriseCustomer",
"partyId" : "EC_1002"
},
However in the Swagger API it is and Related Party is used elsewhere.
"relatedParty": {
"role" : "EnterpriseCustomer",
"id" : "EC_1002"
},
Does (2) mean that we should not be using this API? In terms of compliance can we be compliant with an older version of the API ? When do you anticipate the new API to be released?
Kind regards
Liyaqat
------------------------------
Liyaqat Mugjenkar
Bytes Systems Integration a division of Altron TMT (Pty) Ltd
Original Message:
Sent: Sep 25, 2020 03:43
From: Kiyotaka Mizuno
Subject: TMF639 vs TMF685
Hi @Liyaqat Mugjenkar
1. My understanding is that the data model in specification doc is more correct than swagger. Therefore, I don't recommend to use swagger.
And, data model of specification doc is also not enouch.
2. Unfortunately the data model of TMF685 is not matured, therefore, I think that data model will be changed drastically.
Best Regards,
Kiyotaka
------------------------------
Kiyotaka Mizuno
NTT Group
Original Message:
Sent: Sep 25, 2020 03:23
From: Liyaqat Mugjenkar
Subject: TMF639 vs TMF685
Hi @Kiyotaka Mizuno
Thank you for your response. If I could combine the two questions and feedback here if you do not mind.
Is it correct to say:
1. TMF-685 docs is a bit out of date, the concept is still fine but we should use the auto generated objects as per the swagger docs
2. We would like to implement pool resourcing and have started on the availabilityCheck and Reservation endpoints (change state of a resource) but this will change? Does that mean if we implement some parts of it our API will not be TM Forum compliant ?
Kind regards
Liyaqat
------------------------------
Liyaqat Mugjenkar
Bytes Systems Integration a division of Altron TMT (Pty) Ltd
Original Message:
Sent: Sep 24, 2020 10:48
From: Kiyotaka Mizuno
Subject: TMF639 vs TMF685
@Liyaqat Mugjenkar
Sorry for late response.
Unfortunately, I think TMF685 is very complicated and not matured yet.
Therefore, I think you should just refer concept of TMF685.
In TMF685 there are two aspects, one is pooling of resource, and the other is reserving of resource.
Currently, we are considering simplification of the TMF685, then the date model will be changed.
------------------------------
Kiyotaka Mizuno
NTT Group
Original Message:
Sent: Sep 18, 2020 09:44
From: Liyaqat Mugjenkar
Subject: TMF639 vs TMF685
Hi @Jonathan Goldberg
My apologies for adding to this thread but we are in a similar predicament and I wanted to find out if my understanding is correct.
We are implementing Resource Pools for our Inventory management of Logical Resources. We are following TMF 685 for finding resources by the pool id and other criteria.
We are also updating the state of the resource from one to the other based on TMF 685.
If we add resources to our inventory what should we follow? When we add resources it needs to be associated to a resource pool and related party. How do we add these resources? Is it ok to use the add logical resource and modify it to add the resource pools ?
Thank you so much :)
------------------------------
Liyaqat Mugjenkar
Bytes Systems Integration a division of Altron TMT (Pty) Ltd
Original Message:
Sent: Jan 16, 2020 09:35
From: Jonathan Goldberg
Subject: TMF639 vs TMF685
Hi Anil
Resource Inventory is about technical management (CRUD) of resources - in your use case logical resources. So if you have a resource you can retrieve/update it, if you want to create one you can. But there is nothing in that API that will help you allocate resources - the propose number use case. Hence the Resource Pool API, which should allow you to handle number (or other logical resource) allocation, aging, etc.
So basically you need to consider both APIs.
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 15, 2020 07:50
From: Anil Sharma
Subject: TMF639 vs TMF685
We are planning to use TMF Open API specifications to define APIs for our Telephone Number Management System. Both TMF639 Resource Inventory Management API and TMF685 Resource Pool Management API specifications seems have similar APIs. We are confused as which of these two specifications to follow. Any guidance on it would be appreciated.
------------------------------
Anil Sharma
Colt Technology Services
------------------------------