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


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



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



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



  • 5.  RE: Product Ordering Management API

    Posted 21 days ago
    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
    ------------------------------



  • 6.  RE: Product Ordering Management API

    TM Forum Member
    Posted 18 days ago
    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
    ------------------------------



  • 7.  RE: Product Ordering Management API

    TM Forum Member
    Posted 14 days ago
    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.
    ------------------------------



  • 8.  RE: Product Ordering Management API

    TM Forum Member
    Posted 4 days ago

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