Open APIs

Hi Team,

We have a use case for Broadband diagnostics/Service Test management where we are looking at using the TMF 653 Service Test Management API. However the current TMF 653 Service Test resource model doesn't meet our requirements where we need to capture the information including test parameters for underlying or related tests as part of the main Service Test as our current downstream system is providing in its API response. e.g. Broadband service tests may consist of related/sub tests like Speed Test, Consistency check tests etc. We are facing challenges to map the payload from the downstream system API to the TMF 653 structure in its current form. To meet our requirement we have proposed to use the extension of TMF 653 with serviceTestRelationship with relationshipType as "contains" to have the information of the related Service Test /Sub Test to capture all relevant info like TestMeasure, Characteristics etc. 

When we looked at the serviceTestSpecification resource model (Design Time) we could see serviceTestSpecRelationship indicating that one serviceTestSpecification can be related to another serviceTestSpecification resource however we haven't seen the same being reflected for the ServiceTest resource model (Run Time) . 

I am attaching the proposed extension resource model diagram here. We feel that the extension we are proposing should have been part of the ServiceTest resource model already by looking at the serviceTestSpecification resource model ? Is something being missed at TMF API side or am I missing something or if you could advise the right approach for the extension for the use case we are looking at ?

Please let me know if more info is required.

------------------------------
Suresh Barman
Vodafone UK Ltd
------------------------------

Hi Suresh,

we had exactly the same problem and we did nearly exactly the same change to our yaml. For me, this was an overlook in the existing yaml because, as you said, the relationship exists between the ServiceTestSpecification entities.

I posted the same type of request as you in the forum not long ago:

https://engage.tmforum.org/discussion/tmf653-missing-servicetestrelationship

We ended up with the following structure added:

serviceTestRelationship:
  type: array
  description: a list of ServiceTest relationships
  items:
    $ref: '#/components/schemas/ServiceTestRelationship'

and 

ServiceTestRelationship:
  allOf:
    - $ref: '#/components/schemas/Extensible'
    - type: object
      properties:
        serviceTest:
          $ref: '#/components/schemas/ServiceTestRefOrValue'
        relationshipType:
          type: string
  discriminator:
    propertyName: '@type'
    mapping:
      ServiceTestRelationship: '#/components/schemas/ServiceTestRelationship'

------------------------------
Frederic Thise
Proximus SA

Original Message:
Sent: Feb 06, 2025 10:28
From: Suresh Barman
Subject: TMF 653 Service Test Management API for serviceTestRelationship extension for related ServiceTest/SubTest

Hi Team,

We have a use case for Broadband diagnostics/Service Test management where we are looking at using the TMF 653 Service Test Management API. However the current TMF 653 Service Test resource model doesn't meet our requirements where we need to capture the information including test parameters for underlying or related tests as part of the main Service Test as our current downstream system is providing in its API response. e.g. Broadband service tests may consist of related/sub tests like Speed Test, Consistency check tests etc. We are facing challenges to map the payload from the downstream system API to the TMF 653 structure in its current form. To meet our requirement we have proposed to use the extension of TMF 653 with serviceTestRelationship with relationshipType as "contains" to have the information of the related Service Test /Sub Test to capture all relevant info like TestMeasure, Characteristics etc. 

When we looked at the serviceTestSpecification resource model (Design Time) we could see serviceTestSpecRelationship indicating that one serviceTestSpecification can be related to another serviceTestSpecification resource however we haven't seen the same being reflected for the ServiceTest resource model (Run Time) . 

I am attaching the proposed extension resource model diagram here. We feel that the extension we are proposing should have been part of the ServiceTest resource model already by looking at the serviceTestSpecification resource model ? Is something being missed at TMF API side or am I missing something or if you could advise the right approach for the extension for the use case we are looking at ?

Please let me know if more info is required.

------------------------------
Suresh Barman
Vodafone UK Ltd
------------------------------

Hi Team,

We have a use case for Broadband diagnostics/Service Test management where we are looking at using the TMF 653 Service Test Management API. However the current TMF 653 Service Test resource model doesn't meet our requirements where we need to capture the information including test parameters for underlying or related tests as part of the main Service Test as our current downstream system is providing in its API response. e.g. Broadband service tests may consist of related/sub tests like Speed Test, Consistency check tests etc. We are facing challenges to map the payload from the downstream system API to the TMF 653 structure in its current form. To meet our requirement we have proposed to use the extension of TMF 653 with serviceTestRelationship with relationshipType as "contains" to have the information of the related Service Test /Sub Test to capture all relevant info like TestMeasure, Characteristics etc. 

When we looked at the serviceTestSpecification resource model (Design Time) we could see serviceTestSpecRelationship indicating that one serviceTestSpecification can be related to another serviceTestSpecification resource however we haven't seen the same being reflected for the ServiceTest resource model (Run Time) . 

I am attaching the proposed extension resource model diagram here. We feel that the extension we are proposing should have been part of the ServiceTest resource model already by looking at the serviceTestSpecification resource model ? Is something being missed at TMF API side or am I missing something or if you could advise the right approach for the extension for the use case we are looking at ?

Please let me know if more info is required.

Dear Suresh,

Hi Team,

We have a use case for Broadband diagnostics/Service Test management where we are looking at using the TMF 653 Service Test Management API. However the current TMF 653 Service Test resource model doesn't meet our requirements where we need to capture the information including test parameters for underlying or related tests as part of the main Service Test as our current downstream system is providing in its API response. e.g. Broadband service tests may consist of related/sub tests like Speed Test, Consistency check tests etc. We are facing challenges to map the payload from the downstream system API to the TMF 653 structure in its current form. To meet our requirement we have proposed to use the extension of TMF 653 with serviceTestRelationship with relationshipType as "contains" to have the information of the related Service Test /Sub Test to capture all relevant info like TestMeasure, Characteristics etc. 

When we looked at the serviceTestSpecification resource model (Design Time) we could see serviceTestSpecRelationship indicating that one serviceTestSpecification can be related to another serviceTestSpecification resource however we haven't seen the same being reflected for the ServiceTest resource model (Run Time) . 

I am attaching the proposed extension resource model diagram here. We feel that the extension we are proposing should have been part of the ServiceTest resource model already by looking at the serviceTestSpecification resource model ? Is something being missed at TMF API side or am I missing something or if you could advise the right approach for the extension for the use case we are looking at ?

Please let me know if more info is required.