Open APIs

 View Only
  • 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
    ------------------------------



  • 7.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Sep 22, 2023 09:59
    Edited by Opher Yaron Sep 22, 2023 10:00

    Hello,

    I am coming back to this discussion from 3 years ago because I am most interested in the agreement that was reached, and in particular its inclusion in the coming production release of TMF701.

    To recap, the agreement was to introduce a ProcessFlowRelationship (or relatedProcessFlow) resource (perhaps with relationshipType attribute to provide semantics) in the taskFlow resource. The use-case is a process with tasks, where a task of this process needs to trigger another process, e.g. for delegating it to someone else.

    Is this indeed expected to be included in Version 5 of TMF701?

    Thank you,



    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------



  • 8.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Sep 25, 2023 03:44

    Hi,

    I second that ;) We have extended our TMF701 API under the assumption that it would make it to V5.

    Basically, we have added a processflowRelationship property under TaskFlow:

        processFlowRelationship:
            type: array
            items:
              $ref: '#/definitions/ProcessFlowRelationship'
            description: A list of processFlows related to this taskFlow

    ProcessFlowRelationship being defined as:

    ProcessFlowRelationship:
        type: object
        description: Describes relationship between a taskFlow and processFlows
        required:
          - relationshipType
          - processFlow
        properties:
          relationshipType:
            type: string
            description: 'The type of taskFlow relationship (requires, triggers, etc.)'
          processFlow:
            $ref: '#/definitions/ProcessFlowRefOrValue'
            description: The processFlow being referred to
          '@baseType':
            type: string
            description: 'When sub-classing, this defines the super-class'
          '@schemaLocation':
            type: string
            format: uri
            description: >-
              A URI to a JSON-Schema file that defines additional attributes and
              relationships
          '@type':
            type: string
            description: 'When sub-classing, this defines the sub-class entity name'

    In the yaml, we also replaced the "Ref" links to TaskFlow/ProcesFlow by their "RefOrValue" version (ProcessFlowRefOrValue in the definition above) which  allows the GET operations to return the full picture. This is extremely useful when you have a tree of ProcessFlow/TaskFlow (currently, we reach a depth of 4 in our most complex flows)...

    Best regards,



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



  • 9.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Sep 28, 2023 07:41

    Bump.

    Can someone from the team that works on TMF701 (maybe @olivier arnaud) please comment on the status of introducing ProcessFlowRelationship (or relatedProcessFlow) in taskFlow?

    @Ludovic Robert - I know that you are not leading the work on this API anymore, but maybe you have insight?

    Thank you and best regards,



    ------------------------------
    Opher Yaron
    Proximus SA
    ------------------------------



  • 10.  RE: Processes behind Services - TMF701

    TM Forum Member
    Posted Oct 17, 2023 07:51

    Hi

    @Opher Yaron @Frederic Thise @Carlos Portela

    I just created the JIRA. Thanks for sharing the extension code.



    ------------------------------
    Olivier Arnaud
    Orange
    ------------------------------