Processes behind Services - TMF701

5. RE: Processes behind Services - TMF701

Like

TM Forum Member

Carlos Portela

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

Original Message

6. RE: Processes behind Services - TMF701

Like

TM Forum Member

Ludovic Robert

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

Original Message

7. RE: Processes behind Services - TMF701

Like

TM Forum Member

Opher Yaron

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

Original Message

8. RE: Processes behind Services - TMF701

Like

TM Forum Member

Frederic Thise

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

Original Message

Original Message:
Sent: Sep 22, 2023 09:59
From: Opher Yaron
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 10, 2020 07:50
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 08, 2020 11:53
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 07, 2020 10:51
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 07, 2020 05:56
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Aug 26, 2020 10:01
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Aug 26, 2020 08:15
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

9. RE: Processes behind Services - TMF701

Like

TM Forum Member

Opher Yaron

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

Original Message

Original Message:
Sent: Sep 25, 2023 03:43
From: Frederic Thise
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 22, 2023 09:59
From: Opher Yaron
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 10, 2020 07:50
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 08, 2020 11:53
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 07, 2020 10:51
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 07, 2020 05:56
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Aug 26, 2020 10:01
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Aug 26, 2020 08:15
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

10. RE: Processes behind Services - TMF701

Like

TM Forum Member

Olivier Arnaud

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

Original Message

Original Message:
Sent: Sep 28, 2023 07:41
From: Opher Yaron
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 25, 2023 03:43
From: Frederic Thise
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 22, 2023 09:59
From: Opher Yaron
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 10, 2020 07:50
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 08, 2020 11:53
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 07, 2020 10:51
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Sep 07, 2020 05:56
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Aug 26, 2020 10:01
From: Ludovic Robert
Subject: Processes behind Services - TMF701

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

Original Message:
Sent: Aug 26, 2020 08:15
From: Carlos Portela
Subject: Processes behind Services - TMF701

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

Open APIs