Open APIs

Hi there,

 Need your assistance in supporting cancellation of an inflight patch which is applied on an inflight 641 ServiceOrder Creation. 

High level sequence as below.

Sequence of Event : 

1. Consumer Request to create serviceOrder
2. Service Provider Initiates ServiceOrder creation
3. Service Provider responds with id and href in HTTP Response 202 and move the order state to inProgress
4. Consumer Updates Service Characteristics of serviceOrder which is inProgress
5. Service Provider acknowledges the update request
6. Service Provider responds with with id and href in HTTP Response 202
7. Consumer wants to cancel PATCH request (step 4) )which is not completed or not reached PONR 

The flow is detailed in the attachment as well .    

Looking forward to get some guidance on supporting the 7^th  step in the sequence , which is a cancellation request on an inflight PATCH. The diagram and steps shows only one PATCH on an inflight serviceOrder. There are usecases where there can be multiple patches on an inflight order. We are looking for a generic solution which can be selectively applied on a specific patch.

 

Regards,

Uma Lakshman

Telstra Corporation

------------------------------
Uma Lakshman
Telstra Corporation
------------------------------

Hi Uma

I don't think that we have reached this level of granularity in the Open API semantics for orders (such as service order).
At least according to my understanding of current semantics, a POST and a PATCH on a service order are synchronous, in other words the result is immediate (201 for POST and 200 for PATCH).
And PATCH can be invoked any number of times (until the PoNR).
To achieve your use case would require keeping multiple versions (perhaps) of the service order, and canceling a patch request would somehow cause reversion to the previous version, assuming that this was still possible (depending on what work was already done).
Deferring to @Ludovic Robert, the lead and SME for TMF641.

​

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

Hello Uma, Jonathan

I do not have a lot to add to Jonathan answer.

We have also in the TMF Open API the Monitor pattern that allow managing asynchronous response (In the response of POST or PATCH you get a 202 and a monitor id). This is illustrated in TMF640.
But if this mechanism allows you manage long running task triggered from a POST or PATCH it will not able to manage cancellation request of an in progress request.

Thanks,
Ludovic

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

Original Message:
Sent: Jul 07, 2020 10:28
From: Jonathan Goldberg
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Hi Uma

I don't think that we have reached this level of granularity in the Open API semantics for orders (such as service order).
At least according to my understanding of current semantics, a POST and a PATCH on a service order are synchronous, in other words the result is immediate (201 for POST and 200 for PATCH).
And PATCH can be invoked any number of times (until the PoNR).
To achieve your use case would require keeping multiple versions (perhaps) of the service order, and canceling a patch request would somehow cause reversion to the previous version, assuming that this was still possible (depending on what work was already done).
Deferring to @Ludovic Robert, the lead and SME for TMF641.

​

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

Thanks Jonathan  and Ludovic .

We agree that there is no existing pattern for resolving this usecase.

@Jonathan Goldberg,
Based on your comment below,

"To achieve your use case would require keeping multiple versions (perhaps) of the service order, and canceling a patch request would somehow cause reversion to the previous version, assuming that this was still possible (depending on what work was already done)."

Is there any chance that the upcoming release will have a support for version in service order level ?

Uma Lakshman,
Telstra Corporation
​

------------------------------
uma lakshman
Telstra Corporation
------------------------------

Original Message:
Sent: Jul 07, 2020 10:36
From: Ludovic Robert
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Hello Uma, Jonathan

I do not have a lot to add to Jonathan answer.

We have also in the TMF Open API the Monitor pattern that allow managing asynchronous response (In the response of POST or PATCH you get a 202 and a monitor id). This is illustrated in TMF640.
But if this mechanism allows you manage long running task triggered from a POST or PATCH it will not able to manage cancellation request of an in progress request.

Thanks,
Ludovic

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


Original Message:
Sent: Jul 07, 2020 10:28
From: Jonathan Goldberg
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Hi Uma

I don't think that we have reached this level of granularity in the Open API semantics for orders (such as service order).
At least according to my understanding of current semantics, a POST and a PATCH on a service order are synchronous, in other words the result is immediate (201 for POST and 200 for PATCH).
And PATCH can be invoked any number of times (until the PoNR).
To achieve your use case would require keeping multiple versions (perhaps) of the service order, and canceling a patch request would somehow cause reversion to the previous version, assuming that this was still possible (depending on what work was already done).
Deferring to @Ludovic Robert, the lead and SME for TMF641.

​

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

Hi Uma
The use case is certainly valid, and perhaps applies also to product order.
The way to proceed would be to open a change request, if you have access to Open API JIRA you can do this yourself at https://projects.tmforum.org/jira/projects/AP/issues
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: Jul 08, 2020 20:01
From: uma lakshman
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Thanks Jonathan  and Ludovic .

We agree that there is no existing pattern for resolving this usecase.

@Jonathan Goldberg,
Based on your comment below,

"To achieve your use case would require keeping multiple versions (perhaps) of the service order, and canceling a patch request would somehow cause reversion to the previous version, assuming that this was still possible (depending on what work was already done)."

Is there any chance that the upcoming release will have a support for version in service order level ?

Uma Lakshman,
Telstra Corporation
​

------------------------------
uma lakshman
Telstra Corporation
------------------------------


Original Message:
Sent: Jul 07, 2020 10:36
From: Ludovic Robert
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Hello Uma, Jonathan

I do not have a lot to add to Jonathan answer.

We have also in the TMF Open API the Monitor pattern that allow managing asynchronous response (In the response of POST or PATCH you get a 202 and a monitor id). This is illustrated in TMF640.
But if this mechanism allows you manage long running task triggered from a POST or PATCH it will not able to manage cancellation request of an in progress request.

Thanks,
Ludovic

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


Original Message:
Sent: Jul 07, 2020 10:28
From: Jonathan Goldberg
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Hi Uma

I don't think that we have reached this level of granularity in the Open API semantics for orders (such as service order).
At least according to my understanding of current semantics, a POST and a PATCH on a service order are synchronous, in other words the result is immediate (201 for POST and 200 for PATCH).
And PATCH can be invoked any number of times (until the PoNR).
To achieve your use case would require keeping multiple versions (perhaps) of the service order, and canceling a patch request would somehow cause reversion to the previous version, assuming that this was still possible (depending on what work was already done).
Deferring to @Ludovic Robert, the lead and SME for TMF641.

​

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

Thanks @Jonathan Goldberg
 
JIRA ticket https://projects.tmforum.org/jira/browse/AP-2283 is created to address this issue.

​

------------------------------
uma lakshman
Telstra Corporation
------------------------------

Original Message:
Sent: Jul 12, 2020 02:18
From: Jonathan Goldberg
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Hi Uma
The use case is certainly valid, and perhaps applies also to product order.
The way to proceed would be to open a change request, if you have access to Open API JIRA you can do this yourself at https://projects.tmforum.org/jira/projects/AP/issues
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: Jul 08, 2020 20:01
From: uma lakshman
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Thanks Jonathan  and Ludovic .

We agree that there is no existing pattern for resolving this usecase.

@Jonathan Goldberg,
Based on your comment below,

"To achieve your use case would require keeping multiple versions (perhaps) of the service order, and canceling a patch request would somehow cause reversion to the previous version, assuming that this was still possible (depending on what work was already done)."

Is there any chance that the upcoming release will have a support for version in service order level ?

Uma Lakshman,
Telstra Corporation
​

------------------------------
uma lakshman
Telstra Corporation


Original Message:
Sent: Jul 07, 2020 10:36
From: Ludovic Robert
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Hello Uma, Jonathan

I do not have a lot to add to Jonathan answer.

We have also in the TMF Open API the Monitor pattern that allow managing asynchronous response (In the response of POST or PATCH you get a 202 and a monitor id). This is illustrated in TMF640.
But if this mechanism allows you manage long running task triggered from a POST or PATCH it will not able to manage cancellation request of an in progress request.

Thanks,
Ludovic

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


Original Message:
Sent: Jul 07, 2020 10:28
From: Jonathan Goldberg
Subject: Cancellation Of Inflight Patch on TMF 641 - ServiceOrderManagement API

Hi Uma

I don't think that we have reached this level of granularity in the Open API semantics for orders (such as service order).
At least according to my understanding of current semantics, a POST and a PATCH on a service order are synchronous, in other words the result is immediate (201 for POST and 200 for PATCH).
And PATCH can be invoked any number of times (until the PoNR).
To achieve your use case would require keeping multiple versions (perhaps) of the service order, and canceling a patch request would somehow cause reversion to the previous version, assuming that this was still possible (depending on what work was already done).
Deferring to @Ludovic Robert, the lead and SME for TMF641.

​

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