Open APIs

Expand all | Collapse all

Processes behind Services - TMF701

  • 1.  Processes behind Services - TMF701

    TM Forum Member
    Posted Aug 26, 2020 08:15
    Hello,

    As part of our latest OSS-related works to support TMF OpenAPI's, we are now looking to extend the Service management (ODA Production) to also support some processes and tasks behind it. This internal need comes up as we believe that each service will have behind some manual and automated activities that need to be orchestrated.
    For example, on the provisioning of an Internet service, there are automated tasks to design and activate some network resources but also manual tasks to plan construction works, set appointments with customer or even contact a 3rd party installer for a CPE.

    I've taken a look on TMF701 and I believe it match our needs.
    I had also a look on this link I am fully aligned that a Process/Task flow catalog should also be exist. I would see TMF701 as a Process&Task Flow Inventory and another TMF### for Process&Task Flow Catalog and both could be applied at any layers (Party Management, Core Commerce Management and Production)..

    Looking on the found documentation, I come up with some questions:
    1) Via TMF701, how can we relate a Process with a specific Service? Can we use the RelatedEntity to link the processes to a specific service (CFS)?
    2) From some use-cases I saw from TMForum (in the link above and also from TAW2020 - by Sylvie and Ludovic), I noticed that you are mainly focusing your TMF701 integration at Core Commerce Management. At our side, we see our first need for TMF701 at Production layer (behind each CFS). How do you see this integration as part of ODA design? Is it aligned with the ODA scope?

    Thanks

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------


  • 2.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Aug 26, 2020 10:01
    Hello Carlos

    Good to see more request for ProcessFlow specification...we'll have to begin the work on this one ;)

    Regarding your questions:
    1/ Yes this is the idea - the relatedEntity is to make the link with the business entitiesmanaged in the process flow. You have it also at task level. You have to provide a role to explicitly indicate that for example this is the "delivered service".
    2/ For me you can use 701 in Core Commerce Management but also in Party Mangement & Production Management. It is aligned with ODA. We have built internally a map with ODA component with corresponding APIs and we put 701 in all three blocs.

    Hope it helps





    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 3.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Sep 07, 2020 05:57
    Edited by Carlos Portela Sep 07, 2020 05:59
    Hi Ludovic,

    Thanks a lot for your reply, it is indeed helping us to apply it.

    Meanwhile, new questions popped up.. ;)
    3) At the moment, there is no link from a processFlow to another processFlow in the API. Could it make sense to add this? I was thinking on how could a process trigger another one (probably based on a catalog) and then have this link maintained in the process inventory via TMF701 (same as it is done between tasks).
    4) Regarding the lifecycle of both, Process and Task, I think it could be improved.
    Couldn't we have a process still to be executed where we define it as (for example) "planned" after the current one? (depends a bit on question 3...)
    For the tasks, I think "new" might be confusing and could be replaced by "planned" or "pending" before jumping to "active" and then "complete".


    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------



  • 4.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Sep 07, 2020 10:52
    Hi Carlos

    3) Make sense for me and also agreed with you that we should also defined this ProcessFlow relationship in the catalog. Where I'm a bit more cautious is the level of the link... is is really a processFlow to processFlow or a processFlow.taskFlow to a processFlow ? for me, this is task #4 from ProcessFlow #789-544 that will trigger a processFlow creation to deleguate something no?
    Perhaps we could leverage the relationship pattern and introduce a relationshipeType attribute that will provide a semantic on the link between a [processFlow or TaskFlow... depending on previous point question]  to another ProcessFlow
    4) I'm not sure we have to manage a planned  state for a processFlow - Don't you think that once a POST ProcessFlow is triggered the processFlow is a active even if first task is to wait for 10 days?
    We can discuss 'new' sure... pending is not recommended because we use if for some other API when we are waiting for additionnal information.

    Thank you

    Ludovic
    ​​

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------



  • 5.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Sep 08, 2020 11:53
    Edited by Carlos Portela Sep 08, 2020 11:55
    Hi Ludovic,

    3) I think you are right, the link to other processes makes more sense to be done at Task level. In that case, we would leverage the "TaskFlowRelationship" (would this object be renamed also?) and link it to "TaskFlowRefOrProcessFlowRef" instead of "TaskFlowRef".
    4) Related with the conclusion in point 3, I think there's no concept of "planned" anymore at ProcessFlow. As soon as a task becomes active and it triggers a Process, this process is directly instantiated as active. Regarding the state for a task before going active, pending might be not the best choice as it is indeed used in other context for the other API's. Additionally to the suggestion of "planned", "foreseen" could also be an option.

    ------------------------------
    Carlos Portela
    Proximus SA
    ------------------------------



  • 6.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Sep 10, 2020 07:51
    Hi Carlos,

    Regarding point 3) we should assess it from a model perspective. I'm a bit reluctant to have one 'fits-all' attribute and probably 2 distinct attributes : we keep TaskFlowRelationship and we add a ProcessFlowRelationship (or relatedProcessFlow). We're probably aligned on the global design now we have to align it with API patterns ;)

    Thanks

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    My answer are my own & don't represent necessarily my company or the TMF
    ------------------------------