TMF641 Modify Service Order Payload

5. RE: TMF641 Modify Service Order Payload

Like

Ludovic Robert

Posted Sep 11, 2020 04:53

Hello Anu,

Aligned with you.
If you want to modify existing service (created with a previous serviceOrder in completed state) you have - for me - to trigger a new serviceOrder referring exsiting service reference (id) in serviceOrder.serviceOrderItem.service.id. You will set serviceOrder.serviceOrderItem.action to modify to indicate you want to change service 'configuration'. Then in serviceOrder.serviceOrderItem.service.serviceCharacteristics you'll indicate the requested value for this modification.
Regarding you point about complex serviceCharacteristic you can leverage polymorphism pattern at characteristic level to describe complex caracteristic like array of embedded table for example.

Hope it helps

Ludovic

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

Original Message

Original Message:
Sent: Sep 10, 2020 19:57
From: Anu Aulakh
Subject: TMF641 Modify Service Order Payload

Hi @Ludovic Robert,

Agree that in-flight modifications of ServiceOrder can be achieved through TMF641 PATCH methods.
However, we are currently interested in the other story; ServiceOrder has reached a terminal state and client is sending TMF641 POST "Modify"....what are the best ways to represent add, modify, no-change and delete to the ServiceOrder.serviceOrderItem.service.serviceCharacteristics? Noting that serviceCharacteristics can be nested/complex objects, strings, arrays etc.

Thanks,
Anu

cc: @Rati Mehrotra, @Uma Lakshman

------------------------------
Anu Aulakh
Telstra Corporation
------------------------------

Original Message:
Sent: Apr 02, 2020 11:15
From: Ludovic Robert
Subject: TMF641 Modify Service Order Payload

Hello

I'm agreeing with Alexander about the fact that the answer is in capability of your SOM System.
We should note that we described in the TMF Open API a pattern leveraging JSON-Patch for PATCH operation.

Just an example to illustrate - following PATCH payload is a request to modify requested start date & description.

[  {"op":"replace",    "path": "requestedStartDate",    "value": "2018-01-16T09:37:40.508Z"  },  {"op":"replace",    "path" : "description",    "value" : "Service order new description updated v2"  }]

Of course this could be only accepted if PONR not yet reach but that another story...

hope it helps

Ludovic

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

Original Message:
Sent: Apr 02, 2020 04:53
From: Alexander Morozov
Subject: TMF641 Modify Service Order Payload

I feel like the TMF641 does not really prescribe this aspect. The decision to include only delta or a full snapshot is driven mostly by how capable your SOM application is (the one that receives and processes a TMF641 createOrder request). If the app is capable to process delta-request - opt-out to this option. Otherwise - you may have to include a full target snapshot (which comes with the need to retrieve service state from Softswitch).

Periodically we see SOM applications that are positioned as "stateless", which roughly means they don't know or cannot access service inventory at all. In this case, using "deltas" is typically off the table.

------------------------------
Alexander Morozov
Vlocity

6. RE: TMF641 Modify Service Order Payload

Like

Dave Whitfield

Posted Jan 25, 2022 15:28
Edited by Dave Whitfield Jan 25, 2022 15:43

hey @Anu Aulakh and @Ludovic Robert,

I was similarly aligned that when you pass a service order item with action = 'MODIFY' to complete service changes to an existing service (order to ADD said service could have been months/years ago). that you would include the characteristics which you wanted to change.

i.e.
order - 123
orderitem (action - MODIFY) --> service --> service characteristics [ name = speed, value = 500]

Key things i was pondering on this was: -

Does running a GET on the above service order return an order item with a collection of service characterisitcs that represent the only the ones defined by the order you placed (and not any characteristics that were already present on the service under change), My thoughts were Yes (i.e. Just speed = 500).
Assume at the point of the above order (action = MODIFY) being received (which may in our case take hours/days to complete) that the result of calling a GET against the order and a GET against the service (TMF 638 inventory) is going to return a different representation of the service i.e.
- TMF 641 GET serviceOrder --> only a single characteristic, speed = 500
- TMF 638 GET service --> many characteristics associated with the service but importantly speed = 100 (i.e. this hasnt had the change affected yet)
How do you deal with attributes that you want to change, i.e. if you want to modify a service to use a very similar service specification (i.e. in the scenario of a fibre access service where you dont wish for disconnection) how would you indicate as part of the order would this be in a characteristic? Or would the client be expected to set the serviceSpecification field of the service object sent to TMF641 with the new specification reference/id?

------------------------------
David Whitfield
TalkTalk Group
------------------------------

Original Message

Original Message:
Sent: Sep 11, 2020 04:52
From: Ludovic Robert
Subject: TMF641 Modify Service Order Payload

Hello Anu,

Aligned with you.
If you want to modify existing service (created with a previous serviceOrder in completed state) you have - for me - to trigger a new serviceOrder referring exsiting service reference (id) in serviceOrder.serviceOrderItem.service.id. You will set serviceOrder.serviceOrderItem.action to modify to indicate you want to change service 'configuration'. Then in serviceOrder.serviceOrderItem.service.serviceCharacteristics you'll indicate the requested value for this modification.
Regarding you point about complex serviceCharacteristic you can leverage polymorphism pattern at characteristic level to describe complex caracteristic like array of embedded table for example.

Hope it helps

Ludovic

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

Original Message:
Sent: Sep 10, 2020 19:57
From: Anu Aulakh
Subject: TMF641 Modify Service Order Payload

Hi @Ludovic Robert,

Agree that in-flight modifications of ServiceOrder can be achieved through TMF641 PATCH methods.
However, we are currently interested in the other story; ServiceOrder has reached a terminal state and client is sending TMF641 POST "Modify"....what are the best ways to represent add, modify, no-change and delete to the ServiceOrder.serviceOrderItem.service.serviceCharacteristics? Noting that serviceCharacteristics can be nested/complex objects, strings, arrays etc.

Thanks,
Anu

cc: @Rati Mehrotra, @Uma Lakshman

------------------------------
Anu Aulakh
Telstra Corporation

Original Message:
Sent: Apr 02, 2020 11:15
From: Ludovic Robert
Subject: TMF641 Modify Service Order Payload

Hello

I'm agreeing with Alexander about the fact that the answer is in capability of your SOM System.
We should note that we described in the TMF Open API a pattern leveraging JSON-Patch for PATCH operation.

Just an example to illustrate - following PATCH payload is a request to modify requested start date & description.

[  {"op":"replace",    "path": "requestedStartDate",    "value": "2018-01-16T09:37:40.508Z"  },  {"op":"replace",    "path" : "description",    "value" : "Service order new description updated v2"  }]

Of course this could be only accepted if PONR not yet reach but that another story...

hope it helps

Ludovic

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

Original Message:
Sent: Apr 02, 2020 04:53
From: Alexander Morozov
Subject: TMF641 Modify Service Order Payload

I feel like the TMF641 does not really prescribe this aspect. The decision to include only delta or a full snapshot is driven mostly by how capable your SOM application is (the one that receives and processes a TMF641 createOrder request). If the app is capable to process delta-request - opt-out to this option. Otherwise - you may have to include a full target snapshot (which comes with the need to retrieve service state from Softswitch).

Periodically we see SOM applications that are positioned as "stateless", which roughly means they don't know or cannot access service inventory at all. In this case, using "deltas" is typically off the table.

------------------------------
Alexander Morozov
Vlocity

7. RE: TMF641 Modify Service Order Payload

Like

Ludovic Robert

Posted Jan 26, 2022 02:24

Hello David

For me, yes for the first 2 bullet points. the service representation in the order item should not change accordingly to the inventory. So you can have a different representation looking in 641 vs 638 but service & order.item state help to understand that an operation will or is running on the service.

I'm not sure to completely understand the third bullet. you want to change the service specification of an existing service? for me it is a service migration and probably I will manage it with 2 items and a relationship between them. In this case you'll have probably a new service.id.
The model allow to manage it in one item (keeping the service.id, changing the Service Specification) but from a provisioning perspective it seems to me a bit complex & risky.

Hope it helps,
Ludovic

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

Original Message

Original Message:
Sent: Jan 25, 2022 15:27
From: David Whitfield
Subject: TMF641 Modify Service Order Payload

hey @Anu Aulakh and @Ludovic Robert,

I was similarly aligned that when you pass a service order item with action = 'MODIFY' to complete service changes to an existing service (order to ADD said service could have been months/years ago). that you would include the characteristics which you wanted to change.

i.e.
order - 123
orderitem (action - MODIFY) --> service --> service characteristics [ name = speed, value = 500]

Key things i was pondering on this was: -

Does running a GET on the above service order return an order item with a collection of service characterisitcs that represent the only the ones defined by the order you placed (and not any characteristics that were already present on the service under change), My thoughts were Yes (i.e. Just speed = 500).
Assume at the point of the above order (action = MODIFY) being received (which may in our case take hours/days to complete) that the result of calling a GET against the order and a GET against the service (TMF 638 inventory) is going to return a different representation of the service i.e.
- TMF 641 GET serviceOrder --> only a single characteristic, speed = 500
- TMF 638 GET service --> many characteristics associated with the service but importantly speed = 100 (i.e. this hasnt had the change affected yet)
How do you deal with attributes that you want to change, i.e. if you want to modify a service to use a very similar service specification (i.e. in the scenario of a fibre access service where you dont wish for disconnection) how would you indicate as part of the order would this be in a characteristic? Or would the client be expected to set the serviceSpecification field of the service object sent to TMF641 with the new specification reference/id?

------------------------------
David Whitfield
TalkTalk Group
------------------------------

Original Message:
Sent: Sep 11, 2020 04:52
From: Ludovic Robert
Subject: TMF641 Modify Service Order Payload

Hello Anu,

Aligned with you.
If you want to modify existing service (created with a previous serviceOrder in completed state) you have - for me - to trigger a new serviceOrder referring exsiting service reference (id) in serviceOrder.serviceOrderItem.service.id. You will set serviceOrder.serviceOrderItem.action to modify to indicate you want to change service 'configuration'. Then in serviceOrder.serviceOrderItem.service.serviceCharacteristics you'll indicate the requested value for this modification.
Regarding you point about complex serviceCharacteristic you can leverage polymorphism pattern at characteristic level to describe complex caracteristic like array of embedded table for example.

Hope it helps

Ludovic

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

Original Message:
Sent: Sep 10, 2020 19:57
From: Anu Aulakh
Subject: TMF641 Modify Service Order Payload

Hi @Ludovic Robert,

Agree that in-flight modifications of ServiceOrder can be achieved through TMF641 PATCH methods.
However, we are currently interested in the other story; ServiceOrder has reached a terminal state and client is sending TMF641 POST "Modify"....what are the best ways to represent add, modify, no-change and delete to the ServiceOrder.serviceOrderItem.service.serviceCharacteristics? Noting that serviceCharacteristics can be nested/complex objects, strings, arrays etc.

Thanks,
Anu

cc: @Rati Mehrotra, @Uma Lakshman

------------------------------
Anu Aulakh
Telstra Corporation

Original Message:
Sent: Apr 02, 2020 11:15
From: Ludovic Robert
Subject: TMF641 Modify Service Order Payload

Hello

I'm agreeing with Alexander about the fact that the answer is in capability of your SOM System.
We should note that we described in the TMF Open API a pattern leveraging JSON-Patch for PATCH operation.

Just an example to illustrate - following PATCH payload is a request to modify requested start date & description.

[  {"op":"replace",    "path": "requestedStartDate",    "value": "2018-01-16T09:37:40.508Z"  },  {"op":"replace",    "path" : "description",    "value" : "Service order new description updated v2"  }]

Of course this could be only accepted if PONR not yet reach but that another story...

hope it helps

Ludovic

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

Original Message:
Sent: Apr 02, 2020 04:53
From: Alexander Morozov
Subject: TMF641 Modify Service Order Payload

I feel like the TMF641 does not really prescribe this aspect. The decision to include only delta or a full snapshot is driven mostly by how capable your SOM application is (the one that receives and processes a TMF641 createOrder request). If the app is capable to process delta-request - opt-out to this option. Otherwise - you may have to include a full target snapshot (which comes with the need to retrieve service state from Softswitch).

Periodically we see SOM applications that are positioned as "stateless", which roughly means they don't know or cannot access service inventory at all. In this case, using "deltas" is typically off the table.

------------------------------
Alexander Morozov
Vlocity

8. RE: TMF641 Modify Service Order Payload

Like

Anu Aulakh

Posted Jan 26, 2022 06:04

Hi @Dave Whitfield,

My understanding of TMF641 and TMF638 is also aligned with your first two bullet points. Regarding the third bullet, the scenario is not clear to me. Is it talking about a major version upgarde of service specification to an existing service instance?

Regards,
Anu

------------------------------
Anu Aulakh
Telstra Corporation
------------------------------

Original Message

Original Message:
Sent: Jan 25, 2022 15:27
From: David Whitfield
Subject: TMF641 Modify Service Order Payload

hey @Anu Aulakh and @Ludovic Robert,

I was similarly aligned that when you pass a service order item with action = 'MODIFY' to complete service changes to an existing service (order to ADD said service could have been months/years ago). that you would include the characteristics which you wanted to change.

i.e.
order - 123
orderitem (action - MODIFY) --> service --> service characteristics [ name = speed, value = 500]

Key things i was pondering on this was: -

Does running a GET on the above service order return an order item with a collection of service characterisitcs that represent the only the ones defined by the order you placed (and not any characteristics that were already present on the service under change), My thoughts were Yes (i.e. Just speed = 500).
Assume at the point of the above order (action = MODIFY) being received (which may in our case take hours/days to complete) that the result of calling a GET against the order and a GET against the service (TMF 638 inventory) is going to return a different representation of the service i.e.
- TMF 641 GET serviceOrder --> only a single characteristic, speed = 500
- TMF 638 GET service --> many characteristics associated with the service but importantly speed = 100 (i.e. this hasnt had the change affected yet)
How do you deal with attributes that you want to change, i.e. if you want to modify a service to use a very similar service specification (i.e. in the scenario of a fibre access service where you dont wish for disconnection) how would you indicate as part of the order would this be in a characteristic? Or would the client be expected to set the serviceSpecification field of the service object sent to TMF641 with the new specification reference/id?

------------------------------
David Whitfield
TalkTalk Group
------------------------------

Original Message:
Sent: Sep 11, 2020 04:52
From: Ludovic Robert
Subject: TMF641 Modify Service Order Payload

Hello Anu,

Aligned with you.
If you want to modify existing service (created with a previous serviceOrder in completed state) you have - for me - to trigger a new serviceOrder referring exsiting service reference (id) in serviceOrder.serviceOrderItem.service.id. You will set serviceOrder.serviceOrderItem.action to modify to indicate you want to change service 'configuration'. Then in serviceOrder.serviceOrderItem.service.serviceCharacteristics you'll indicate the requested value for this modification.
Regarding you point about complex serviceCharacteristic you can leverage polymorphism pattern at characteristic level to describe complex caracteristic like array of embedded table for example.

Hope it helps

Ludovic

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

Original Message:
Sent: Sep 10, 2020 19:57
From: Anu Aulakh
Subject: TMF641 Modify Service Order Payload

Hi @Ludovic Robert,

Agree that in-flight modifications of ServiceOrder can be achieved through TMF641 PATCH methods.
However, we are currently interested in the other story; ServiceOrder has reached a terminal state and client is sending TMF641 POST "Modify"....what are the best ways to represent add, modify, no-change and delete to the ServiceOrder.serviceOrderItem.service.serviceCharacteristics? Noting that serviceCharacteristics can be nested/complex objects, strings, arrays etc.

Thanks,
Anu

cc: @Rati Mehrotra, @Uma Lakshman

------------------------------
Anu Aulakh
Telstra Corporation

Original Message:
Sent: Apr 02, 2020 11:15
From: Ludovic Robert
Subject: TMF641 Modify Service Order Payload

Hello

I'm agreeing with Alexander about the fact that the answer is in capability of your SOM System.
We should note that we described in the TMF Open API a pattern leveraging JSON-Patch for PATCH operation.

Just an example to illustrate - following PATCH payload is a request to modify requested start date & description.

[  {"op":"replace",    "path": "requestedStartDate",    "value": "2018-01-16T09:37:40.508Z"  },  {"op":"replace",    "path" : "description",    "value" : "Service order new description updated v2"  }]

Of course this could be only accepted if PONR not yet reach but that another story...

hope it helps

Ludovic

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

Original Message:
Sent: Apr 02, 2020 04:53
From: Alexander Morozov
Subject: TMF641 Modify Service Order Payload

I feel like the TMF641 does not really prescribe this aspect. The decision to include only delta or a full snapshot is driven mostly by how capable your SOM application is (the one that receives and processes a TMF641 createOrder request). If the app is capable to process delta-request - opt-out to this option. Otherwise - you may have to include a full target snapshot (which comes with the need to retrieve service state from Softswitch).

Periodically we see SOM applications that are positioned as "stateless", which roughly means they don't know or cannot access service inventory at all. In this case, using "deltas" is typically off the table.

------------------------------
Alexander Morozov
Vlocity

Open APIs