Open APIs

Expand all | Collapse all

Product Ordering Management API

  • 1.  Product Ordering Management API

    TM Forum Member
    Posted Dec 04, 2018 07:39

    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
    ------------------------------
    DT America


  • 2.  RE: Product Ordering Management API

    TM Forum Member
    Posted Dec 04, 2018 08:50
    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
    ------------------------------

    DT America


  • 3.  RE: Product Ordering Management API

    TM Forum Member
    Posted Dec 04, 2018 10:19

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

    DT America


  • 4.  RE: Product Ordering Management API

    TM Forum Member
    Posted Dec 06, 2018 04:26
    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
    ------------------------------

    DT America


  • 5.  RE: Product Ordering Management API

    Posted May 27, 2019 08:09
    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
    ------------------------------

    DT America


  • 6.  RE: Product Ordering Management API

    TM Forum Member
    Posted May 30, 2019 09:36
    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
    ------------------------------

    DT America


  • 7.  RE: Product Ordering Management API

    TM Forum Member
    Posted Jun 03, 2019 03:21
    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.
    ------------------------------

    DT America


  • 8.  RE: Product Ordering Management API

    TM Forum Member
    Posted Jun 13, 2019 09:04

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

    DT America


  • 9.  RE: Product Ordering Management API

    TM Forum Member
    Posted Jul 03, 2019 10:00
    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
    ------------------------------

    DT America


  • 10.  RE: Product Ordering Management API

    TM Forum Member
    Posted Jul 05, 2019 05:34
    Hi Thomas,

    As I got you are talking about In-Flight operations.
    From my experience, In-Flight is additional Order which is linked to the previous one. Based on the newly created Order OrderManagement System should Cancel/Obsolete previous Order, update process and etc.
    Regarding PoNR could be different ways to check it either via explicit PoNR value on some entity or via internal logic in OrderManagement. So that it could be additional API to check that PoNR is reached or for example logic on FrontEnd to disable In-Flight if PoNR is set.  


    ------------------------------
    Andrey Lednev
    ------------------------------

    DT America


  • 11.  RE: Product Ordering Management API

    TM Forum Member
    Posted Jul 05, 2019 12:51
    All - There has been debate within the API team regarding the applicability of PATCH to state/status of resources in general, and of <xxxx>Order in particular. It's good to see that the community is weighing in with its opinions.
    Specifically for the latest posts:
    • For point 1, about order submission, I would argue that POST of a Product Order is not necessarily an act of formal submission, and to resolve this you might want to add a Task resource SubmitOrder that sets the order off for execution after first validating what needs to be validated. As for Cancel, the advantage of using a Task resource is that it allows you to include a feedback structure for more detailed reporting of errors than would be possible in a single HTTP return code from a PATCH to the status.
    • For point 2, I think we are all in agreement that DELETE should not be used to cancel an order.
    Reaching out to @Ludovic Robert - the owner of the ProductOrder API - for more insights.​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------

    DT America