Open APIs

 View Only

  • 1.  Major Difference between TMF 638 V4 Vs Gen5 V5 versions

    TM Forum Member
    Posted Nov 03, 2023 05:39

    Dear Team,

    Can someone explain about major differences between TMF 638 V4 vs Gen5 V5 versions? I can see new objects added like Intent, Under place sub address place etc.

    Kindly help with major differences and also if i can get conformance document w.r.t 638B for V5 version would be great to understand mandatory parameters or objects for V5.

    Also need understanding of use of Intent and expectation while passing it in new API version.

    Thanks!!!



    ------------------------------
    Mahesh Choudhari
    BT Group plc
    ------------------------------


  • 2.  RE: Major Difference between TMF 638 V4 Vs Gen5 V5 versions

    TM Forum Member
    Posted Nov 09, 2023 02:21

    Hi Masesh

    Here's a very short general summary of the changes between v4 and v5 for all APIs:

    • OAS (Swagger) 3: instead of Swagger 2
    • Related Party pattern has changed
    • Values for Characteristics and Characteristic Specs are strongly typed
    • Contact Medium is now strongly typed
    • RefOrValue is now a oneOf the Ref or the Value, instead of being an allOf

    Specifically for 638, I'm not qualified to explain the changes in detail. But take a look at the Intent API itself TMF921; my estimation is that the service inventory can store the "intent" that was used to instantiate the specific service.

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

    Original Message


  • 3.  RE: Major Difference between TMF 638 V4 Vs Gen5 V5 versions

    TM Forum Member
    Posted Nov 09, 2023 02:56

    As it happens, I was just looking into the v5 changes involving Intent.  I note that Common/Intent.schema.json now includes Characteristics.

    I arrived at that observation after finding an intent attributed added to Product/Product.schema.json, and realizing that Feature had previously not been included in Product I am thinking that the intention was to combine these two methods of expressing Intent.

    While I do see an intent attribute added to Service and Resource the existing feature and activationFeature attributes, respectively, remain. Is it planned to remove these in the future?  Am I correct in assuming we could use one intent attribute to handle both the declarative intent and the new ontology based intent?



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

    Original Message


  • 4.  RE: Major Difference between TMF 638 V4 Vs Gen5 V5 versions

    Posted Nov 10, 2023 01:33

    Interesting thoughts Vance.

    For the Product layer, I seem to remember Jonathan mentioning that he thought that Features were not necessary at the Product layer as each feature would most likely end up as a separate product with its own pricing.

    I have seen a few implementations where Features are merely being used to group characteristics (rather than using complex characteristics/objects).   Since the original plan  was that the use of Features was for expressing intent, and the new 'intent' attribute now exists, it would be really helpful to get some clarification on future plan for the use of Features.

    Thanks



    ------------------------------
    Dan d'Albuquerque
    Individual
    ------------------------------

    Original Message


  • 5.  RE: Major Difference between TMF 638 V4 Vs Gen5 V5 versions

    TM Forum Member
    Posted Nov 10, 2023 02:16
    Edited by Vance Shipley Nov 10, 2023 02:59

    Looking at it from a perspective of general patterns, Product, Service, and Resource all have Specifications which define Characteristics used to parameterize an instantiation. We may declare an intent when ordering or activating a Service, for example:

    {
         "@type": "Service",
         "feature": [
              {
                   "name": "QoS",
                   "featureCharacteristic": [
                        {
                              "name": "speed",
                              "value": "fast"
                        }
                   ]
              }
         ],
         ...
    }

    The intention is that a fast Service is configured and activated.  Once instantiated the actual speed value (e.g. in bps) may be found in a Characteristic of the Service in inventory.

    So why not intent based Product configuration?

    "featureCharacteristic": [
         {
              "name": "color type",
              "value": "neon"
         }
    ]

    The intention being to select a neon colour as opposed to a pastel or monochrome. Once instantiated the actual color (e.g. neon green) may be found in a Characteristic of the Product in inventory.

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

    Original Message