Open APIs

 View Only

  • 1.  TMF 667 and schemafication

    Posted Aug 24, 2020 02:30
    Hi All, 

    We have few Provider Domains who have complex service specifications. For those providers, to define the specification in the catalog using TMF 633 below is the code snippet that they can use .
    "serviceSpecCharacteristicValue": [
                    {
                    "valueType": "object",
                    "isDefault": true,
                    "value": {
                        "minInstances": 1,
                        "maxInstances": 1000,
                        "@type": "IPv4AttributesObject",
                        "@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Service/IPv4AttributesObject.schema.json"
                    },

    We are working on automating the schema management for all such complex objects and was wondering if there is already any TMF API that can be used. We came across TMF 667 and found it quite useful to upload such complex schemas. Few queries :
    1) Is TMF 667 the correct API for schemafication of complex service characteristics or is there any other way that anyone has used for this requirement?
    2) The latest version we see in Open API Table is 17.0.1 . Is there any latest version being released as we could not find anything in beta versions on this API?



    ------------------------------
    Rati Mehrotra
    Telstra Corporation
    ------------------------------


  • 2.  RE: TMF 667 and schemafication

    Posted Aug 24, 2020 09:12
    Hi Rati

    1) TMF 667 is Document Management - it has nothing to do with management of objects and schemas, rather it relates to formal documents that need to be handled and tracked as part of telco business processes. For example a contract with a business customer.
    2) TMF 667 was being worked on by @Stephen Harrop, but I am not sure what the current status is. In any case as I said in 1) I'm not sure it is relevant to what you are trying to achieve. But maybe I missed something and you have come up with a new use case for this API.

    Hope it helps

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



  • 3.  RE: TMF 667 and schemafication

    Posted Aug 25, 2020 02:48
    Hi @Jonathan Goldberg

    We are planning to introduce schema capability for reusing the serviceSpecCharacteristicValue  when the valueType is object(complex service characteristics ) across various services.  For that we were planning to use the 667 API to manage the CRUD operations on the schemas( could be a json/yaml file)
    This can also be used for holding schemas for any polymorphic extension that we do to the TMF APIs which we adopt. 

    Please let me know if this gives an understanding of our requirements ?

    Hi @Stephen Harrop,

    Can you please provide more understanding on the API and if the 667 API is suitable for the usage that I have mentioned above. We were also looking for the latest documentation on the API. 

    Thanks,
    Rati



    ​​​​​

    ------------------------------
    Rati Mehrotra
    Telstra Corporation
    ------------------------------

    Original Message


  • 4.  RE: TMF 667 and schemafication

    Posted Aug 26, 2020 01:27
    Hi Rati

    Yes you have made your requirements very clear.
    However I am still not sure that that the Documents API is what you are looking for.

    In my opinion, schemas need to be managed like software code assets, using source code control (like Git). You will almost certainly have software (e.g. java code) that is written specifically for your IPv4 service (and other services), and this code will relate to the attributes in your schema. So if your schema changes then your code will change, and vice-versa.

    The TMF Open APIs are not intended for software configuration management, rather for telco business processes.

    Perhaps @Vance Shipley has an opinion on this as well, we have had prior discussions on the semantic meaning of the @schemaLocation value.​​​

    Anyway I hope these insights are helpful, whether or not you agree with them.

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

    Original Message


  • 5.  RE: TMF 667 and schemafication

    Posted Aug 26, 2020 04:49
    I doubt the authors of TMF667 had your use case in mind but it sounds workable.  The value of the @schemaLocation attribute​ must be a URI but it doesn't have to be available for HTTP GET at that location, it's just an identifier. So I don't see any problem with using the TMF667 resource paths here.

    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


  • 6.  RE: TMF 667 and schemafication

    Posted Aug 27, 2020 23:25
    Hi @Vance Shipley,

    Thanks for your response.  We are exploring options to understand how we can have a common schema capability for our gateway which could be reusable, version managed and ​can be used for service specifications. In our landscape there are multiple provider domains ( Mobile, IP, UC etc)  who will expose multiple services.These services might have complex schemas for specifications .  Also, it is possible that there will be some common schemas that can be used across provider domains.  Since TMF 633 provides  capability for defining @schemaLocation attribute , we were looking for guidance on how to maintain the schemas.  The below example for a schemaLocation , there can be many such schemas in our case.
    "serviceSpecCharacteristicValue": [ { "valueType": "object", "isDefault": true, "value": { "minInstances": 1, "maxInstances": 1000 }, "validFor": { "startDateTime": "2017-08-17T00:00", "endDateTime": "2018-03-12T00:00" }, "@type": "CapabilityScalable", "@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Service/CapabilityScalable.schema.json" } ], "serviceSpecCharRelationship": [], "@type": "ServiceSpecCharacteristic", "@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Service/ServiceSpecCharacteristic.schema.json" } ], ​
                

    Managing through git or any other source repository would be tricky  in our landscape due to multiple provider Domains . Below is the diagram explaining the same . 

     ​​
    Please provide any guidance in this regards.

    Thanks,
    Rati

    ------------------------------
    Rati Mehrotra
    Telstra Corporation
    ------------------------------

    Original Message


  • 7.  RE: TMF 667 and schemafication

    Posted Aug 28, 2020 00:40
    At TM Forum we use git for version management of schemas. Those are sourced by tooling to create swagger (OAS) files. That is all design time activity.

    To distribute your schemas all you really need is an HTTP server. You may include version in the resource path:
    "@schemaLocation": "/serviceManagement/schema/v1/CapabilityScalable.schema.json"

    As I said previously the value here is a URI type but the schema does NOT have to be retrievable at this URI as it is simple an identifier in a namespace (your namespace).  So distribution is up to you, you may send everyone involved flash drives by FedEx if you choose.  There are no normative rules for matching the namespace identifier with a resource in your namespace either.  The obvious rules of representing directory paths are probably most suitable however. Using Apache to serve static files would be an entirely acceptable method of distribution.

    If using TMF667 adds some value for you, perhaps by documenting an API to manage the collection of schemas, that seems fine to me.

    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message


Related Content