Open APIs

 View Only

  • 1.  TMF 622 - Place management for an Order

    Posted Apr 08, 2022 03:17
    Hi all, 
    I would like to ask if using place field as a complex object is compliant with the TMF 622? Unfortunately on the specification the samples are not filled with this information. 
    Thanks in advance, 
    Filippo

    ------------------------------
    Filippo Roberto Valeriani
    NTT DATA CORPORATION
    ------------------------------


  • 2.  RE: TMF 622 - Place management for an Order

    Posted Apr 08, 2022 05:34
    Edited by Koen Peeters Apr 08, 2022 05:34
    Hi,

    I would like to give both a short and a long answer.

    Short answer
    The datamodel defines place as a RefOrValue. This means a complex object is indeed compliant.

    Long answer
    In general all OpenAPI can be organised in 3 broad categories:
    • Catalog API
    • Inventory/repository API
    • Process API: Order, Task, ...
    The Catalog and Inventory API are designed to handle a single entity, the CUD interfaces should implement the separation of concern principle. These interfaces should not hide any side effects and thererfore they should not use RefOrValue parameters.

    The API in the process category are designed to handle processes that might involve several steps. The process might impact several inventories. For these processes the use of RefOrValue can't really be avoided. If an order process needs to create entities in an inventory, it will probably need some values for creating or updating values for this inventory item. The process might also use values as search criteria for searching in existing inventories.

    If your implementation embeds a complex object for place. It is important to understand that you will need to define the process to handle it. You will also need to consider that you are increasing the possible exceptions that will occur.
    Will the process use the information to search in existing geographicAddress / GeographicSite repositiory? This will inevitably lead to not-found conditions. How will you handle this? What will happen to the order? Will it fail? Will you need to amend and resubmit?
    Will the process use the information to create new places in a repository? How will you avoid duplicates? How will you maintain an hierarchical model? How will you handle exceptions. Will the order fail in that case?

    It is generally a good design principle to design your order process as a backend process with a very low likelyhood for failure. In most cases that will speak against having a complex object for place in the order. It is better to have front end process that validates the place first and handles all possible exceptions. The result of that frontend process is that the product order can pass the place by reference, avoiding failure risks for the process.

    So although sending a complex place object in your productorder is compliant to TMF622, it is usually not the best solution. Business constraints, timeline, budget might force you to use the solution with complex place objects, but it definitely leaves room for later improvements.

    Regards




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

    Original Message


Related Content