Darryl,
Your starting point should be the creation of a collection of Resource Specifications (TMF634) which describe the Resources you will instantiate within your Resource Inventory (TMF639). For example:
POST /resourceCatalogManagement/resourceSpecification/
Content-Type: application/json
{
"name": "Electricity Meter",
"description": "This resource specification defines an Electricity Meter",
...
"resourceSpecCharacteristic": [
{
"name": "Manufacturer Model",
"valueType": "string",
"resourceSpecCharacteristicValue": [
{
"valueType": "string",
"value": "Sangamo K2A"
},
{
"valueType": "string",
"value": "Arch Meter SW3005"
},
...
]
},
...
]
}
Now when you create an instance in your Resource Inventory (TMF639) you provide the Resource Specification used and the Characteristic values as allowed by the specification:
POST /resourceInventoryManagement/resource/
Content-Type: application/json
{
...
"resourceSpecification": {
"id": "42",
"href": "/resourceCatalogManagement/resourceSpecification/42",
"name": "Electricity Meter"
},
"resourceCharacteristic": [
{
"name": "Manufacturer Model",
"value": "Sangamo K2A"
},
...
]
}
There are no special schemas needed to define profiles of resources with the list of possible characteristics and allowed values, value ranges or value types.
If however you want to go beyond this mechanism you may use polymorphism to define new classes. You would provide a schema which extends an existing class (i.e. LogicalResource) and may add attributes not defined in TM Forum Open APIs.
{
...
"@type": "ElectricityMeterSpecification",
"@baseType": "PhysicalResourceSpecification",
"@schemaLocation": "/resourceCatalogManagement/schemas/ElectricityMeterSpecification"
...
"myAttributeSpecification": {
...
}
}
{
...
"@type": "ElectricityMeter",
"@baseType": "PhysicalResource",
"@schemaLocation": "resourceInventoryManagement/schemas/ElectricityMeter"
...
"myAttribute": {
...
}
}
I would encourage you to take the ResourceSpecification/Resource, CharacteristicSpecification/Characteristic pattern as far as you can before resorting to polymorphism.
------------------------------
Vance Shipley
SigScale
------------------------------
Original Message:
Sent: Dec 06, 2019 08:02
From: Darryl Cook
Subject: TMF639 - Resource Inventory - Patterns for schema definition for different resource types
Hi All,
I work for a UK Energy Company (SSE) and we are using the TMForum Open APIs to define a business service API layer across a number of legacy applications. We are early on in our TMF journey and we are trying to map Resource Inventory to our landscape.
What we have found is that Resource along with Service are generic APIs that are intended to be used to interact with many different types of Resources and Services - obviously those resources and services will require different data fields to describe them accurately.
The latest definition of the Resource Inventory API provides operations for
Logical Resources
Physical Resources
and a catch all that allows you to specify the type of resource you want to retrieve
GET /{resource-type}/{id}
What I'm not clear on is the TMF pattern for specifying the schema that will be returned for each individual resource.
In a GET Resource scenario
1. Would I use a supeset schema that specifies all the fields across all different resources and just populate the ones specific to the resource I am dealing with - so regadless of the type of resource return the API consumer the same schema
2. Or would I define specific schemas for each resource, and use the schema that is aligned to the resource type - so the schema and data returned is specific to the type of resource requested (i.e. Meter, or InHome Display, or Registration for example)
3. Oris it OK to extend the out of the box resource inventory API to add resource specific operations, that use schema for that particular resource. i.e.
GET /ResourceInventory/meter/{id} (returns a specific MeterResource structure)
GET /ResourceInventory/InHomeDisplay/{id} (returns a specific InHomeDisplay structure)
GET /ResourceInventory/EnergyRegistration/{id} (returns a specific EnergyRegistration structure)
It gets even tricker on a POST when creating the resources - I want to be able to expose a strongly types schema to the API consumer so that it is obvious what needs to be populated when creating a resource
Can someone help me on the general pattern that should be used?
Thanks
Darryl
------------------------------
Darryl Cook
SSE Energy Services Ltd
------------------------------