Open APIs

Back to discussions
Expand all | Collapse all

TMF 639: Resource inventory management API extension

  • 1.  TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 5 days ago
    Hi All,

    We need to provide APIs for Bulk number management. We wont work on individual numbers. APIs work on number block and does activation, de-activation, reservation etc for the number block. The TMF 639 works on individual numbers. Is there a way to extend this API to support resource blocks or number blocks or what is the TMF suggestion to implement our requirement?

    Many thanks,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------


  • 2.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 5 days ago
    There is a new Resource Reservation API in preparation, @Pierre Robitaille leads this API, and he will want to be aware of the requirements for TN management (presumably for MSISDNs, VoIPs, etc.).
    ​

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


  • 3.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 4 days ago
    Thank you @Jonathan Goldberg. For now, how can we achieve this​ requirement. Do we need to create custom REST API for our requirement or is there any other way to be aligned with TMF guidelines.

    Best regards,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------

    Original Message


  • 4.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 4 days ago
    You might be able to use this as a starting point:
    https://github.com/tmforum-apis/TMF639_ResourceInventory

    ------------------------------
    Richard Loo
    Telstra Corporation
    ------------------------------

    Original Message


  • 5.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 4 days ago
    Thank you @Richard Loo. I have seen this. This spec manages individual resources. Our requirement is to do CRUD on bulk numbers. The question I have is do we need to create custom REST API for bulk resources or is there any other way to be aligned with TMF guidelines.

    Best regards,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------

    Original Message


  • 6.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 4 days ago
    With further analysis, we are thinking of extending Resource Inventory Management API to have a derived "logical resource" as "resource/number-block" with required parameters like start range, end range etc. Is this acceptable?

    Thanks,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------

    Original Message


  • 7.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 4 days ago
    Hi Kalpana
    There is a Resource Pool API TMF685, that may give you what you are looking for, but as I wrote previously it would probably be better for you to wait for the new Resource Reservation API. Or, if you cannot wait, to reach out to Pierre to see if you can align your design with his proposal.

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


  • 8.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 4 days ago
    Thank you @Jonathan Goldberg. Resource pool API is not suitable for us and as per the thread "TMF639 vs TMF685" resource pool API specification is not yet matured. Will reach out​ to @Pierre Robitaille​​.

    @Pierre Robitaille,
    Could you please, let us know your thoughts on this post.​

    Best regards,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------

    Original Message


  • 9.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 3 days ago
    Hi @Kalpana HV,
    you are on the right path thinking of extending the resource model. We have had discussions about this in the past and the ​proper wording for this concept is "ResourceCollection".

    Since a ResourceCollection is itself an extension of Resource, it can be used as the subject of a reservation which i believe is what you are trying to achieve.

    Here is  a very high-level diagram showing the concept of collection :

    Please let me know if this addresses your needs.
    Thanks

    ------------------------------
    Pierre Robitaille
    Videotron G.P.
    ------------------------------

    Original Message


  • 10.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 3 days ago
    Thank you @Pierre Robitaille. It helps. So, we would define "resourceCollection" object by extending "Resource" object of Resource Inventory Management API and would do CRUD on the resourceCollection. These CRUD operations on resourceCollection would be under the Resource Inventory Management API. Would that be OK?

    Best Regards,
    Kalpana

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------

    Original Message


  • 11.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 2 days ago
    Given that ResourceCollection would be an extension of Resource, it then falls under the idea of polymorphism. So in theory you could use ResourceCollection in a polymorphic manner anywhere a Resource could be used. In that regards my opinion is that yes, the CRUD operations could be done under the Resource Inventory Management API.

    Thanks

    ------------------------------
    Pierre Robitaille
    Videotron G.P.
    ------------------------------

    Original Message


  • 12.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 2 days ago
    Many thanks @Pierre Robitaille for the response. It helps a lot :)

    Best​ regards,
    Kalpana​

    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------

    Original Message


  • 13.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 3 days ago
    Edited by Pierre Robitaille 3 days ago
      |   view attached

    [duplucate reply removed]



  • 14.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted 2 days ago

    Hey Folks,

    I'm not sure, but if I understood the proposal correctly, the response of the API could then look like this:

    [
    {
        "id": "1",
        "href": "http://inventory/tmf-api/resourceInventory/v4/resource/1",
        "name": "LR_1",
        "@type": "LogicalResource",
        "@baseType": "Resource",
        "resourceRelationship": [
            {
                "relationshipType": "IsContainedIn", // Not sure if this is the correct and if we would need this.
                "href": "http://inventory/tmf-api/resourceInventory/v4/resource/3",
                "@type": "ResourceRelationship",
                "@referredType": "ResourceCollection"
            }
        ]
    },
    {
        "id": "2",
        "href": "http://inventory/tmf-api/resourceInventory/v4/resource/2",
        "name": "LR_2",
        "@type": "LogicalResource",
        "@baseType": "Resource",
        "resourceRelationship": [
            {
                "relationshipType": "IsContainedIn", // Not sure if this is the correct and if we would need this.
                "href": "http://inventory/tmf-api/resourceInventory/v4/resource/3",
                "@type": "ResourceRelationship",
                "@referredType": "ResourceCollection"
            }
        ]
    },
    {
        "id": "3",
        "href": "http://inventory/tmf-api/resourceInventory/v4/resource/3",
        "name": "A ResourceCollection",
        "@type": "ResourceCollection",
        "@baseType": "Resource",
        "resourceRelationship": [
            {
                "relationshipType": "HasCompoundResources",
                "href": "http://inventory/tmf-api/resourceInventory/v4/resource/1",
                "@type": "ResourceRelationship",
                "@referredType": "LogicalResource"
            },
            {
                "relationshipType": "HasCompoundResources",
                "href": "http://inventory/tmf-api/resourceInventory/v4/resource/2",
                "@type": "ResourceRelationship",
                "@referredType": "LogicalResource"
            }
        ]
    }
]

    Is this going in the right direction?

    Cheers,

    Jan



    ------------------------------
    Jan Lemmermann
    OSS Lead Architect
    EWE TEL GmbH
    ------------------------------

    Original Message


  • 15.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted yesterday
    Edited by Kalpana HV yesterday
    Hi Jan,

    The resource model would be something like

    So the JSON representation would be
    Thanks,
    ------------------------------
    Kalpana HV
    Colt Technology Services
    ------------------------------

    Original Message


  • 16.  RE: TMF 639: Resource inventory management API extension

    TM Forum Member
    Posted yesterday
    Your variant is definitely also possible. I just wonder if it makes sense to introduce resourceCollectionRef, resourceCollectionSpecification and so on as new attributes.
     
    According to SID a ResourceCollection is derived from Resource. So you inherit resourcecSpecification and the resourceRelationship array directly when you introduce a new REST resource in the API. So why not use these attributes instead of introducing new ones that end up doing the same thing, mapping relationships between resources.
     
    Until now, I always assumed that if you apply polymorphism to TMF OpenAPI, the same basic principles apply.
    Would be interesting to hear what others have to say about this.
    Cheers,
    Jan


    ------------------------------
    Jan Lemmermann
    OSS Lead Architect
    EWE TEL GmbH
    ------------------------------

    Original Message