You are quite right that the example operation payload in the TMF638 API is misleading. Sub-classing (CustomerFacingServiceSpecification/ResourceFacingServiceSpecification) in the Service domain Open API is typically only performed for the specs so that you can subclass the service instances in the inventory to add concrete fields to the API, e.g. NetworkService, ShippingService, etc, etc. The example in the TMF641 API suggest that the serviceType should discriminate between CFS and RFS, whereas in TMF638 the indication is that the category field should be used for this.
Looking at the discussions in JIRA, it appears that the decision is not to use the category field, suggesting to use the serviceType instead (as per TMF641 examples). Hopefully this will be corrected in the Open API and PDFs soon.
Sorry this is not much help.
Original Message:
Sent: Aug 27, 2024 05:46
From: Sandrine Godmez
Subject: TMF638 Service Inventory - JSON CFS and RFS in API
Regarding to TMF638 v4 Swagger file, a Service haven't @type & @schemaLocation fields.
Regarding to TMF638 v4 PDF specification, theses fields aren't describes for a Service.
So, the example in this PDF wouldn't have theses fields, maybe a little mistake in this document.
So, without theses fields, I guess that the only way to differenciate CFS of RFS is using the Service.category.
This is an extract from TMF638 v4.0 (extract with only interesting fields)
{ "id": "5351", "href": "https://mycsp.com:8080/tmf-api/serviceInventory/v4/service/5351", "serviceType": "Cloud", "name": "vCPE serial 1355615", "description": "Instantiation of vCPE", "category": "CFS" "@type": "Service", "@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Service/vCPE.schema.json"}
------------------------------
Sandrine Godmez
Airbus
Original Message:
Sent: Aug 23, 2024 05:42
From: Sandrine Godmez
Subject: TMF638 Service Inventory - JSON CFS and RFS in API
Hello all
I was looking how to differenciate CFS of RFS in TMF638 v4.0 but the examples does not seem to me compliance with TMF630 REST API Design Guidelines.
I would define a CFS (extract of a CFS), like that :
Definition 1 , Regarding TMF630 & TMF638
(extract with only interesting fields)
{ "id": "5351", "href": "https://mycsp.com:8080/tmf-api/serviceInventory/v4/service/5351", "@type": "CustomerFacingService", "@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Service/CustomerFacingService.schema.json", "@baseType": "Service"}
Definition 2 , RegardingTMF638 only
This is an extract from TMF638 v4.0 (extract with only interesting fields)
{ "id": "5351", "href": "https://mycsp.com:8080/tmf-api/serviceInventory/v4/service/5351", "serviceType": "Cloud", "name": "vCPE serial 1355615", "description": "Instantiation of vCPE", "category": "CFS" "@type": "Service", "@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Service/vCPE.schema.json"}
Which definition is correct ?
Why am I struggle ? Because :
What TMF638 Service Inventory v4.0 and TMF630 REST API Design Guildeline said
TMF638:
Service is a base class for defining the Service hierarchy. All Services are characterized as either being possibly visible and usable by a Customer or not. This gives rise to the two subclasses of Service: CustomerFacingService and ResourceFacingService.
CFS and RFS are 2 subclasses of Services, therefore regarding TMF630 REST API Design Guidelines Part 2 :
As part of the API Data model the resources that have been identified as expected to be extended in implementations must include parameters @type, @baseType and @schemaLocation explicitly within the structure defined for those resources.
The @baseType of an entity can be used to represent the collection of all entities with the same
base type.
◦ For example, the "logicalResource" collection will scope both the "Tpe" and "Link" resources.
But TMF638 said too :
Field descriptions
Service fields
category A string. Is it a customer facing or resource facing service.
------------------------------
Sandrine Godmez
Airbus
------------------------------