Open APIs

 View Only

  • 1.  TMF640 - serviceCharacteristic

    TM Forum Member
    Posted Mar 03, 2021 17:38

    Hi,

    Seeking some clarity on the usage of serviceCharacteristic in TMF640.

    We understand the serviceCharacteristic array holds all the characteristics of the service being activated.

    However, is there a placeholder in TMF640, for other attributes that are not exactly characteristics of the service, but information required in the process of activation??

    For example, we have 'manufacturerPurchaseOrderRef' which is required to claim licence key upon activation of router device. There are use cases as well, hoping you are getting the point.

    Apologies if this has already been asked, but I could not find such thread.

    Thanks
    Anu

    ​​

    ------------------------------
    Anu Aulakh
    Telstra Corporation
    ------------------------------


  • 2.  RE: TMF640 - serviceCharacteristic

    TM Forum Member
    Posted Mar 04, 2021 00:51
    Hi Anu
    Bear in mind that TMF640 is conceived as operating directly against the network, activating the service. Seemingly all the characteristics in the service request are part of the service.
    On the other hand, it really is up to you to decide how to model your services, and if you need a characteristic that is not ultimately "stored" in the service on the network, I think that's up to you.

    Note that if there is a process involved, perhaps it should be mediated by TMF641, Service Order, which could orchestrate the acquisition of the license key.
    Having said that, the order Open APIs (Product/Service/Resource) do not currently support capture and storage of characteristics independently of the P/S/R being ordered, so an extension would be required 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.
    ------------------------------

    Original Message


  • 3.  RE: TMF640 - serviceCharacteristic

    Posted Mar 04, 2021 02:31
    Hi Jonathan!

    But I think it would be a very good improvement for the APIs to distingues between "Order-Only-Characteristics" and "To-Be-Stored-Characteristics". I my experience there is always a mapping table which holds this information and I think it would be a good move to bring it into the model. I think this will help a lot of teams to adapt the APIs even faster.

    Kind Regards
    Daniel


    ------------------------------
    Daniel Lauxtermann
    Glasfaser NordWest GmbH & Co .KG
    ------------------------------

    Original Message


  • 4.  RE: TMF640 - serviceCharacteristic

    TM Forum Member
    Posted Mar 05, 2021 02:55
    Hi all!

    It's a good idea. We actually have it implemented in product orders, and it's useful.
    We call it: "for product inventory" ("To-Be-Stored-Characteristics") or "not for product inventory" ("Order-Only-Characteristics" )

    Regards,
    Damian

    ------------------------------
    Damian Golda
    Comarch S.A.
    ------------------------------

    Original Message


  • 5.  RE: TMF640 - serviceCharacteristic

    Posted Mar 05, 2021 03:04
    Hi Damian!

    That is a good example how to realize it. It was always a bad experience if something which is so important is hidden deep in the code. Nice to hear that in work in practice. 

    I would also recommend to use something like this in the catalogue APIs. I have seen catalogues and most of them don't have the information in an explicit form. So one one hand you try to expose a model through a catalogue create more transparency and end-to-end relationsship between Product Management, Engineering and IT and on the other hand you still hide these information. 

    Regards
    Daniel

    ------------------------------
    Daniel Lauxtermann
    Glasfaser NordWest GmbH & Co .KG
    ------------------------------

    Original Message


  • 6.  RE: TMF640 - serviceCharacteristic

    Posted Mar 05, 2021 07:56
    The interesting thing to me is to consider how models for products services and resources are produced stored and exchanged as configurations of BSS and OSS alongside the schema definition of an order. This is especially of interest for exchanging guidelines in B2B scenarios. 

    When it comes to ordering products, I have  in the past suggested certain extensions being modelled as part of the product rather than being added to the  of the order guideline. But often this would be resisted on grounds that the attribute was a feature of more than one product or that the information was not to be recorded as part of the provisioned service downstream.

    The alternative of some form of non product characteristic extension to an  order which is then not to be reflected in schema raises the question of how one documents and publishes those extensions.

    ------------------------------
    Derrick Evans
    ------------------------------

    Original Message


  • 7.  RE: TMF640 - serviceCharacteristic

    TM Forum Member
    Posted Mar 07, 2023 00:38
    Edited by Srinivasa Vellanki Mar 07, 2023 00:39

    Hi,

    Did we consider having these transactional characteristics as Order Characteristics modelled as Order Specifications in Catalog?

    ------------------------------
    Srinivasa Vellanki
    Jio Platforms Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of my employer or TM Forum.
    ------------------------------

    Original Message