Open APIs

 View Only
  • 1.  Resubmission of a Product Order...

    TM Forum Member
    Posted Nov 30, 2021 07:37
    Dear Members,

    I have a requirement where a product order request needs to be resubmitted by the consumer of Product Ordering API with order id.
    Here scenario is as follows:
    An Product Order Request was submitted to Customer Order Management System using product Ordering Micro-service. These order processing got failed in fulfilment system and updated to order front end application. In certain scenario, it can be resubmitted by channel using order id with or without changing few order attributes.

    Since I don't find any resubmission api in TMF622. Should patch api be used?  Or can we use same order management api with order id additionally to resubmit the order?
    Please provide your suggestion.

    Thanks & regards,
    Anil Jain

    ------------------------------
    Anil Jain
    Tata Consultancy Services
    ------------------------------


  • 2.  RE: Resubmission of a Product Order...

    TM Forum Member
    Posted Nov 30, 2021 09:03
    Hi Anil

    It looks like you are talking about an Amend to a Product Order.
    We have an open CR (AP-2402) for adding a task resource to TMF622 (and TMF641) for Amend, in a similar way to the existing Cancel task resource.
    PATCH directly is not a good idea, since there could be financial implications, changes in feasibility/qualification/dates, and more.
    Unfortunately I cannot tell you if and when this CR will be processed, @Ludovic Robert might want to add his thoughts.​

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



  • 3.  RE: Resubmission of a Product Order...

    TM Forum Member
    Posted Nov 30, 2021 10:42
    Hello
    Agreeing with Jonathan about reluctance to use PATCH in this context  and probably the safest choice is to look for a dedicated task (and leverage TMF pattern for task-based resource) . We had this discussion also in the MEF context, and as far as I know the decision was to craft specific tasks to handle the modification request types.

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



  • 4.  RE: Resubmission of a Product Order...

    TM Forum Member
    Posted Dec 01, 2021 04:02
    Hi Jonathan,
    We had the following functionality with the software vendor proprietary APIs:
    Supplemental Order:  (aka order revision) it will override an existing order (same order Id, higher rev #)  that was already sent to fulfilment but is still "in transit"/before PONR
    I read AP-2402 in JIRA and it seems like Amend order is the same.

    have you considered this scenario:
    Follow-On Order
    : future date order to change a product offering before it is "productized" in inventory. It references the previous order (which is used as the starting point) but can only be done after PONR. from a user point of view, this would behave like a modify order, action code would use delete/modify/... values. This was a great feature for customers who change their mind but didn't want to wait days (or weeks) for the product to be in inventory to make a change order.

    ------------------------------
    Matthieu Hattab
    Altibox AS
    ------------------------------



  • 5.  RE: Resubmission of a Product Order...

    TM Forum Member
    Posted Dec 01, 2021 11:47
    Hi Matthieu
    In what you call Follow-on order, you're getting into extremely complex and sticky ground. Commercial and robust order management systems (like the ones we build at Amdocs, and I'm sure by other vendors in this space) need to deal with pending orders, overlapping orders, and all the rest.
    Just a couple of examples:
    • It's now 1-Dec-2021. Customer has requested a move (change address) to take place on 15-Jan-2022. But in the meantime the customer has decided that she wants an upgraded speed, ASAP, so we have a new order to go into effect on 5-Dec-2021. We now need to ensure that the speed change is propagated to the pending move order, and also (perhaps) verify that the new speed is feasible/serviceable at the new address.
    • It's now 1-Dec-2021. Customer has requested a move (change address) to take place on 15-Jan-2022. But customer also wants to suspend the product at a later date 3-Mar-2022 due to planned vacation. So now we have a new order to go into effect on top of the moved product.
    I honestly don't know how to represent these complexities in the Open API TMF622, it is most likely to be done in vendor-specific extensions.

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



  • 6.  RE: Resubmission of a Product Order...

    TM Forum Member
    Posted Dec 02, 2021 04:53
    Hi,

    I fully agree that the PATCH approach for amending orders has its drawbacks and for many scenarios it can't provide syncronuous reponses as expected by a PATCH.
    The AP-2402 aproach seems much better here.

    Your Follow-On order scenario can be handled easily if your ordering application updates the inventory in the following way:
    • TMF620 POST provides synchonous response after syntax validation only
    • Asynchronous logic provides semantic validation (against catalog) and creates productsin state 'created' in the inventory. The id of the created product is added in a ProductOrderStateChangeNotification with state='acknowledged'

    Once the acknowledgement is received Follow-On orders, with a requestedCompletionDate later than the original order, can then be created using the product ids of the created, but not active products. Handling Follow-on orders with a requestedCompletionDate earlier than the first order is more tricky and often not supported by ordering systems. But when your ordering system updates your ProductInventory early enough in the process, it is usually a matter of proper planning of the steps. and writing the result in the product inventory.

    The key of doing this successfully is updating ProductInventory as early as possible and then keeping it up to date with each state change. If you use this aproach there are only very few scenarios that are not feasible.

    Regards

    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 7.  RE: Resubmission of a Product Order...

    TM Forum Member
    Posted Dec 03, 2021 06:40
    We have also come to the same conclusion that the PATCH approach has too many drawbacks for us and is not a route we want to go down. The order management system cannot perform the actions needed within a reasonable timeframe to provide that syncronous response. We are also not keen on the monitor approach that i know can be used in this scenario but puts the onus on the client to 'check back' with the server to see if the request has been fulfiled.

    So based on the Cancel Task pattern in TMF641 we are currently implementing an Amend task in our TMF641 to handle this considering the previous implementation, our requirements and the MEF content. Given that this is unlikely to be exactly as per the eventual implementation in the offical swagger it isnt ideal, it would be great to get some idea of when it will be considered?

    ------------------------------
    David Whitfield
    TalkTalk Group
    ------------------------------