Open APIs

 View Only
Expand all | Collapse all

TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

  • 1.  TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 24 days ago

    We are trying to map TMF639 Open API resource response to one of our physical inventory which has some specific attributes. We would like to know how to include these specific attributes into the Resource Open API GET response.

    For example: Tower (cell tower) inventory has specific attributes like TowerNumber, Height, Antenna Load, etc. How to include these attributes in to Resource Open API GET response?



    ------------------------------
    Arko Chakravarty
    VCT International
    ------------------------------


  • 2.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 22 days ago
    Hi Arko
    The resource inventory (like other inventories such as product, service) is driven by catalog. So in the Resource Catalog (TMF633) you define characteristics for different resource types (such as Tower, Switch, Router, Firewall, etc.). These characteristics are what you refer to as attributes.
    An alternative approach is to define specific subclasses of LogicalResource or PhysicalResource, e.g. Tower, and give these subclasses strongly-typed attributes. This is described in summary in the user guide for TMF633, suggest you look there.
    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: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 14 days ago
    Edited by Arko Chakravarty 14 days ago
    Hi Jonathan,
    Thanks for your valuable comment  . After going through the document I am able to mapped  some of these specific attributes   in resourceCharacteristic by  Characteristic-based  but unable to figure it out map it via Schema -based .Can you please help me to do the same with Schema -based. Shared below sample example with Characteristic-based.
    Resource Catalog included, present two complementary methods
    • Characteristic-based
    • Schema-based

    For  Characteristic base

    "resourceCharacteristic": [
    {
    "name": "poleNumber",
    "valueType": "string",
    "value": "pole001"
    },{
    "name": "height",
    "valueType": "integer",
    "value": 56
    },
    {
    "name": "heightUnits",
    "valueType": "string",
    "value": "cm"
    },{
    "name": "diameter",
    "valueType": "integer",
    "value": 5
    },
    {
    "name": "diameterUnits",
    "valueType": "string",
    "value": "cm"
    },{
    "name": "loadCapacity",
    "valueType": "integer",
    "value": 67
    },
    {
    "name": "material",
    "valueType": "string",
    "value": "iron"
    },{
    "name": "isShared",
    "valueType": "boolean",
    "value": false
    }
    ],

    ------------------------------
    Arko Chakravarty
    VCT International
    ------------------------------



  • 4.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 12 days ago
    Hi Arko
    How about something like this? Note that I have not included values here, because this is a defining schema - the values would be in a payload generated according to this schema. I also re-used the Quantity type that encapsulates value and units for things like height, weight, etc.
    Hope it helps
    "Pole" {
    "type": "object",
    "properties": {
       "poleNumber": {
           "type": "string",
           "description": "identifying number of the pole"
       },
       "height": {
          "$ref": "../Common/Quantity.schema.json#Quantity",
          "description": "height of the pole - includes units and amount"
      },
       "isShared": {
          "type": "boolean",
          "description": "indicates if the pole is shared by multiple service providers"
      },
       "loadCapacity": {
          "type": "number",
          "description": "How much can the pole take"
      }
    }
    }

    ------------------------------
    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: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 11 days ago
    Hi,
    Can you please give some example of the payload according to the above schema 

    ------------------------------
    Arko Chakravarty
    VCT International
    ------------------------------



  • 6.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 11 days ago

    I guess it would look something like (I took the values from your original post). Hope it helps
    {
    "poleNumber": "pole001",
    "height": {"units": "cm", "amount": 65.0},
    "isShared": true,
    "loadCapacity": 65.7

    }



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



  • 7.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 11 days ago
    Hi,

    in my opinion the ResourceCatalog (TMF634) should contain a concrete type instead of a abstract type (as ResourceSpecification).
    E.g. instead of "router" the ResourceCatalog should contain all the models of routers you use in the field.

    You can then specify your attributes as characteristics in the ResourceSpecification (you will have to do this for every type).
    If you don't want to define the characteristics for each type individually you can use schema based extension. In that case you would create a json schema for your characteristics that inherits all properties from PhysicalResource (of TMF639) and create a reference to this schema from all your "router" ResourceSpecifications via the "targetResourceSchema" attribute.

    ------------------------------
    Henrik Kletke
    Deutsche Telekom AG
    ------------------------------



  • 8.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 11 days ago
    Hi Henrik

    In the user guide for TMF634 (resource catalog) you will find a short section (written by yours truly) describing the two approaches: schema-based strongly typed as against completely dynamic characteristic based. There are advantages and disadvantages to both approaches. The main gap that we need to be aware of in the schema-based approach is that we haven't figured out how to express the rich metadata that goes beyond JSON schema capabilites.

    ------------------------------
    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: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 11 days ago
    Hi Henrik,

    I completely agree with you. I even believe this was the original intention of the ResourceCandidate entity but it never got properly documented that way.

    I can provide some examples

    1. The actual resource used matters to the customer

    2. The actual resource used doesn't matter to the customer


    The same resourceCandidate can also used to document more complex stuff like
    • This Homegateway has 4 ethernetports, a wifi-port and a DSL-port
    • add manufacturer, vendor (where we buy from if different from manufacturer)
    • planned cost
    • warranty duration
    • ...

    My current model for this is.

    This matches quite good with capabilities offered by supply chain systems. We have implemented it succesfully as a wrapper around SAP "Material Master".

    Regards


    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 10.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 10 days ago
    Edited by Henrik Kletke 10 days ago
    Hi Koen,

    I find it interesting that you use the resourceCandidate for the model of the router (exp. 2). I would use the resourceSpecification for that. In my opinion the resourceCandidate only exists to decouple the spec from the catalog.
    You also wrote "The same resourceCandidate can also used to document more complex stuff like...". Do you really mean resourceCandidate or do you mean resourceSpecification? I'm asking because you can't put any characteristics on the resourceCandidate (I guess you could use schema based extension here).

    ------------------------------
    Henrik Kletke
    Deutsche Telekom AG
    ------------------------------



  • 11.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 10 days ago
    Hi Henrik,

    I really mean ResourceCandidate.
    And I am sure that some other on this forum will disagree with me.
    A ResourceSpecifications defines the questions "what is a router, and which characteristics I want to store about this".
    A ResourceCandidate defines "what model can I order, and which characteristics are already defined by the model."
    These are two entirely different concepts and modeling both using only ResourceSpecification will lead to weird results.

    Obviously the current ResourceCandidate schema used in TMF634 at this moment is not sufficient to hande the concept. Therefore I provided the diagram of the extension that we currently use in my previous answer. I believe it should be submitted as a proposal for a next version of TMF634 but I never found the time for it.

    Regards

    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 12.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 10 days ago
    Hi Koen,

    I like the idea of splitting device model and type. It's really weird to design both in the same entity since you have to specify the same characteristics over and over for each instance.
    However I'm not sure about using the candidate for the device model. The main reason for this is that I would like to have a relation from the resource to the device model but there is no relation between resource (TMF639) and resourceCandidate. Do you have a solution for this?

    ------------------------------
    Henrik Kletke
    Deutsche Telekom AG
    ------------------------------



  • 13.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 10 days ago
    Hi Henrik,

    Indeed I extended TMF639 Resource as well with an additional  0..1 link to ResourceCandidateRef.
    Without this extension the solution is not complete.

    The same actually applies to services.
    A ServiceSpecification can define a BroadbandConnection.
    In most cases these BroadbandConnection are sold in well defined t-shirt sizes: XL, L, M, S.
    Each t-shirt size is modeled as a ServiceCandidate, with fixed values for upstream and downstream.

    TMF620 ProductOffering does already include references to ResourceCandidate & ServiceCandidate and does not require extensions.


    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 14.  RE: TMF639 Open API resource response to one of our physical inventory which has some specific attributes.

    TM Forum Member
    Posted 10 days ago
    Hi Koen,

    thanks for the clarification.
    I think your solution is definitly worth to consider.

    ------------------------------
    Henrik Kletke
    Deutsche Telekom AG
    ------------------------------