Open APIs

Expand all | Collapse all

Taking 633 Service Specifications into 638 Services

  • 1.  Taking 633 Service Specifications into 638 Services

    TM Forum Member
    Posted 25 days ago
    Hi All,

    I've posted previously on the arrangement and linking of service specifications on the catalog and the use of poly morphism which is suggested by the SID examples.

    Now i'm trying to conceive how this transitions into inventory via an order. In the service order API (and inventory) the TMF swagger's just have the service as a single object and the examples in the document dont really show polymorphism (@type = 'service'). So faced with the idea that we are thinking of using poly morphism in the catalog(specifications) I wonder which would be the recommeded approach for order/inventory?

    633-641-638-combined-model


    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------


  • 2.  RE: Taking 633 Service Specifications into 638 Services

    TM Forum Member
    Posted 17 days ago
    Hi David
    I don't think that there is a preference one way or another, it really depends on your business needs and your software architecture considerations.

    P.S. For a realistic example of the strong typing (with polymorphism) as against fully dynamic, see the introduction in the user guide for TMF634 Resource Catalog - I show there how the same resource specification can be modeled dynamically with characteristics or with strongly typed attributes.

    P.P.S. sorry for delay in answering, I have now finished holiday/vacation period and am back to normal work.

    ------------------------------
    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: Taking 633 Service Specifications into 638 Services

    TM Forum Member
    Posted 17 days ago

    Everyone needs a good holiday @Jonathan Goldberg, hope you had a good rest!

    Thanks for getting back to me as always.

    I suppose whilst i understand that we can achieve it two different ways my question was really saying if we were to use polymorphism and strong typing in the catalog then shouldnt this also be used in the inventory? I thought that each sub classed specification in the catalog with its own extended attribute data would have to have an equ​ivilent sub classed service in the inventory world? If not (my OR THIS approach above) how do the extension attributes get passed by a client via an order in TMF641 to inventory?

    I did look up your example (TMF634 v4.0.1), thanks for the pointer, its left me with more questions! I'm thinking im missing something but it appears the example contridicts the example given in TMF630 Part2 (v4.0.0). This shows this swagger definition as 

    PhysicalResource:
    title: PhysicalResource
    type: object
    properties:
    id:
    type: integer
    
    Equipment:
    title: Equipment
    type: object
    allOf:
    - $ref: "#/definitions/PhysicalResource"
    - properties:
    operatingState:
    type: string


    and then an example here (ive cut it down)...

    It has the following differences i could see: -
    A - the @type is 'Equipment' which is the custom polymorphic extenstion, Looking at your example it appears to suggest that the @type should actually still be 'PhysicalResource'
    B - the 630 example makes no use of targetResourceSchema field, your example does.

    Is one or the other correct or are these two different methods of extension? I couldnt find an example like yours in 634 within the TMF630 extension guide

    {
    "id": "45",
    "href": "/resourceInventoryManagement/physicalResource/45",
    "publicIdentifier": "07467223333",
    "@type": "Equipment",
    "@baseType": "PhysicalResource",
    "@schemaLocation":
    "http://server:port/resourceInventoryManagement/schema/Equipment.yml",
    "category": "Category 1",
    "lifecyleState": "Active",
    "manufactureDate": "2007-04-12",
    "serialNumber": "123456745644",
    "versionNumber": "11",
    "operatingState": "Working",
    "resourceSpecification": {
    "id": "6",
    "href": "/resourceCatalogManagement/resourceSpecification/6",
    "@type": "PhysicalResourceSpecification"
    },
    "resourceCharacteristic": [{
    "name": "physicalPort",
    "valueType":"Object",
    "value": {
    "@type": "PhysicalPort",
    "@schemaLocation": "http://host:port/schema/PhysicalPort.yml",
    "name": "LAN Port",
    "isActive": true
    }
    },
    {
    "name": "color",
    "value": "red"
    }]
    }






    ​​​​​

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 4.  RE: Taking 633 Service Specifications into 638 Services

    TM Forum Member
    Posted 16 days ago
    Hi Dave
    I was actually referring to the section called Characteristic-Based or Schema-Based in the introduction of TMF634 user guide.
    Compare the two JSON payloads below.
    Hope it helps.

    Dynamic
    {
        "name": "Virtual Storage Medium",
        "description": "This resource specification defines the virtual storage medium",
        "@type": "LogicalResourceSpecification",
        "@baseType": "ResourceSpecification",
        "resourceSpecCharacteristic": [
            {
                "name": "Maximum Allowed Storage",
                "description": "The storage limit in the virtual storage medium, ",
                "valueType": "integer",
                "configurable": true,
                "minCardinality": 1,
                "maxCardinality": 1,
                "isUnique": true,
                "resourceSpecCharacteristicValue": [
                    {
                        "valueType": "integer",
                        "value": 1024000
                    },
                    {
                        "valueType": "integer",
                        "value": 2048000
                    }
                ]
            }
        ]
    }
    ​

    Schema-based
    {
        "name": "Virtual Storage Medium",
        "description": "This resource specification defines the virtual storage medium",
        "@type": "LogicalResourceSpecification",
        "@baseType": "ResourceSpecification",
        "targetResourceSchema": {
            "@type": "VirtualStorage",
            "@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Resource/VirtualStorage.schema.json"
        }
    }
    And the referred schema file might appear as follows:
    {
        "$schema": "http://json-schema.org/draft-07/schema#",
        "$id": "VirtualStorage.schema.json",
        "title": "VirtualStorage",
        "definitions": {
            " VirtualStorage ": {
                "$id": "# VirtualStorage ",
                "description": "This resource specification defines the virtual storage medium.",
                "type": "object",
                "properties": {
                    "Maximum Allowed Storage": {
                        "type": "integer", 
                        "description": "The storage limit in the virtual storage medium",
                        "enum": [1024000, 2048000]
                    } 
                },
                "required": ["Maximum Allowed Storage"],
                "allOf": [
                    {
                        "$ref": "LogicalResourceSpecification.schema.json#LogicalResourceSpecification"
                    }
                ]
            }
        }
    }
    ​



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



  • 5.  RE: Taking 633 Service Specifications into 638 Services

    TM Forum Member
    Posted 16 days ago
    understood @Jonathan Goldberg, thanks, that was what i have been looking at, forgive me if im interpreting it incorrectly but if i were to translate the example given in TMF630 into your example i believe it would look like the below and not what you have in the 634 document. Can you point out what im missing?...

    ResourceSpecification:
    title: ResourceSpecification
    type: object
    properties:
    id:
    type: integer
    
    LogicalResourceSpecification:
    title: LogicalResourceSpecification
    type: object
    allOf:
       - $ref: "#/definitions/ResourceSpecification"
    properties:
    name:
       type: string
    
    VirtualStorage:
    title: VirtualStorage
    type: object
    allOf:
       - $ref: "#/definitions/LogicalResourceSpecification"
    properties:
    maximumAllowedStorage:
       type: integer
       enum:[1024000, 2048000]​

    Example (not sure ive got this completely right but hopefully you get the idea of the confusion i have with the different approaches)

    {
    "id": "45",
    "href": "/resourceCatalogManagement/resourceSpeification/45",
    "name": "Virtual Storage Medium"
    "@type": "VirtualStorage",
    "@baseType": "LogicalResourceSpecification",
    "@schemaLocation": "http://server:port/resourceCatlogManagement/schema/VirtualStorage.yml",
    "maximumAllowedStorage": [1024000, 2048000]
    }​



    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------



  • 6.  RE: Taking 633 Service Specifications into 638 Services

    TM Forum Member
    Posted 4 days ago
    Hey @Jonathan Goldberg could you help at all with my confusion on the items above at all?​

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------