Open APIs

Hello,

I am analyzing some use-cases for the TMF640 and I am struggling with a specific scenario.

Imagine that I've activated a service (RFS) via TMF640 and, due to the service POST action in the IT application, some resources were consequently instantiated in the IT application (based on the model spec, etc.).

Now, I would like to activate a child service (RFS) that comes in the picture later in the process. This child service should depend & consume characteristics from the previously created service (or its consequent created resources).

From my understanding, the right way of working would be to have two different calls to this IT application:

1. Create (POST) the child service with supportingResource referring to the previously created resource in the parent.
2. Update (PATCH/PUT) the parent service with the supportingService ID from the child

My doubt is if we could make this link or relation without the need to execute the 2nd call.
Or better, is there any better recommendation to handle this?

I would prefer to have this child service POST call in a single shot and to only announce the relation with the parent service and avoid referencing the resources but I am not sure if this is valid.

I hope I made myself clear.. 
Thanks for the help.


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

Hi Carlos
TMF640 is for activating services, not for maintaining the IT service inventory. So the question you need to consider is - does the main activated service in the network need to "know" about the child service? If yes, then I don't see an alternative, you would indeed need to patch the activated service to inform the network. Unless you can activate the child service first and then activate the parent.
I think that if you could provide some concrete examples this would assist experts (such as @Ludovic Robert, @Vance Shipley) to give an ​​informed opinion.

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:
Sent: Apr 29, 2020 09:24
From: Carlos Portela
Subject: TMF640 Activation of Parent and Child

Hello,

I am analyzing some use-cases for the TMF640 and I am struggling with a specific scenario.

Imagine that I've activated a service (RFS) via TMF640 and, due to the service POST action in the IT application, some resources were consequently instantiated in the IT application (based on the model spec, etc.).

Now, I would like to activate a child service (RFS) that comes in the picture later in the process. This child service should depend & consume characteristics from the previously created service (or its consequent created resources).

From my understanding, the right way of working would be to have two different calls to this IT application:

1. Create (POST) the child service with supportingResource referring to the previously created resource in the parent.
2. Update (PATCH/PUT) the parent service with the supportingService ID from the child

My doubt is if we could make this link or relation without the need to execute the 2nd call.
Or better, is there any better recommendation to handle this?

I would prefer to have this child service POST call in a single shot and to only announce the relation with the parent service and avoid referencing the resources but I am not sure if this is valid.

I hope I made myself clear..
Thanks for the help.


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

Hi Jonathan, 

I had a look on this thread and I think that, for my needs, the supportingService concept would be misused.

The idea would be, for example, that we have a service that defines the basic configuration of a CPE device that is taken for activation. As a supportingResource, we would have the CPE device itself. Later in the process, I would like to order and activate a service to configure a specific underlay L3 access in the device. For this underlay connectivity service, I think there should be a serviceRelationship "reliesOn" with the service that sets the basic configuration of the CPE. Additionally, this underlay service should have, consequently, as supporting resource, the physical and logical interfaces required from the CPE. The services relationships would be managed by an orchestrator before being taken for activation.
When I raised this thread, I was considering the underlay L3 access as a child service (supportingService) of the service for basic configuration but, now, I think it won't work that way.

Did the example help you understanding what I am trying to achieve? 

Thanks for your help!

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

Original Message:
Sent: May 03, 2020 05:45
From: Jonathan Goldberg
Subject: TMF640 Activation of Parent and Child

Hi Carlos
TMF640 is for activating services, not for maintaining the IT service inventory. So the question you need to consider is - does the main activated service in the network need to "know" about the child service? If yes, then I don't see an alternative, you would indeed need to patch the activated service to inform the network. Unless you can activate the child service first and then activate the parent.
I think that if you could provide some concrete examples this would assist experts (such as @Ludovic Robert, @Vance Shipley) to give an ​​informed opinion.

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:
Sent: Apr 29, 2020 09:24
From: Carlos Portela
Subject: TMF640 Activation of Parent and Child

Hello,

I am analyzing some use-cases for the TMF640 and I am struggling with a specific scenario.

Imagine that I've activated a service (RFS) via TMF640 and, due to the service POST action in the IT application, some resources were consequently instantiated in the IT application (based on the model spec, etc.).

Now, I would like to activate a child service (RFS) that comes in the picture later in the process. This child service should depend & consume characteristics from the previously created service (or its consequent created resources).

From my understanding, the right way of working would be to have two different calls to this IT application:

1. Create (POST) the child service with supportingResource referring to the previously created resource in the parent.
2. Update (PATCH/PUT) the parent service with the supportingService ID from the child

My doubt is if we could make this link or relation without the need to execute the 2nd call.
Or better, is there any better recommendation to handle this?

I would prefer to have this child service POST call in a single shot and to only announce the relation with the parent service and avoid referencing the resources but I am not sure if this is valid.

I hope I made myself clear..
Thanks for the help.


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

Your Service Orchestrator (SO) exporting TMF640 API may support composite Services (isBundle=true). It is then the job of the SO to perform all the API calls before returning the result.

------------------------------
Vance Shipley
SigScale
------------------------------

Original Message:
Sent: Apr 29, 2020 09:24
From: Carlos Portela
Subject: TMF640 Activation of Parent and Child

Hello,

I am analyzing some use-cases for the TMF640 and I am struggling with a specific scenario.

Imagine that I've activated a service (RFS) via TMF640 and, due to the service POST action in the IT application, some resources were consequently instantiated in the IT application (based on the model spec, etc.).

Now, I would like to activate a child service (RFS) that comes in the picture later in the process. This child service should depend & consume characteristics from the previously created service (or its consequent created resources).

From my understanding, the right way of working would be to have two different calls to this IT application:

1. Create (POST) the child service with supportingResource referring to the previously created resource in the parent.
2. Update (PATCH/PUT) the parent service with the supportingService ID from the child

My doubt is if we could make this link or relation without the need to execute the 2nd call.
Or better, is there any better recommendation to handle this?

I would prefer to have this child service POST call in a single shot and to only announce the relation with the parent service and avoid referencing the resources but I am not sure if this is valid.

I hope I made myself clear..
Thanks for the help.


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