Open APIs

 View Only
  • 1.  v5 Characteristic required Attributes

    TM Forum Member
    Posted 19 days ago
    Edited by Jan Lemmermann 19 days ago

    Hi Community,

    We're starting to take a first look into the v5 TMF OpenAPIs and I was very happy to see the use of specific Characteristic types like StringCharacteristic and avoiding the use of "any".
    When digging into the TMF641 v5 I noticed that for any given Characteristic only the attribute "value" is required and not "name" + "value".
    Is this a desired change or has something been overlooked here? I think that a characteristic without a name is not very useful.
    Would be interested if anyone has any insights on this who may have worked on the v5 OpenAPIs.

    Regards,

    Jan

    Update 2023-01-09 1:30pm: In the post I had originally mentioned the TMF641 v4, I meant of course the TMF641 v5

    ------------------------------
    Jan Lemmermann
    OSS Lead Architect
    EWE TEL GmbH
    ------------------------------


  • 2.  RE: v5 Characteristic required Attributes

    TM Forum Member
    Posted 19 days ago
    Could be we overlooked this, Jan. Possibly because value moved into the concrete subclasses.
    I plan to take this up with Open API team colleagues.
    Please note that the v5 APIs are published ​as beta, changes can still be expected.

    ------------------------------
    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: v5 Characteristic required Attributes

    TM Forum Member
    Posted 17 days ago
    Hi Jan
    We actually discussed the issue that I opened, https://projects.tmforum.org/jira/browse/AP-4230, (visible only to Open API project members.
    Team members were of the opinion that we cannot say for every use case that a value is needed. Example was given of a shopping cart for a mobile phone, where you could have characteristic such as IMEI, which would not be populated until later on e.g. by scanning barcode in fulfillment.

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



  • 4.  RE: v5 Characteristic required Attributes

    TM Forum Member
    Posted 17 days ago

    @Jonathan Goldberg very interesting but my finding is a different one.

    With v4 Characteristic.value and Characteristic.name are both required. With v5 only Characteristic.value is required.

    You now describe a different issue which is also worth discussing but that is one another page if you ask me.

    I'm currently busy but I'll post more details later. I've access to the Jira issue so if desired I can also address this directly within the ticket.

    Cheers,

    Jan



    ------------------------------
    Jan Lemmermann
    OSS Lead Architect
    EWE TEL GmbH
    ------------------------------



  • 5.  RE: v5 Characteristic required Attributes

    TM Forum Member
    Posted 16 days ago

    Finally I've some time for some insights.

    So as I mentioned with TMF641v4 a valid Characteristic required "name" and "value" to exist within the payload. Example (reduced):

    {
        "serviceOrderItem": [
            {
                "id": "1",
                "action": "add",
                "service": {
                    "serviceCharacteristic": [
                        {
                            "name": "nameIsRequired",
                            "value": "aCharacteristicValue"
                        }
                    ]
                }
            }
        ]
    }


    With TMF641v5 it would look like this:

    {
        "serviceOrderItem": [
            {
                "id": "1",
                "action": "add",
                "service": {
                    "serviceCharacteristic": [
                        {
                            "value": "aCharacteristicValue_but_for_which_characteristic?",
                            "@type": "StringCharacteristic"
                        }
                    ],
                    "@type": "Service"
                },
                "@type": "ServiceOrderItem"
            }
        ],
        "@type": "ServiceOrder"
    }


    For the the example with a Shopping Cart and characteristic values (e.g. IMEI) which get populated later thru the fulfillment process: Couldn't this be solved by having the product below the CardItem NOT having this IMEI charactestitic, and if it is present, adding it to the list by PATCHing the ShoppingCart.CardItem.Preoduct.productCharacteristic array?




    ------------------------------
    Jan Lemmermann
    OSS Lead Architect
    EWE TEL GmbH
    ------------------------------



  • 6.  RE: v5 Characteristic required Attributes

    TM Forum Member
    Posted 15 days ago
    Hi,

    Regarding value not mandatory in V5, I have the same reasoning: if a characteristic has not (yet) a value then it is not ready to be added to the list of characteristics of a Service/Resource/... After all, listing the possible characteristics of an Entity is the role of the catalogs, not the inventories...

    I also think that name+value should be kept mandatory...

    Best regards,

    ------------------------------
    Frederic Thise
    Proximus SA
    ------------------------------



  • 7.  RE: v5 Characteristic required Attributes

    TM Forum Member
    Posted 13 days ago
    Thanks all for your comments - I still feel that a standard should be permissive where possible, so as to allow various different business behaviors.
    You are welcome to join the regular Open API governance call to make your case, at 3pm CET Wednesdays (open only to members of the TMF Open API collaborative project)

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