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:
Sent: Aug 18, 2021 08:09
From: Vikas Kumar
Subject: TMF640: Support for alternative key identifier : ID
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:
Sent: Aug 18, 2021 02:03
From: Jonathan Goldberg
Subject: TMF640: Support for alternative key identifier : ID
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:
Sent: Aug 18, 2021 01:24
From: Hanumantha Marikanti
Subject: TMF640: Support for alternative key identifier : ID
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:
Sent: Aug 17, 2021 21:55
From: Vikas Kumar
Subject: TMF640: Support for alternative key identifier : ID
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
------------------------------