Open APIs

 View Only

  • 1.  TMF640: Support for alternative key identifier : ID

    Posted Aug 17, 2021 21:55


    Hi there

    As per the standards today; ID field is mandatory when a service is created in the server/repository.
    Once the ID is created - this ID is to perform the GET/PATCH/DELETE etc on the service.

    Example:

    PATCH /service/{id}
    DELETE /service/{id}
    GET {id}

    If we don't want to tie up these operations GET/PATCH/DELETE on ID generated by the server but define it more aligned to the user or client (CRM) or our our custom ID
    Can we have an alternate ID defined for retrieval and will that comply with TMF standard?

    Example:

    PATCH /service/{clientId}
    DELETE /service/{clientId}
    GET {clientId}



    thanks
    vikas



    ------------------------------
    Vikas Kumar
    Ciena Corporation
    ------------------------------


  • 2.  RE: TMF640: Support for alternative key identifier : ID

    Posted Aug 18, 2021 01:24
    Hi Vikas,

    The simplest solution would be to map/copy  clientId to Id as well, if it is OK to ignore/abandon actual ID.

    So your entity would look like

    {
           "id": "clientId00001",  //actual ID will  never get published then
           "href": "https:/myserevr.com/app/customer/clientId00001",
           "clientId" : "clientId00001",
           "xxx": "abc"
            .....
    }


    Thanks,
    Hanumantha Marikanti
    OpenAPI  Ethusisast.

    ------------------------------
    Hanumantha Marikanti
    Saralam Technologies
    ------------------------------

    Original Message


  • 3.  RE: TMF640: Support for alternative key identifier : ID

    TM Forum Member
    Posted Aug 18, 2021 02:03
    Hi
    From Open API perspective, we introduced the ExternalIdentifier structure to deal with this use case. The idea is that the consumer can use this identifier to retrieve entities that it created, without needing to get the internal entity ID back from the creation operation. More and more entities are having ExternalIdentifier array added as we release new API versions, and of course you can add yourself as an extension.
    Supplying a primary entity ID by a consumer at creation is a risky step, you need some scheme to ensure no duplication across multiple consumers for the same entity.
    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


  • 4.  RE: TMF640: Support for alternative key identifier : ID

    Posted Aug 18, 2021 08:09

    Hi Jonathan

    We dont have externalId in TMF640 - I checked the spec 

    ExternalID is only available in TMF641

    thanks
    vikas



    ------------------------------
    Vikas Kumar
    Ciena Corporation
    ------------------------------

    Original Message


  • 5.  RE: TMF640: Support for alternative key identifier : ID

    TM Forum Member
    Posted Aug 18, 2021 08:17
    Like I said, it's getting added gradually to additional entities. Probably more will happen in v5.

    In the meantime, you can extend the current API for your specific needs, my recommendation is to add an array of ExternalIdentifier, since this allows chaining of IDs from multiple systems, and addresses other use cases where multiple IDs might be needed.

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


  • 6.  RE: TMF640: Support for alternative key identifier : ID

    TM Forum Member
    Posted Apr 20, 2023 14:54

    I like this idea.

    We use the a similar mechanism internally to support multiple identifiers. An "idScope" explains to alternate source reference system/source. 

    It would be nice to have a standard pattern across all API's for this. 

    Something like:

    "externaldentifiers" [    
        { "id":
          "idScope": }
        ]



    ------------------------------
    Peter Broucke
    Proximus SA
    ------------------------------

    Original Message


  • 7.  RE: TMF640: Support for alternative key identifier : ID

    TM Forum Member
    Posted Apr 21, 2023 09:48

    using the externalIdentifier like suggested by Jonathan is a good idea, it would align the 2 API's 640 and 641.
    Regards



    ------------------------------
    Geoffrey Cristallo
    Proximus SA
    ------------------------------

    Original Message


  • 8.  RE: TMF640: Support for alternative key identifier : ID

    Posted Aug 18, 2021 08:16

    Hi Hanuma

    We actually thought about the same . 
    the problem is

    - client ID or something like externalID is not supported in TMF640
    - We will not end up publish ID

    Will it make the implementation fail the tmf compliance

    thanks
    vikas



    ------------------------------
    Vikas Kumar
    Ciena Corporation
    ------------------------------

    Original Message


  • 9.  RE: TMF640: Support for alternative key identifier : ID

    TM Forum Member
    Posted Aug 18, 2021 01:59
    Hi Vikas,

    The id field is a unique identifier of an entity. The entity is in your case the service.
    For PATCH and DELETE operations it is extremely important that you uniquely identify the entity (service) you want to modify or delete.
    Using the identfier of a user or client, that in principle can have more than one service wouldn't uniquely identify the service.

    The story of the GET operation this is an entirely different one.
    Beside the retrieval of a single entity you can also use search criteria as described in TMF630 Part 1.

    This will allow you to things like:

    • GET /service?relatedParty.role=client&relatedParty.id=1234567
      • this will return a collection with all services of this client
    • GET /service?supportingResource.id=345678
      • This will return a collection of services impacted if this resource is malfunctioning
    • GET /service?name=1234567-001
      • if your naming convention uses a prefix of the client with a suffix unique to the service of this client this will return a collection with 0 or 1 service.

    I hope this helps

    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------

    Original Message


  • 10.  RE: TMF640: Support for alternative key identifier : ID

    Posted Aug 18, 2021 08:13
    Hi Koen

    In our case clientID maps to only one service.
    If we can have something like ExternalID in TMF640 also to support this behavior

    thanks
    vikas

    ------------------------------
    Vikas Kumar
    Ciena Corporation
    ------------------------------

    Original Message