Open APIs

 View Only

TMF622 R19.0 Questions/Comments

  • 1.  TMF622 R19.0 Questions/Comments

    Posted Sep 05, 2019 08:14
    First off, thanks to all that contributed to the R19.0 version of TMF622. 

    Long time lurker, first time poster.

    Have a reasonable amount of experience developing order management/fulfillment systems for CSPs and a few basic questions to start with.

    1. Has any thought been given to rationalize TMF622 and TMF641? There is natural synergy between how OM systems at different levels operate - and this is manifest in the many similarities between the two specs. Wouldn't it be better (simpler to understand, more consistent and higher quality implementations) to refactor out the common parts and isolate the pieces which are truly unique from one to the other? If this is an age old debate then I apologize for scratching an old wound - but would be interested in any wisdom the community has to offer on this subject.
    2. Little thought seems to be given as to how in-flight revisions are handled. There is only narrow support for one in-flight use case which is the wholesale cancellation of an order, and the approach taken on that does not lend itself to a more general expression of the problem. Moreover, the spec allows things like a patch or post to be done to update an order - yet does not address how these may be considered by the implementing system. For example, the spec allows the implementation to consider and reject or accept a cancellation request and provides states to communicate the status of this evaluation - yet it is silent on any similar process that is undertaken when dealing with in-flight changes. Am I missing something or is the whole area of in-flight changes and related advanced OM scenarios not (yet) addressed in the spec?
    3. On failures - how are failures corrected? The spec indicates that an order can undergo a complete or partial failure - either of which is final meaning no recourse can be taken to correct the error. Yet commonly we see scenarios where substantial work has been done on an order, errors occur, and there is a need to understand and take corrective actions on the order in place. This would mean that an order in the failed or partial states could be altered in such a way as to allow the order to progress (as an example, by submitting an amendment to the order to do an in-flight change, or by doing a partial cancellation of the order). How are these scenarios handled?
    4. How are roll-ups of order item state and order state handled? e.g. Between parent and child line items, or across top level line items and order state. Is there a standard definition of how these states should be represented given various permutations of state across parent and child line items? Are parent line items for example always purely derived from the state of child line items, and does it follow therefore that the order state is derived purely from root order items?
    5. The order state machine allows an order to progress from held to cancelled. Can someone explain this transition? I would have thought the more consistent transition would have been from held to assessingCancellation or at least pendingCancellation to ensure any necessary functional compensation for the cancellation is consistently represented and communicated.
    6. How are cross order dependencies/relationships represented? There are several common use cases for cross order dependencies/relationships that are important to understand/communicate - including follow-on orders, batch orders, child orders, revisions, etc. 

    Thanks in advance for input from the community.

    ------------------------------
    Brian Dueck
    Oracle Corporation
    ------------------------------