Open APIs

Hi all,

I have a few doubts on implementing the state lifecycle for both order and service instances.

1) I see an example on a POST example from TMF641 Specs (18.5.1) with a defined service state (as Active) on its payload(see in the code block below). I would like to know how do you see a need of this field on a order creation, under an order item as ADD. Even in the other use-cases (excluding GET), would the service state be something needed or could it be seen as a not applicable attribute? (I see that you assign it as non-mandatory in the detailed rules of the POST but wouldn't it make more sense to exclude it?)

	"externalId": "OrangeBSS747",
	"priority": "1",
	"description": "Service order description",
	"category": "TMF resource illustration",
	"state": "acknowledged",
	(...)
	"@type": "ServiceOrder",
	}],
	"orderItem": [{
		"id": "1",
		"action": "add",
		"state": "acknowledged",
		"service": {
			"@type": "vCPE",
			"@schemaLocation": "http//my.schemas/vCpe.schema.json",
			"state": "active",
			"serviceType": "CFS",
			"serviceCharacteristic": [{
	(...)​

Regarding the state lifecycle for both orders and services, I am trying to understand how should we foresee the cascade update of these states on the SOM layer. And that's why the following two questions come up.

2) On a Service state lifecycle, do you agree that we can only consider a parent service as active when, at least, all the child (supportingServices) services are also active? Or, would it be a valid use-case that the parent service is active when there's a supportingService in Designed state?

3) The same doubt pops-up on an Order Item state lifecycle. As soon as a orderItem with action ADD has it's corresponding service as Active, we can automatically define the orderItem state as Completed. Is this the right way to see this lifecycle cascade update? 

Thanks in advance for the help!

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

Hello Carlos

For you point 1 you should consider than you can request a new service in any state via service order. Nothing prevent to request a 'reserved' service creation.
I will not comment point 2 because I do not have enough feedback.
For 3) yes there are cascade update between but could be tricky .... suppose you ask for an existing a service state change from active to inactive ...
sunny day: order item delivery succeed:  service is inactive, service order item is completed,
rainy day: order item delivery fails: service is active, service order item is failed

Hope it helps
Ludovic

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

Original Message:
Sent: Jun 01, 2020 08:24
From: Carlos Portela
Subject: TMF641/640 Order and Service State

Hi all,

I have a few doubts on implementing the state lifecycle for both order and service instances.

1) I see an example on a POST example from TMF641 Specs (18.5.1) with a defined service state (as Active) on its payload(see in the code block below). I would like to know how do you see a need of this field on a order creation, under an order item as ADD. Even in the other use-cases (excluding GET), would the service state be something needed or could it be seen as a not applicable attribute? (I see that you assign it as non-mandatory in the detailed rules of the POST but wouldn't it make more sense to exclude it?)

	"externalId": "OrangeBSS747",	"priority": "1",	"description": "Service order description",	"category": "TMF resource illustration",	"state": "acknowledged",	(...)	"@type": "ServiceOrder",	}],	"orderItem": [{		"id": "1",		"action": "add",		"state": "acknowledged",		"service": {			"@type": "vCPE",			"@schemaLocation": "http//my.schemas/vCpe.schema.json",			"state": "active",			"serviceType": "CFS",			"serviceCharacteristic": [{	(...)​

Regarding the state lifecycle for both orders and services, I am trying to understand how should we foresee the cascade update of these states on the SOM layer. And that's why the following two questions come up.

2) On a Service state lifecycle, do you agree that we can only consider a parent service as active when, at least, all the child (supportingServices) services are also active? Or, would it be a valid use-case that the parent service is active when there's a supportingService in Designed state?

3) The same doubt pops-up on an Order Item state lifecycle. As soon as a orderItem with action ADD has it's corresponding service as Active, we can automatically define the orderItem state as Completed. Is this the right way to see this lifecycle cascade update?

Thanks in advance for the help!

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