Open APIs

Expand all | Collapse all

TMF 640 task for reset operation

  • 1.  TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    Hi,

    In our organization, my team is implementing the SOM layer and, to configure services (CFS), we rely extensively on features which would translate during provisioning/activation into RFS attached to the CFS (through a rule based design module using the service catalog).
    We were requested recently to provide at CFS level the possibility to "reset" some features which means regenerate these from scratch with default values while keeping the CFS and remaining features unchanged (as well as non impacted RFS). These default values are not known by either the calling application or stored anywhere at our side so a classic patch is not possible.
    We thought to use tasks to allow this functionality and would like to have your opinion.
    The task would be at TMF640 level and its path would be something like .../service/{serviceId}/reset with as body a classic ServiceUpdate/ServiceCreate object containing whatever needs to be reset (as we would like to be generic).
    Basically, resetting one or more feature would mean to provide something like that as body:
    {
        "feature": [
                {
                    "id""id1"
                },
                {
                    "id""id4"
                }
        ]
    }

    What are your thoughts? Do you see any other way to achieve this?

    Best regards,


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


  • 2.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    Hi Fredrick,

    Before I try to answer this, I would like to understand how are you generating the provisioning/activation requests in case of change orders when certain characteristics are changed for a Service or a feature has been added or removed.

    Are you managing configuration versions of your CFSs and RFSs in Service Inventory and using the diff of the versions to generate the Activation request?


    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 3.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    Hi Kinshuk,

    change on a Service is managed through classic TMF640.PATCH or TMF641.POST coming from BSS or GUI (for manual repairs). When processing the patch, a complete redeisgn is performed on each CFS based on the patch body and thus RFSs are, as a result, generated/updated/kept unchanged.
    We do however keep versioning of our services but it is not used for patch operations (at the moment, it's only intended for rollbacks). As a new version is created for each TMF640.PATCH, we can have quite a lot of these for each CFS/RFS so it won't help to find back the default values because we don't keep the full history in our DB (cleanups are scheduled to keep the size of our TMF638 DB manageable and older versions are removed first)

    Best regards,

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



  • 4.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    Hi Fredric,

    Thanks for the details. I think you are already getting what my thought process is on this topic. One option is to create a default configuration version for your CFS/RFS and not delete them as part of the cleanup process. Whenever you want to reset the service, just restore the default version.


    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 5.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    Indeed, we thought about it but it's not really the solution we want as the default values from 1 year ago may not be the default values of today ;)

    Best regards,

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



  • 6.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    I agree! But when there is a change in default values, the default configuration can be changed. Do you have other options on the table as well to consider?

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------



  • 7.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    Default values are not stored explicitly in some central place but are generated during the design from various source (legacy backends) depending of the CFS to design so it can only be determined by the designing module.
    Basically the reset would trigger the removal of the considered features and a redesign of the service to regenerate these from scratch.

    Best regards,

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



  • 8.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    Edited by Abel Ruiz 20 days ago

    Hi,

    Why don't use the catalog configuration? I mean, as part of the service specification configuration in the catalog, you can set default values for its characteristics, or feature characteristics. You can also manage versions of these specifications, so if the default configuration changes, you just need to generate a new version of your specification with the new values. The SOM component responsible to execute the reset operation would only need to get the last version of the specification and apply the default values.

    Regards,

    Abel

    ------------------------------
    Abel Ruiz
    SATEC GROUP
    ------------------------------



  • 9.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 20 days ago
    Hi Abel,

    As explained earlier, our design module is fully based on the service catalog and a rule engine that tells him what to do to design a service.
    Some characteristic default values can come from the catalog directly but also from backends (legacy) that may have to be called (what backend to call is based on the ServiceSpecification itself and our rule engine and is, of course, different for each CFS to design) so everything cannot be  available in the catalog (which only allows to store static default values).

    Best regards,

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



  • 10.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 19 days ago
    Edited by Abel Ruiz 19 days ago

    Hi,

    In that case, if you can't store this configuration in the catalog, and you don't have a way to recover a valid previous configuration from the inventory, the only way I can think is to implement logic in SOM to recover the information that you need from the legacy systems.

    My point now is which is the right place for that? I guess that you have a SOM component, which has orchestration and decomposition capabilities and provides the TMF641. I guess that it is also able to make calls to the TMF640. If these suppositions are right:

    • You can get a TMF641 POST to launch a service order with the CFS and the action = reset.
    • The SOM will decompose the CFS received and will implement logic to call the legacy systems. With all this information, it will build the service (the RFS) with the default configuration.
    • Then, it may send a TMF640 PATCH operation with the service (totally configured with the default values that you want).
    • The component behind the TMF640 just needs to update the service with the configuration received.

    Well, this is just another option; perhaps more 'standard'. Hope it helps.

    Best regards,

    Abel



    ------------------------------
    Abel Ruiz
    SATEC GROUP
    ------------------------------



  • 11.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 19 days ago
    We have indeed a full SOM logic with, as entry point, TM641 and 640. TMF 641 delegating the handling of each CFS to 640.

    Because a PATCH is not possible at TMF640 in this case (no way to get the default config without actually designing it), the reset task is intended to trigger this re design of the CFS based on what was specified to be reset in the body of the task (in my specific case, a feature).

    Btw, action "reset" does not exist in TMF641 so either we extend it or use a similar reset task for whatever SOI are passed. That's not really in scope at the moment as this reset would actually be requested by the customer from the UI (running on the STB, web or any other channel) at CFS level...

    Thanks for your input,

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



  • 12.  RE: TMF 640 task for reset operation

    TM Forum Member
    Posted 11 days ago
    You have raised a very good point Fredric. I think we need to provide a recommended way in the TMF641 to trigger the Reset operation. For Suspend and Resume, there are multiple options as described in this thread. But for Reset, I don't think we can​ use any of these patterns for Reset of the service. Does it make sense to add a new Action code for 'Reset' of the service in TM641. I think the same concept would be applicable for Product and Resource APIs as well. What are your views on this @Ludovic Robert

    ------------------------------
    Kinshuk Kulshreshtha
    Oracle Corporation

    My views posted on this forum are personal, and do not reflect the position of my employer or TM Forum.
    ------------------------------