Yes good conversation with the team today.
200 or 201 will depends on the implementation choice... if server side is able to repond on the fly in the response and do not want to manage cancelServiceOrder resource I'm fine with 200.
If not, server will answer later, then a resource must be created, GET operation must be provided (and notification) then yes 201 must be sent.
From my perspective I did no see objectiion to have both 200 and 201 in the API definition.
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------
Original Message:
Sent: Sep 09, 2020 12:06
From: Igor Veliev
Subject: TMF641 - Cancel Service Order lifecycle misalignment
@Ludovic Robert I just saw meeting minutes after your discussion.
I have a small concern that the status must be 201 (Created) instead of 200 (Ok), because it's POST and we can receive created resource with GET /cancelServiceOrder/{id} even if it's 'terminatedWithError'.
------------------------------
Igor Veliev
Netcracker Technology
Original Message:
Sent: Sep 07, 2020 10:34
From: Ludovic Robert
Subject: TMF641 - Cancel Service Order lifecycle misalignment
Hi Igor,
For the serviceOrder, the capability to have an Error Message is part of the current work in progress by @Kamal Maghsoudlou for the release 4.1. This feature will allow to refer (if needed) service order items. So I guess it will answer your requirement.
Your jira 2343 is helpful to assess same patern for CancelServiceOrder resource.
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 07, 2020 07:23
From: Igor Veliev
Subject: TMF641 - Cancel Service Order lifecycle misalignment
@Ludovic Robert how about Service Order in failed state?
If we believe CancelServiceOrder should have error details then probably each failed ServiceOrderItem within ServiceOrder needs to have something similar too?
@Dave Milham maybe error details required in all Ordering APIs (622, 641, 652) on main Order and Cancel Order resources for failed/terminatedWithError states?
------------------------------
Igor Veliev
Netcracker Technology
Original Message:
Sent: Sep 04, 2020 05:01
From: Ludovic Robert
Subject: TMF641 - Cancel Service Order lifecycle misalignment
Hello Igor,
To provide you some information regarding first two points:
- For 'accepted' or 'acknowledged' : Yes you're right. This inconsistency has been identifed by the team (thanks to @Ernie Bayha) and a Jira to fix it is already logged.
- For describing error this is a valid point - May I request you to trigger a jira for this to the team? @Kamal Maghsoudlou is currently working on TMF641 in particular to manage message.
Regarding the third point this is more complicated to solve. I assume we have alignement on order (state).
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 03, 2020 12:10
From: Igor Veliev
Subject: TMF641 - Cancel Service Order lifecycle misalignment
Hello community,
I'm confused a bit with Cancel Service Order state.
Is initial state 'accepted' or 'acknowledged'?
It is also not clear, how to describe error details in case of 'terminatedWithError'.
By the way, will the Product Inventory/Ordering be consistent with the Service Inventory/Ordering in terms of 'status' vs 'state' in instances?
------------------------------
Igor Veliev
Netcracker Technology
------------------------------