🔖 TMF API Service
The ETSI HypO ecosystem is built around multi-stakeholder and multi-role principles. Each stakeholder role is associated with relevant ETSI HypO services, which are made accessible to the stakeholder through a standards-compliant (based on TMForum) REST-based Northbound Interface (NBI).
Summary of Supported APIs
Table 1 summarizes the TMF APIs offered by ETSI HypO and how they relate to various stakeholders and their roles.
| TMF API | Objective |
|---|---|
| TMF 620 Product Catalog Management | Allows customers to manage products organized in catalogs and categories |
| TMF 622 Product Ordering Management | Allows customers to order products from the products catalog(s) |
| TMF 637 Product Inventory Management | Allows customers to manage the runtime of products instances |
| TMF 633 Service Catalog Management | Allows service providers to manage services organized in catalogs and categories |
| TMF 641 Service Ordering Management | Allows service providers to order services from the service catalog(s) |
| TMF 640 Service Activation Management | Allows service providers to activate/deactivate services |
| TMF 638 Service Inventory Management | Allows service providers to manage the runtime of service instances |
| TMF 657 Service Quality Management | Allows service providers to describe a service's quality criteria |
| TMF 634 Resource Catalog Management | Allows infrastructure owners to manage resources organized in catalogs and categories |
| TMF 652 Resource Ordering Management | Allows infrastructure owners to order resources from the service catalog(s) |
| TMF 639 Resource Inventory Management | Allows infrastructure owners to manage the runtime of resources instances |
| TMF 632 Party Management | Allows platform administrators to manage ETSI HypO stakeholders, either individuals or organizations |
| TMF 669 Party Role Management | Allows platform administrators to assign role(s) to certain party |
| TMF 668 Partnership Management | Allows platform administrators to describe relations (i.e., partnership) between parties |
| TMF 642 Alarm Management | Allows platform administrators to perform simple alarm reporting and fault management |
| TMF 674 Geographic Site Management | Allows infrastructure owners to declare their resources' Points of Presence (PoPs) by means of abstract sites |
| TMF 673 Geographic Address Management | Allows infrastructure owners to associate an abstract geographic site with specific geographic addresses |
The complete list of open TMF APIs can be found online.
🔖 TMF Product Management APIs
ETSI HypO leverages TMF's Product Catalog Management API specification (TMF620) to describe products associated with services, which can be then organized in various products catalogs, each with one or more product categories as shown in Table 2.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/productCatalogManagement/v4 | 4.1.0 | Provides a catalog of products |
| /tmf-api/productCategoryManagement/v4 | 4.1.0 | Provides a category of products that belongs to a certain catalog |
| /tmf-api/productCandidateManagement/v4 | 4.1.0 | Provides a candidate of products that belongs to a certain category |
| /tmf-api/productSpecificationManagement/v4 | 4.1.0 | Provides a specification of products that maps to a certain candidate |
Once a product is stored into a product catalog, users can order it using TMF's Product Ordering API specification (TMF622) as shown in Table 3. A product order may comprise one or more product specifications, thus users may buy composite products.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/productOrderingManagement/v4 | 4.0.0 | Provides the ability to manage product orders that comprise of one or more product specifications |
Upon product ordering, a (set of) product instance(s) is/are made available to the customer. These instances are kept in a database that follows TMF637 Product Inventory Management API specification (TMF637), as shown in Table 4. This API keeps runtime information about product instances available to customers.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/productInventoryManagement/v4 | 4.0.0 | Provides the ability to query and manipulate active product instances |
🔖 TMF Service Management APIs
ETSI HypO leverages TMF's Service Catalog Management API specification (TMF633) to encode service providers' services into abstract service specifications, which can be then organized in various service catalogs, each with one or more service categories as shown in Table 5.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/serviceCatalogManagement/v4 | 4.0.0 | Provides catalogs containing service categories |
| /tmf-api/serviceCategoryManagement/v4 | 4.0.0 | Provideds categories containing service candidates |
| /tmf-api/serviceCandidateManagement/v4 | 4.0.0 | Provides service candidates. Each candidate corresponds to a unique specification |
| /tmf-api/serviceSpecificationManagement/v4 | 4.0.0 | Provides service specifications which work as blueprints for creating services |
Once a service specification is stored into a service catalog, users can order it using TMF's Service Ordering API specification (TMF641) as shown in Table 6. A service order may comprise one or more service specifications, thus users may request composite services.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/serviceOrdering/v4 | 4.1.0 | Provides the ability to manage service orders that comprise of one or more service order items |
Ordered services are provisioned into a target infrastructure but remain inactive (consuming no resources) till an explicit service activation. This is done via an explicit API call to TMF640 Service Activation Management API (TMF640) as shown in Table 7.
Service orders can contain multiple order items. Each order item has a unique specification reference which works as a blueprint to order services. Therefore, a service order can potentially create multiple services.
Service Order Orchestration
The TMF API utilizes a specific set of rules to determine the types of specifications provided within a service order, subsequently creating the corresponding service objects and references. These rules are triggered immediately upon service order creation and are executed at the pre-persist level. The system employs Easy Rules, a lightweight engine that allows users to define rules programmatically using Java POJOs. This implementation functions similarly to traditional Drools-based rules but with a smaller footprint.
Service orders supported by SONATA for orchestration typically include items belonging to one of the following categories:
- End User Service Specification (or inherited types)
- Kubernetes Services provided by a peered OSS
- 5G Services provided by a peered OSS
Once a service order is validated and passes all business rules, it is persisted. A message is then dispatched to SONATA to begin orchestration. The following JSON snippet illustrates a composite message structure:
{
"specversion": "1.0",
"id": "21000e26-31eb-43e7-8343-88a696fd96b1",
"source": "",
"type": "sonata-service-order",
"data": {
"serviceOrderEndUserData": {
"serviceOrderId": "2c4fecbc-c436-4f8c-a5db-4a1159ebad2a",
"serviceOrderItemId": "4e0abab6-25d4-4204-b6e1-aea09f642d49",
"serviceId": "790daa4d-7f56-4575-8b64-c558cf518bed",
"serviceName": "CMS",
"servicePackageManager": "HELM",
"serviceRepositoryURL": "someUrl",
"serviceArtifactIdentifier": "react-nginx/compose.yaml",
"serviceArtifactVersion": "1.0.0",
"requestedCompletionDate": "2048-02-13T11:27:56.705567622Z"
},
"k8sServiceOrderData": {
"serviceOrderId": "2c4fecbc-c436-4f8c-a5db-4a1159ebad2a",
"serviceId": "790daa4d-7f56-4575-8b64-c558cf518bed",
"serviceSpecificationName": "K8SAAS",
"serviceOrderItemId": "1e382e63-0bac-40fa-a62e-a6c533cecc26",
"serviceOrderCharacteristics": [
{
"characteristicName": "Number of worker nodes",
"characteristicType": "TEXT",
"values": [{ "value": "3", "alias": null }]
},
{
"characteristicName": "Flavor of Nodes",
"characteristicType": "ENUM",
"values": [{ "value": "cpu4.m8192.d20g", "alias": null }]
}
],
"organizationCharacteristics": {
"organizationId": "2582308c-9f26-497e-9547-ec88d60ef9ff",
"organizationName": "osl",
"characteristics": {
"EXTERNAL_TMF_API_USERNAME": "username",
"EXTERNAL_TMF_API_BASE_URL": "http://192.192.192.192:80",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_SECRET": "secret",
"EXTERNAL_TMF_API_PASSWORD": "password",
"EXTERNAL_TMF_API_OAUTH2_TOKEN_URI": "",
"EXTERNAL_TMF_API_SERVICE_CATEGORY_URL": "/tmf-api/serviceCatalogManagement/v4/serviceCategory",
"EXTERNAL_TMF_API_CLIENT_REGISTRATION_ID": "1234",
"EXTERNAL_TMF_API_SERVICE_CATALOG_URL": "/tmf-api/serviceCatalogManagement/v4/serviceSpecification?type=CustomerFacingServiceSpecification",
"EXTERNAL_TMF_API_OAUTH2_SCOPES": "",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_ID": "123"
}
}
},
"fiveGServiceOrderData": {
"serviceOrderId": "2c4fecbc-c436-4f8c-a5db-4a1159ebad2a",
"serviceId": "790daa4d-7f56-4575-8b64-c558cf518bed",
"serviceOrderItemId": "90e45010-4c2d-4036-abc3-8c6245098eb3",
"serviceSpecificationName": "5GAAS",
"serviceOrderCharacteristics": [
{
"characteristicName": "open5gs-core_ns@OSM TEN::TAC",
"characteristicType": "TEXT",
"values": [{ "value": "100", "alias": null }]
},
{
"characteristicName": "open5gs-core_ns@OSM TEN::5G Radio Nodes",
"characteristicType": "SET",
"values": [{ "value": "east_agent", "alias": "Museum East" }]
}
],
"organizationCharacteristics": {
"organizationId": "2582308c-9f26-497e-9547-ec88d60ef9ff",
"organizationName": "osl",
"characteristics": {
"EXTERNAL_TMF_API_USERNAME": "username",
"EXTERNAL_TMF_API_BASE_URL": "http://192.192.192.192:80",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_SECRET": "secret",
"EXTERNAL_TMF_API_PASSWORD": "password"
}
}
}
}
}
In the example above, the service order includes three distinct items used to populate the orchestration message:
- End User Service Order Item: Contains Helm chart repository information and the target Kubernetes service ID for deployment.
- Kubernetes Service Item: Configured via the
serviceOrderCharacteristicsfield. - 5G Service Order Item: Also utilizes
serviceOrderCharacteristicsfor network-specific parameters.
Both the Kubernetes and 5G items include an organizationCharacteristics field.
This contains the necessary metadata for the peered organization, enabling the orchestration of services across a peered OSS.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/serviceActivationAndConfiguration/v4 | 4.0.0 | Provides the ability to activate/deactivate services in the service inventory |
Upon service activation, a (set of) service instance(s) is/are available in a target infrastructure. These instances are kept in a database that follows TMF638 Service Inventory Management API specification (TMF638), as shown in Table 8. This API makes runtime information about service instances available to the end users.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/serviceInventory/v4 | 4.0.0 | Provides the ability to query and manipulate active service instances |
ETSI HypO implements TMF's Service Quality Management API (TMF657) to describe an active service's quality criteria as shown in Table 9.
Service Update Orchestration
TMF API can determine via a set or rules if the update needs to be handled to other systems as well. In all cases SONATA can handle the service update orchestration. The suitable SONATA process for each case can be triggered via messages published in various KAFKA channels.
Activate End User Service
If the service state is updated to ACTIVE and the specification is related to an end user cfs service then a message like the following will be sent to the KAFKA topic tmf-service-activation:
{
"id" : "8f82748e-eec2-4726-8b7d-a9643fc77a4f",
"source" : "",
"type" : "tmf-service-activation",
"specversion" : "1.0",
"data" : {
"serviceId" : "ecc4345a-2097-4c3b-a40c-a9e791cdccbb",
"state" : "ACTIVE"
}
}
The PATCH update body which triggers the above is are provided below:
{
"state": "ACTIVE"
}
Note that as long as the SONATA process is ongoing, the service remains in a transitional state PENDING_ACTIVATION.
If the process is successful the state transitions to ACTIVE via a Kafka message sent from SONATA in the channel tmf-service-update.
In case of an error in any step of the SONATA process, a message will be sent to the same KAFKA channel that will trigger the rollback of the service to its previous image before the update.
Deactivate End User Service
If the service state is updated to INACTIVE and the service specification is related to an end user cfs service then a message like the following will be sent to the KAFKA topic tmf-service-activation:
{
"id" : "8f82748e-eec2-4726-8b7d-a9643fc77a4f",
"source" : "",
"type" : "tmf-service-activation",
"specversion" : "1.0",
"data" : {
"serviceId" : "ecc4345a-2097-4c3b-a40c-a9e791cdccbb",
"state" : "INACTIVE"
}
}
The PATCH update body which triggers the above is are provided below:
{
"state": "INACTIVE"
}
Note that as long as the SONATA process is ongoing, the service remains in a transitional state PENDING_DEACTIVATION.
If the process is successful the state transitions to INACTIVE via a Kafka message sent from SONATA in the channel tmf-service-update.
In case of an error in any step of the SONATA process, a message will be sent to the same KAFKA channel that will trigger the rollback of the service to its previous image before the update.
Update End User Service Characteristics
If the user updates the end user service characteristics then a message like the following will be sent to the KAFKA topic sonata-service-update:
{
"specversion":"1.0",
"id":"21000e26-31eb-43e7-8343-88a696fd96b1",
"source":"",
"type":"sonata-service-update",
"data":{
"serviceOrderEndUserData":{
"serviceOrderId":"2c4fecbc-c436-4f8c-a5db-4a1159ebad2a",
"serviceOrderItemId":"4e0abab6-25d4-4204-b6e1-aea09f642d49",
"serviceId":"790daa4d-7f56-4575-8b64-c558cf518bed",
"k8sServiceId" : "2f1d01c8-80f6-420a-b7d1-a2aa681bde1d",
"serviceName":"CMS",
"servicePackageManager":"HELM",
"serviceRepositoryURL":"someUrl",
"serviceArtifactIdentifier":"react-nginx/compose.yaml",
"serviceArtifactVersion":"1.0.0",
"requestedCompletionDate":"2048-02-13T11:27:56.705567622Z"
}
}
}
A sample PATCH update body is provided below. Note that TMF API can detect that such a change occurs by comparing the characteristics provided with the existing. This means that the user can either provide the characteristics that change value, or all characteristics that exist with the changes in some of the characteristics. In both cases the outcome will be the same.
{
"serviceCharacteristic": [
{
"id": "7a2a1bbc-2083-47e7-a240-dc5265f0cfce",
"name": "Service artifact version",
"value": {
"value": "1.0.2",
"alias": null
},
"valueType": "TEXT",
"characteristicRelationship": [],
"@baseType": "BaseRootEntity"
}
]
}
Note that as long as the SONATA process is ongoing, the service remains in a transitional state PENDING_UPDATE.
If the process is successful the state transitions to its previous state.
This is again determined by message published by SONATA in the Kafka topic tmf-service-update.
In case of an error in any step of the SONATA process, a message will be sent to the same KAFKA channel that will trigger the rollback of the service to its previous image before the update.
One particular case that is worth mentioning is the Kubernetes Service Id. If this value changes, HypO will migrate the end user service to the cluster corresponding to the new id provided and uninstall it from the previous one. The PATCH update body is provided below:
{
"serviceCharacteristic": [
{
"id": "7c4926c7-9abe-423d-8293-47d8a0fb737d",
"name": "Kubernetes Service ID",
"value": {
"value": "2d1a4226-3373-4969-8b67-79ed701dfb68",
"alias": null
},
"valueType": "TEXT",
"characteristicRelationship": [],
"@type": "org.etsi.osl.hypo.api.tmf.svc.catalog.schema.ServiceSpecCharacteristic"
}
]
}
Update Platform Service Characteristics
If the user updates the platform service (Kubernetes/5G service) characteristics then a message like the following will be sent to the KAFKA topic tmf-platform-service-update:
{
"specversion":"1.0",
"id":"21000e26-31eb-43e7-8343-88a696fd96b1",
"source":"",
"type":"tmf-platform-service-update",
"data":{
"serviceOrderId":"2c4fecbc-c436-4f8c-a5db-4a1159ebad2a",
"serviceOrderItemId":"4e0abab6-25d4-4204-b6e1-aea09f642d49",
"serviceId":"790daa4d-7f56-4575-8b64-c558cf518bed",
"serviceCharacteristics":[
{
"characteristicName":"Number of worker nodes",
"characteristicType":"TEXT",
"values":[
{
"value":"10",
"alias":null
}
]
}
],
"organizationCharacteristics":{
"organizationId":"2582308c-9f26-497e-9547-ec88d60ef9ff",
"organizationName":"osl",
"characteristics":{
"EXTERNAL_TMF_API_USERNAME":"admin",
"EXTERNAL_TMF_API_BASE_URL":"http://192.192.192.192:80",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_SECRET":"secret",
"EXTERNAL_TMF_API_PASSWORD":"password",
"EXTERNAL_TMF_API_OAUTH2_TOKEN_URI":"",
"EXTERNAL_TMF_API_SERVICE_CATEGORY_URL":"/tmf-api/serviceCatalogManagement/v4/serviceCategory",
"EXTERNAL_TMF_API_CLIENT_REGISTRATION_ID":"1234",
"EXTERNAL_TMF_API_SERVICE_CATALOG_URL":"/tmf-api/serviceCatalogManagement/v4/serviceSpecification?type=CustomerFacingServiceSpecification",
"EXTERNAL_TMF_API_OAUTH2_SCOPES":"",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_ID":"123"
}
}
}
}
Note that as long as the SONATA process is ongoing, the service remains in a transitional state PENDING_UPDATE.
If the process is successful the state transitions to its previous state.
This is again determined by message published by SONATA in the Kafka topic tmf-service-update.
In case of an error in any step of the SONATA process, a message will be sent to the same KAFKA channel that will trigger the rollback of the service to its previous image before the update.
Note than in this case since the service is provided and maintained by the underlying OSS, a subsequent service update request will be performed via OSS Client.
Terminate End User Service
If the service has its state updated to TERMINATED or a change occurs to its scheduled termination via updating the endDate field then a Kafka message is published in the Kafka topic tmf-end-user-service-termination that triggers a SONATA process.
{
"id": "8f82748e-eec2-4726-8b7d-a9643fc77a4f",
"source": "",
"type": "tmf-end-user-service-termination",
"kogitoprocinstanceid": "ce604c0c-9d80-4712-9286-061fee21236a",
"specversion": "1.0",
"data": {
"serviceTerminationData": {
"serviceOrderId": "cb791390-10ce-494d-9d37-192bb22c7903",
"serviceOrderItemId": "74dc5e22-da5e-4cc2-a2af-324bb300c2a0",
"serviceId": "c04f3d66-5350-49ea-8b31-ff325f149232",
"k8sServiceId": "bbaf20e9-9de9-4cfd-87a4-12315005f334"
},
"requestedTerminationDate": "2024-02-13T11:27:56Z"
}
}
The PATCH update body can be one of the two, where state is updated to TERMINATED or a new endDate is provided:
{
"state": "TERMINATED"
}
{
"endDate": "2036-12-20T15:23:53Z"
}
In the case of the state update, note that as long as the SONATA process is ongoing, the service remains in a transitional state PENDING_TERMINATION.
If the process is successful the state transitions to TERMINATED via a Kafka message sent from SONATA in the channel tmf-service-update.
In case of an error in any step of the SONATA process, a message will be sent to the same KAFKA channel that will trigger the rollback of the service to its previous image before the update.
Terminate Kubernetes User Service
If the Kubernetes service has its state updated to TERMINATED or a change occurs to its scheduled termination via updating the endDate field then a Kafka message is published in the Kafka topic tmf-kubernetes-service-termination that triggers a SONATA process.
{
"id": "8f82748e-eec2-4726-8b7d-a9643fc77a4f",
"source": "",
"type": "tmf-kubernetes-service-termination",
"kogitoprocinstanceid": "ce604c0c-9d80-4712-9286-061fee21236a",
"specversion": "1.0",
"data": {
"serviceTerminationData": {
"serviceOrderId": "cb791390-10ce-494d-9d37-192bb22c7903",
"serviceOrderItemId": "74dc5e22-da5e-4cc2-a2af-324bb300c2a0",
"serviceId": "c04f3d66-5350-49ea-8b31-ff325f149232",
"organizationCharacteristics":{
"organizationId":"2582308c-9f26-497e-9547-ec88d60ef9ff",
"organizationName":"osl",
"characteristics":{
"EXTERNAL_TMF_API_USERNAME":"admin",
"EXTERNAL_TMF_API_BASE_URL":"http://192.192.192.192:80",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_SECRET":"secret",
"EXTERNAL_TMF_API_PASSWORD":"password",
"EXTERNAL_TMF_API_OAUTH2_TOKEN_URI":"",
"EXTERNAL_TMF_API_SERVICE_CATEGORY_URL":"/tmf-api/serviceCatalogManagement/v4/serviceCategory",
"EXTERNAL_TMF_API_CLIENT_REGISTRATION_ID":"1234",
"EXTERNAL_TMF_API_SERVICE_CATALOG_URL":"/tmf-api/serviceCatalogManagement/v4/serviceSpecification?type=CustomerFacingServiceSpecification",
"EXTERNAL_TMF_API_OAUTH2_SCOPES":"",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_ID":"123"
}
}
},
"requestedTerminationDate": "2024-02-13T11:27:56Z"
}
}
In the case of the state update, note that as long as the SONATA process is ongoing, the service remains in a transitional state PENDING_TERMINATION.
If the process is successful the state transitions to TERMINATED via a Kafka message sent from SONATA in the channel tmf-service-update.
In case of an error in any step of the SONATA process, a message will be sent to the same KAFKA channel that will trigger the rollback of the service to its previous image before the update.
The PATCH update bodies which trigger this operation are the same as in the case of end user service.
Note that in this case OSS Client provided and maintains the service above. So a subsequent termination request is performed via OSS Client.
Terminate 5G User Service
If the 5G service has its state updated to TERMINATED or a change occurs to its scheduled termination via updating the endDate field then a Kafka message is published in the Kafka topic tmf-five-g-service-termination that triggers a SONATA process.
{
"id": "8f82748e-eec2-4726-8b7d-a9643fc77a4f",
"source": "",
"type": "tmf-five-g-service-termination",
"kogitoprocinstanceid": "ce604c0c-9d80-4712-9286-061fee21236a",
"specversion": "1.0",
"data": {
"serviceTerminationData": {
"serviceOrderId": "cb791390-10ce-494d-9d37-192bb22c7903",
"serviceOrderItemId": "74dc5e22-da5e-4cc2-a2af-324bb300c2a0",
"serviceId": "c04f3d66-5350-49ea-8b31-ff325f149232",
"organizationCharacteristics":{
"organizationId":"2582308c-9f26-497e-9547-ec88d60ef9ff",
"organizationName":"osl",
"characteristics":{
"EXTERNAL_TMF_API_USERNAME":"admin",
"EXTERNAL_TMF_API_BASE_URL":"http://192.192.192.192:80",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_SECRET":"secret",
"EXTERNAL_TMF_API_PASSWORD":"password",
"EXTERNAL_TMF_API_OAUTH2_TOKEN_URI":"",
"EXTERNAL_TMF_API_SERVICE_CATEGORY_URL":"/tmf-api/serviceCatalogManagement/v4/serviceCategory",
"EXTERNAL_TMF_API_CLIENT_REGISTRATION_ID":"1234",
"EXTERNAL_TMF_API_SERVICE_CATALOG_URL":"/tmf-api/serviceCatalogManagement/v4/serviceSpecification?type=CustomerFacingServiceSpecification",
"EXTERNAL_TMF_API_OAUTH2_SCOPES":"",
"EXTERNAL_TMF_API_OAUTH2_CLIENT_ID":"123"
}
}
},
"requestedTerminationDate": "2024-02-13T11:27:56Z"
}
}
In the case of the state update, note that as long as the SONATA process is ongoing, the service remains in a transitional state PENDING_TERMINATION.
If the process is successful the state transitions to TERMINATED via a Kafka message sent from SONATA in the channel tmf-service-update.
In case of an error in any step of the SONATA process, a message will be sent to the same KAFKA channel that will trigger the rollback of the service to its previous image before the update.
The PATCH update bodies [which trigger this operation are the same as in the case of end user service.
Note that in this case OSS Client provided and maintains the service above. So a subsequent termination request is performed via OSS Client.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/serviceQualityManagement/v4 | 4.0.0 | Describe a service's quality criteria |
🔖 TMF Resource Management APIs
ETSI HypO leverages TMF's Resource Catalog Management API specification (TMF634) to encode resources into abstract resource specifications, which can be then organized in various resource catalogs, each with one or more resource categories, as shown in Table 10.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/resourceCatalogManagement/v4 | 4.1.0 | Provides a catalog of resources |
| /tmf-api/resourceCategoryManagement/v4 | 4.1.0 | Provides a category of resources that belongs to a certain catalog |
| /tmf-api/resourceCandidateManagement/v4 | 4.1.0 | Provides a candidate of resources that belongs to a certain category |
| /tmf-api/resourceSpecificationManagement/v4 | 4.1.0 | Provides a specification of resources that maps to a certain candidate |
Once a resource is stored into a resource catalog, users can order it using TMF's Resource Ordering API specification (TMF652), as shown in Table 11. A resource order may comprise one or more resource specifications, thus users may request composite resources.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/resourceOrderingManagement/v4 | 4.0.0 | Provides the ability to manage resource orders that comprise of one or more resource specifications |
A completed resource order results in an available resource instance. These instances are kept in a database that follows TMF's Resource Inventory Management API specification (TMF639), as shown in Table 12. This API makes runtime information about resource instances available to the end users.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/resourceInventoryManagement/v4 | 4.0.0 | Provides the ability to query and manipulate active resource instances |
🔖 TMF Party Management APIs
Party is an abstract concept that represents an individual (person) or an organization that has any kind of relation with the enterprise. ETSI HypO leverages TMF's Party Management API (TMF632) to encode parties and their characteristics, while TMF's Party Role Management API (TMF669) is used to associate a party with one or more roles. ETSI HypO also uses TMF's Partnership Management API (TMF668) to encode relations between parties. These API endpoints are shown in Table 13.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/party/v4/individual | 4.0.0 | Manage individual parties |
| /tmf-api/party/v4/organization | 4.0.0 | Manage corporate parties (i.e., organizations) |
| /tmf-api/partyRoleManagement/v4 | 4.0.0 | Manage party roles |
| /tmf-api/partnershipManagement/v4 | 4.0.0 | Manage partnership relations |
🔖 TMF Alarm Management API
There is a strong desire from Service Providers to provide a Fault Management interface that can be used in a simple way to do simple alarm reporting, while also covering more complex OSS-to-OSS scenarios. ETSI HypO leverages TMF's Alarm Management API (TMF642) to encode this type of alarms related to services, resources, or products.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/alarmManagement/v5/alarm | 5.0.0 | Manage alarms |
🔖 TMF Location Management APIs
ETSI HypO needs to be aware of the underlying domains' locations as well as the resources offered by these domains. To do so, ETSI HypO leverages TMF's Geographic Site Management API (TMF674) to encode the abstract location of a domain along with specific addresses (TMF673) where this domain offers resources, as shown in Table 14. The later API is part of the TMF 674, as the geographic site data model encloses a list of geographic address data models.
| Endpoint | Version | Description |
|---|---|---|
| /tmf-api/geographicSiteManagement/v5 | 5.0.0 | Manage resource locations at abstract sites, where each site may contain a list of geographic addresses |