Open APIs

 View Only
  • 1.  TMF633: Representing nested objects in Service Specification

    Posted Mar 23, 2021 09:33
    Hi,

    We are using TMF633 to publish the service catalog that is consumed by SOM to create TMF641 service order.

    We have nested objects in the service model, such as below. Here enniServiceList is an array of objects with each object containing two attributes maxNumOfOvc and maxNumOfOvcEndPoints.

    {
      "valueType": "array",
      "name": "enniServiceList",
      "value": [
        {
          "maxNumOfOvcs": 1,
          "maxNumOfOvcEndPoints": 2
        }
      ]
    }​

    I would like to know if below is the best way to represent this information as serviceSpecCharacteristics in TMF633 service specification or is there an alternative? Here we have used items to represent the type of object in the array and then we have used the delimiter (.) to  represent the attributes of the object. 

    {
      "serviceSpecCharacteristic": [
        {
          "name": "enniServiceList.items",
          "valueType": "object",
          "displayType": "NORMAL",
          "serviceSpecCharacteristicValue": [],
          "@type": "ServiceSpecCharacteristicenniServiceList.items"
        },
        {
          "name": "enniServiceList.items.maxNumOfOvcs",
          "configurable": true,
          "extensible": false,
          "isUnique": false,
          "maxCardinality": 1,
          "minCardinality": 1,
          "valueType": "integer",
          "displayType": "RANGE",
          "serviceSpecCharacteristicValue": [
            {
              "isDefault": false,
              "rangeInterval": "closedBottom",
              "valueFrom": 1,
              "valueType": "integer",
              "@baseType": "ServiceSpecCharacteristicValue",
              "@type": "ServiceSpecCharacteristicValue.enniServiceList.items.maxNumOfOvcs"
            }
          ],
          "@baseType": "ServiceSpecCharacteristic",
          "@type": "ServiceSpecCharacteristic.enniServiceList.items.maxNumOfOvcs"
        },
        {
          "name": "enniServiceList.items.maxNumOfOvcEndPoints",
          "configurable": true,
          "extensible": false,
          "isUnique": false,
          "maxCardinality": 1,
          "minCardinality": 1,
          "valueType": "integer",
          "displayType": "RANGE",
          "serviceSpecCharacteristicValue": [
            {
              "isDefault": false,
              "rangeInterval": "closedBottom",
              "valueFrom": 1,
              "valueType": "integer",
              "@baseType": "ServiceSpecCharacteristicValue",
              "@type": "ServiceSpecCharacteristicValue.enniServiceList.items.maxNumOfOvcEndPoints"
            }
          ],
          "@baseType": "ServiceSpecCharacteristic",
          "@type": "ServiceSpecCharacteristic.enniServiceList.items.maxNumOfOvcEndPoints"
        },
        {
          "name": "enniServiceList",
          "configurable": true,
          "extensible": false,
          "isUnique": false,
          "maxCardinality": 1,
          "minCardinality": 1,
          "valueType": "array",
          "displayType": "NORMAL",
          "serviceSpecCharacteristicValue": [
            {
              "isDefault": false,
              "valueType": "array",
              "@baseType": "ServiceSpecCharacteristicValue",
              "@type": "ServiceSpecCharacteristicValue.enniServiceList"
            }
          ],
          "@baseType": "ServiceSpecCharacteristic",
          "@type": "ServiceSpecCharacteristic.enniServiceList"
        }
      ]
    }​


    Thanks
    Kanika

    ------------------------------
    Kanika Aggarwal
    VOCUS PTY LTD
    ------------------------------


  • 2.  RE: TMF633: Representing nested objects in Service Specification

    TM Forum Member
    Posted Apr 04, 2021 22:32
    Hi Kanika, we are doing something similar at Telstra and I'm just working out how to express in our TMF633 catalog too. In my specifications the value objects nested within serviceCharacteristic objects are just objects, not fully fledged serviceCharacteristic. So I think the correct way is to have a ServiceSpecCharacteristic for each ServiceCharacteristic, and to have this contain a @valueSchemaLocation to the json that describes the serviceCharacteristic fully, including your nested objects.

        {
          "name": "pri",
          "description": "Product Instance value object",
          "valueType": "object",
          "configurable": true,
          "minCardinality": 1,
          "maxCardinality": 1,
          "isUnique": "true",
          "extensible": "false",
          "@type": "ServiceSpecCharacteristic",
          "@baseType": "Characteristic",
          "@valueSchemaLocation": "/schemaManagement/v1/nbnCVC_pri_v1.json"
        },​
    One alternative we rejected was to structure the service with flat serviceCharacteristic and use CharacteristicSpecificationRelationship as it was designed. This of course makes your serviceCharacteristic payloads lose obvious structure, and also may complicate your modification transactions.

    Hope this helps!

    ------------------------------
    Matt Beanland
    Telstra Corporation
    ------------------------------



  • 3.  RE: TMF633: Representing nested objects in Service Specification

    Posted Apr 05, 2021 07:51
    Thanks Matt for getting back and sharing an example of your work.

    Any particular reasons that you rejected was to use CharacteristicSpecificationRelationship (serviceSpecCharRelationship)?

    Also how and where would you persist /schemaManagement/v1/nbnCVC_pri_v1.json (consider a multi-host environment for instance). I think this json then needs to be re-generated every time you add a new attribute to that object, do you have any automation for that too?


    ------------------------------
    Kanika Aggarwal
    VOCUS PTY LTD
    ------------------------------



  • 4.  RE: TMF633: Representing nested objects in Service Specification

    TM Forum Member
    Posted Apr 05, 2021 19:13
    Kanika, we've rejected serviceSpecCharRelationship principally because it works best with flat, fine grained services. We've tended to group related characteristics into value objects.

    At Telstra we have a Network Abstraction Layer (NAL) which is a gateway for BSS consumers of southbound network domains, it implements most of TMF909 NaaS component suite. Domains/cross domain orchestration also use NAL it to reach 'across' domains, enforcing domains to hide resources and expose services. The NAL has TMF633 functions to allow read/publishing of the catalog, and they include the validation and hosting of schemas that may describe/extend TMF classes or describe serviceCharacteristic. So the answer is {naas_host}/schemaManagement/v1/{serviceCharacteristicJson} depending on model or prod.

    We don't add attributes to services that often, but if this was done in a back compatible way it would be pretty minor and the serviceSpecification could be updated at runtime to point to a later version of the e.g. /schemaManagement/v1/nbnCVC_pri_v2.json describing both the old and new attributes now present/allowed on the service.


    ------------------------------
    Matt Beanland
    Telstra Corporation
    ------------------------------



  • 5.  RE: TMF633: Representing nested objects in Service Specification

    TM Forum Member
    Posted Apr 06, 2021 02:29
    Interesting thread.
    Comment from an OSS ignoramus (me): Did you consider representing these complex value objects as contained Services, with "simple" characteristics. This would (perhaps) allow you to model the service structure using vanilla TMF633 without the need for schema extensions. But maybe this doesn't match your business aims.
    Just a thought.
    @Kamal Maghsoudlou and @Ludovic Robert might be interested in your use of the service-related APIs, as (of course) the NaaS Maven herself @Johanne Mayer​​​​

    ------------------------------
    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.
    ------------------------------



  • 6.  RE: TMF633: Representing nested objects in Service Specification

    Posted Apr 06, 2021 03:06
    Thanks @Jonathan Goldberg for getting back. Our use case is to represent the services using MEF7.3 model, that doesn't give us an option to represent the objects as contained services. MEF objects are quite nested in nature and hence this query.​

    ------------------------------
    Kanika Aggarwal
    VOCUS PTY LTD
    ------------------------------



  • 7.  RE: TMF633: Representing nested objects in Service Specification

    TM Forum Member
    Posted Apr 06, 2021 05:05
    Jonathan, Yes but they aren't actually services, they just represent either the intent (and sometimes the detail) of a single facet of the service. Regards, Matt

    ------------------------------
    Matt Beanland
    Telstra Corporation
    ------------------------------



  • 8.  RE: TMF633: Representing nested objects in Service Specification

    TM Forum Member
    Posted Apr 06, 2021 05:22
    Edited by Jonathan Goldberg Apr 06, 2021 09:08
    Thanks Matt for the clarification.

    Isn't it possible that for intents you could use Features, these were part of the Resource model and API set, but have more recently moved also into the Service model and API set, if I am not mistaken (take a look at the early access table). Features have characteristics and relationships between features.

    Suggest you take a look at this possibility.

    @Vance Shipley might be interested in this.

    ------------------------------
    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.
    ------------------------------



  • 9.  RE: TMF633: Representing nested objects in Service Specification

    Posted Apr 06, 2021 03:08
    Edited by Kanika Aggarwal Apr 06, 2021 03:11
    Thanks @Matt Beanland, that makes sense. Just wondering, if your 633 catalog generation from service models is automated or hand crafted?

    ------------------------------
    Kanika Aggarwal
    VOCUS PTY LTD
    ------------------------------



  • 10.  RE: TMF633: Representing nested objects in Service Specification

    TM Forum Member
    Posted Apr 06, 2021 05:07
    Would love to say automated from the model, but not yet. We have a 'domain enablers as a service' shared tech which aims to do this and other implementation chores, such that service development and lifecycle maintenance can be done low code/no code.

    ------------------------------
    Matt Beanland
    Telstra Corporation
    ------------------------------