Hi,
I came across the same problem recently and saw this interesting discussion.
In our project we have 2 business functionalities for Product Ordering where I am lost how to solve them in a TMF622 conformal manner:
1. Support of pending orders:
A client may first submit (POST) an incomplete order, then complete it on the basis of some customer interaction (e.g. arrange an appointment at a certain date), add some order items or attributes, update (PATCH) the submitted order accordingly and finally decide to get the order started.
- To support the last step in a SOAP oriented interface one would introduce some operation "executeOrder(id)" which may be called by the client in order to signal the productOrdering engine that the order is now ready to be processed.
- In TMF /REST we only have the given set of http operations (we cannot simply introduce some additional EXECUTE operation) and the order "state" attribute avaiblable.
- From what I have learned from TMF622 the state is NOT a patchable order attribute, but instead only the product order engine controls the order state. So the consumer must NOT be able to drive the order state from, let's say, "initial" (acknowledged) to "Pending" to "InProgress".
- So neither the given operations nor the state can be leveraged to meet this needs. Instead, the logic seems to be transferred to the engine which has to be able to decide whether an order is complete or not. But this looks quite impossible - given that many attributes are optional how should the engine know whether an order is already complete or not from a business point of view?
2. Order cancellation:
A client may wish to cancel the order (which might be pending or already running).
- This problem also relates to the fact that it is not possible from ouside to change the state (e.g. from "pending" or "InProgress" to "Cancelled").
- Certainly, a DELETE operation should not be used to mimic a cancel operation since it has some other meaning.
Maybe the solution for both problems would be
to allow to patch the state with a PATCH operation from outside - and leave it to the responsibility of the engine to decide whether this state change would be accepted (according to the internal state model and some business logic as for instance some PonR logic). Or introduce new APIs for both sort of operations.
Is there meanwhile some hint available in which direction TMF622 will being evolved?
Best regards
Thomas
------------------------------
Thomas Dupré
Deutsche Telekom AG
------------------------------
Original Message:
Sent: Jun 13, 2019 08:26
From: Andrey Lednev
Subject: Product Ordering Management API
Thanks everyone
Honestly, I agree that it is better to have allocated API for Cancellation operation.
just wanted to check if someone has any arguments to do it via PATCH
------------------------------
Andrey Lednev
Original Message:
Sent: Jun 03, 2019 01:11
From: Ashish Doodhwala
Subject: Product Ordering Management API
Dear All,
Penning my thoughts :
There can be scenarios which are requried to make change on the running order. A simple use case can be just change in service configuration parameters and complex use case not to proceed with fulfillment of products and services subscribed in the order for one or other reasons.
Almost all operations will be driven business specific and API is more to serve exchange if information in more formal and standardized manner. For more complex operations like cancellation having a separate API will help segragate the logic , clearly visibility from Order entry to Order fulfillment i.e . from front desk to back end operations teams , overall clarity across the stakeholders.
On operations like cancellation also serves to great extend beyond the traditional fulfillment usecase like reporting, long running order, stuck order beyond control , very corner cases .
BR,
Ashish
------------------------------
Ashish Doodhwala
Ericsson Inc.
Original Message:
Sent: May 30, 2019 07:44
From: Jonathan Goldberg
Subject: Product Ordering Management API
Hi Andrey (and all)
The following is my opinion only.
Where there is a significant business operation, I prefer to see a dedicated API for this, rather than "hiding" it in an attribute change (even if you add the checks and validations).
Apart from @Ludovic Robert's point about point of no return, there can be impacts even at order capture time for a cancel, e.g. a cancelation fee might need to be collected, or there may be an impact on a dependent order, etc.
Additionally the cancel may need to be asynchronous, and PATCH is generally synchronous - making the cancel a TASK resource allows us to handle synchronous and asynchronous use cases very cleanly.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Original Message:
Sent: May 27, 2019 05:10
From: Andrey Lednev
Subject: Product Ordering Management API
Hi Ludovic,
I'm investigating Cancellation options as well and found your proposal with 'Cancel' API.
However TMF622 PATCH operation has 'State' in the list of patchable attributes. So that I thought to allow to PATCH state of the Order. However to add some logic behind the PATCH operation, i.e. to check state transition, validate that transition is allowed, PoNR is not reached and etc and only after that to execute Cancellation logic. So that Order Fulfilment system will be responsible for all validations and business logic.
So I'm looking for advantages and disadvantages of both approaches.
Any thoughts?
------------------------------
Andrey Lednev
Original Message:
Sent: Dec 06, 2018 03:52
From: Ludovic Robert
Subject: Product Ordering Management API
H
Hello Joana
I'm a bit uncomfortable to add a capability to modify productOrder via a PATCH operation except of course for ADMIN. My concern is that the server side is responsible to order fulfillment and getting a PATCH to cancel the order for example could be an issue if the order had already reach point of no return.
I'm involved in MEF (Metro Ethernet Forum) in for example there we defined a specific operation: POST productOrder/{id}/cancel to allow client side to request a cancellation (but the resource is a cancellation request and not the order). It allows server side to deny the request if PONR reached.
Perhaps one way to handle it is to use the shoppingCart API for the whole order capture process (including payment & billing Account link capture) and then switch to the product order to manage the fulfillment.
Hope it helps.
------------------------------
Ludovic Robert
Orange
Original Message:
Sent: Dec 04, 2018 09:48
From: Joana Lopes da Fonseca
Subject: Product Ordering Management API
Hello Ludovic,
Thank you so much for your help.
I have looked into Shopping Cart API, where is mentioned that when the user goes to checkout shopping cart, an order is created (draft status), as explained in the image from REST Specification document presented bellow:
But, what this draft status means? I was not able to understand this in any of the API's and since we are not able to patch the status in product ordering, how can we change this status of the order after the payment?
It is the same problem again, since it is not possible to patch the field status.
Or to go from order in draft status to place order (ackowledged status) it is not necessary to patch the status? What is supposed to be done to, after the payment change the order (draft status) to the order (ackowledged status)
Thank you so much for your help.
Best Regards,
------------------------------
Joana Lopes da Fonseca
Celfocus
Original Message:
Sent: Dec 04, 2018 08:34
From: Ludovic Robert
Subject: Product Ordering Management API
Hello Joana,
Please take a look on the API TMF 663 Shopping cart. I presume your UC should be more supported with this API; They were a lot of discussion of the transfer point from shopping cart to product Order but till customer has not yet validated her/his basket you could use the shopping cart.
Hope it helps.
------------------------------
Ludovic Robert
Orange
Original Message:
Sent: Dec 04, 2018 05:48
From: Joana Lopes da Fonseca
Subject: Product Ordering Management API
Hello,
I have a doubt regarding Ordering Management API's that you may be able to help me with.
By reading and analyzing the Ordering Management API's, I have understand that, and please correct me if I am wrong, the following:
My question is:
- Let's imagine that, for some reason, and before the completion of the product order created (the only order the customer has knowledge of):
- The user decides that he no longer wants the product he is acquiring and wants to cancel de product order.
Since it's not possible to patch the state of the product order or the state of the product order items, how can the agent cancel the product order he has just created?
- The state of the product order is partially failed, the agent wants to solve the problem for the customer he has in front of him and wants to re-submit the order.
Since it's not possible to patch the state of the product order or the state of the product order items, how can the agent "re-submit" the product order he has just created?
I have seen that, between all the Ordering Management API's, only Resource Order allows to Patch the state. Can you help me understand why only resource orders allow that?
Can we have an extra operation on Product Ordering Management API in order to be able to cancel or re-submit an order?
Thank you so much for your help understanding this points.
Best Regards,
------------------------------
Joana Lopes da Fonseca
Celfocus
------------------------------