Open APIs

 View Only
  • 1.  Resource Pool API swagger issues

    Posted Feb 28, 2020 11:26
    Hi, There are a couple of issues with the definitions in the current Resource Pool API swagger, missing definitions.  This is preventing us from rendering the swagger in API documentation tooling.  I can probably fix this by including the definitions from the Resource Inventory API. How do I go about contributing to these API definitions technically e.g. how to I get to branch and pull request the github projects

    ------------------------------
    Kris Thornley
    Vodafone New Zealand Limited
    ------------------------------


  • 2.  RE: Resource Pool API swagger issues

    TM Forum Member
    Posted Feb 29, 2020 13:49
    Hi Kris
    The Resource Pool API is being refreshed, led by @Kiyotaka Mizuno - I suggest you reach out to him directly to explain the issues so that he can ensure that they will be fixed in the latest version.
    In general, write access to the underlying sources for the Open API assets is restricted to Open API project members. We have several colleagues from Vodafone group in this project, such as @Steve Harrop and @Florin Tene - if you are thinking of making contributions you might want to discuss with them first to see how to cooperate.
    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: Resource Pool API swagger issues

    TM Forum Member
    Posted Mar 06, 2020 07:48
    Dear Kris,
    I'm Kiyotaka Mizuno of NTT Japan.
    Thank you for your post.
    As you said, there is many mistakes in TMF685 Resource Pool API's Swagger file, for example, 'ResourcePool' resource does not include 'Capacity' sub-resource, and so on.
    Currently, I and TMF API team are considering about simplification of TMF685 Resource Pool API, when the simplificaiton is done, the Swagger file will be match with Spec document.

    Dear Jonathan,
    Thank you for your explanation.

    ------------------------------
    Kiyotaka Mizuno
    NTT Group
    ------------------------------



  • 4.  RE: Resource Pool API swagger issues

    TM Forum Member
    Posted Mar 09, 2020 12:37

    ​Dear Kris,
    I'm Kiyotaka Mizuno of NTT Japan.
    Thank you for your post.
    As you said, there is many mistakes in TMF685 Resource Pool API's Swagger file, for example, 'ResourcePool' resource does not include 'Capacity' sub-resource, and so on.
    Currently, I and TMF API team are considering about simplification of TMF685 Resource Pool API, when the simplificaiton is done, the Swagger file will be match with Spec document.

    Dear Jonathan,
    Thank you for your explanation.



    ------------------------------
    Kiyotaka Mizuno
    NTT Group
    ------------------------------



  • 5.  RE: Resource Pool API swagger issues

    TM Forum Member
    Posted Mar 11, 2020 10:22
    Dear Kris,
    I'm Kiyotaka Mizuno of NTT Japan.
    Thank you for your posting.
    As you said, there are many mistakes in TMF685 Resource Pool API's Swagger file, for example, 'ResoucePool' resource does not include 'Capacity' sub-resource, and so on.
    Currently, I and TMF API team are considering about simplification of TMF685 Resource Pool, when the simplication done, the Swagger file will be match with Spec document. ​

    Dear Jonathan,
    Thank you for your explanation.

    ------------------------------
    Kiyotaka Mizuno
    NTT Group
    ------------------------------



  • 6.  RE: Resource Pool API swagger issues

    TM Forum Member
    Posted Apr 03, 2020 02:31
    Hi Kiyotaka,

    while you are refactoring the API, I would ask you to consider the following aspect since I think it could make the API more widely applicable in the pre-ordering phase. (maybe also later in the process, as required):

    Hello, 

    I commented on an earlier draft already. I think the new proposal is much more streamlined and I like it. 

    We are interested in something like this that can be used for availability check and reservation of resources like SIM-cards or MSISDNs along with specific products (e.g. handsets)  which according to our understanding are not resources but products.  

    1. Should we model these products as resources in the API and use it as is?
    2. Should there be a split of this API into two (like e.g. ServiceQualification and ProductOfferingQualification)? One handling general products, the other "classical" resources?.
    3. Might it be an idea to call this API simply "Reservation API" or something like that since the Reservation process is the primary value stream whereas the Resourcepool is only a mechanism for that purpose.  This way, the focus on Resource (as opposed to product or resource) might be reduced and it might be used for both. 
    4. Looking at the Appointment API, which is also used in similar context, the simply have an EntityRef, which could replace the ResourceRef (maybe along with an EntitySpecRef)

    Andreas



    ------------------------------
    Andreas Schlueter
    NTT DATA CORPORATION
    ------------------------------