Open APIs

 View Only
Expand all | Collapse all

TMF639 vs TMF685

  • 1.  TMF639 vs TMF685

    TM Forum Member
    Posted Jan 15, 2020 08:40
    ​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
    ------------------------------


  • 2.  RE: TMF639 vs TMF685

    TM Forum Member
    Posted Jan 16, 2020 09:36
    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.
    ------------------------------



  • 3.  RE: TMF639 vs TMF685

    TM Forum Member
    Posted Jan 20, 2020 02:03
    Hello Jonathan,

    Thanks for providing guidance. Yes it helped. For now our requirement is to manage logical number resources' life cycle using API interfaces and Resource Pool API specification may help us in this area. ​

    Thanks again for the insights around these two API specification Jonathan.
    Regards,
    Anil.

    ------------------------------
    Anil Sharma
    Colt Technology Services
    ------------------------------



  • 4.  RE: TMF639 vs TMF685

    Posted Sep 18, 2020 09:45

    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
    ------------------------------



  • 5.  RE: TMF639 vs TMF685

    TM Forum Member
    Posted Sep 24, 2020 03:58
    Probably best if @Kiyotaka Mizuno​ can relate to this, as the "owner" of the Resource Pool API.

    ------------------------------
    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.
    ------------------------------



  • 6.  RE: TMF639 vs TMF685

    TM Forum Member
    Posted Sep 24, 2020 10:49
    @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
    ------------------------------



  • 7.  RE: TMF639 vs TMF685

    Posted Sep 25, 2020 03:24

    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
    ------------------------------



  • 8.  RE: TMF639 vs TMF685

    TM Forum Member
    Posted Sep 25, 2020 03:44
    Edited by Kiyotaka Mizuno Sep 25, 2020 03:44
    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
    ------------------------------



  • 9.  RE: TMF639 vs TMF685

    Posted Sep 25, 2020 03:49

    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
    ------------------------------



  • 10.  RE: TMF639 vs TMF685

    TM Forum Member
    Posted Sep 27, 2020 03:17
    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
    ------------------------------



  • 11.  RE: TMF639 vs TMF685

    TM Forum Member
    Posted Mar 04, 2021 08:59
    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
    ------------------------------



  • 12.  RE: TMF639 vs TMF685

    TM Forum Member
    Posted Mar 05, 2021 08:32
    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.
    ------------------------------



  • 13.  RE: TMF639 vs TMF685

    Posted Mar 08, 2021 09:04
    The link of the topic is also a very good explanation congratulations. I don't understand why we're looking for the wrong places too

    ------------------------------
    Dursun Koç
    TO BE VERIFIED
    ------------------------------