This is actually a very good question and it show that a clarification is needed.
I am alligned with Jonathan. For TMF638 and TMF641 the href definitely points to the inventory.
For TMF640 service activation the story is indeed more tricky. TMF640 in principle pushes a service that already exists in the inventory into a network element.
This results in a digital twin of the service with one instance in the inventory and the other instance on the network element.
Do these twins have the same href? I see two options:
1/ Under the assumption is that TMF640 only copies the infromation from inventory to network element there is potentially no need for a differen href.
2/ Under the assumption that TMF640 creates another instance on the network element the href should be different. But that may even imply that it is not the same type of entity. In that case TMF640 should probably handle a different entity than the inventory. Maybe it should become Service (inventory) and ServiceConfiguration (network)? I personally struggle with the fact that we have 2 OpenAPI TMF638 & TMF640 that seem to handle the same entity.
I am personaly inclined towards the second option, but more discussion seems required.
@Zoltan Gelencser @Hugo Vaughan: maybe we should discuss this as part of the network component definition?
------------------------------
Koen Peeters
OryxGateway
------------------------------
Original Message:
Sent: Jun 21, 2022 02:51
From: Jonathan Goldberg
Subject: service href - representation in context of 640 and 641 APIs
Hi Ambily
I would suggest the following:
- TMF638 service repository - returned href should definitely be a reference to the endpoint that allows direct retrieval of the service from the inventory
- TMF641 service order - the href at the top level is of course a reference to the service order, not to services that are being dealt with in the order. In the order items, services embedded by value (e.g. new services) will not have href, services embedded by reference should have href pointing to TMF638
- TMF640 service activation - tricky one here. I am responsible for the example :( (mycsp.com:8080 is a giveaway) from about 4 years ago. But it is not a given that the network elements will actually be able to respond to the GET request, and perhaps a specific implementation would reroute to the inventory.
@Ludovic Robert and @Kamal Maghsoudlou may also want to weigh in here
------------------------------
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: Jun 20, 2022 19:43
From: Ambily Narayanan Unni
Subject: service href - representation in context of 640 and 641 APIs
Hi @Jonathan Goldberg , @Derrick Evans , @Koen Peeters , @Dave Milham , curious to hear your inputs on this based on some of the previous 638, 640, 641 discussions.
------------------------------
Ambily Narayanan Unni
Telstra Corporation
Original Message:
Sent: Jun 17, 2022 03:10
From: Ambily Narayanan Unni
Subject: service href - representation in context of 640 and 641 APIs
Hello,
Wanted to discuss if there is any guideline around what 'href' field under 'service' resource should denote in a 640 Vs 641 (under each Service Order Item) responses. Should this point to a 'Service Inventory' representation or to a ServiceActivationAndConfiguration URL?
In 640 API user guide, as part of the example of a request/response for activating a new service on the network (page 27) - the created service's href given denotes a serviceActivationAndConfiguration URL. (eg: https://mycsp.com:8080/tmf-api/ServiceActivationAndConfiguration/v4/service/5351). This seem to make sense as 640 operations are expected to directly operate on network and the ServiceActivationAndConfiguration URL can be considered as the representation of the service on the network.
However there could be implementations that orchestrates both Network and Service Inventory update along with 640 operations (Ref: https://engage.tmforum.org/communities/community-home/digestviewer/viewthread?GroupId=31&MessageKey=37d4cdf6-a887-43c2-8773-436f399e01a1&CommunityKey=d543b8ba-9d3a-4121-85ce-5b68e6c31ce5&tab=digestviewer). IG1224 NaaS Service Management v5.1.0 ( page 21, Figure 12: Order Management sequence flow) also denotes that as part of a 640 operation, internally domain updates the inventory.
In case of 641 – The general expectation is that as part of 641 order , internally both 638 and 640 are invoked and both service inventory and network are updated during the order journey. In TMF 641 User guide examples (page 27) for modify - one of the service order item href points to the serviceInventory as http://serverlocation:port/serviceInventoryManagement/v4/service/12
So – Is there a guideline/general recommendation around what service href should point to in these different cases? or is this subject to implementation/interpretation?
------------------------------
Ambily Narayanan Unni
Telstra Corporation
------------------------------