Open APIs

Expand all | Collapse all

TMF_622 Order Management

  • 1.  TMF_622 Order Management

    Posted Jan 16, 2019 10:43
    Hi All,

    I am studying to use the TMF 622 Order Management for order creation. I find difficulty on matching the field on existing order form into the Data object. Is there any example or case study for reference?

    Regards
    Mimi


  • 2.  RE: TMF_622 Order Management

    TM Forum Member
    Posted Jan 20, 2019 14:07
    Can I suggest that you provide more explicit information about the fields on your order form. This would help community members to assist you.

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



  • 3.  RE: TMF_622 Order Management

    Posted Jan 21, 2019 06:19
    HI Jonathan,

    Thanks for yours reply. In my order form, there are some product specific info: Bandwidth, Port Speed, Port type, installation address A, installation address A contact person, installation address B, installation address B contact person, network interface, etc. Can I create some special data object for my use case? But it will violate the open-API standard.

    Regards
    Mimi

    ------------------------------
    Mimi :aw
    HGC Global Communications Ltd
    ------------------------------



  • 4.  RE: TMF_622 Order Management

    TM Forum Member
    Posted Jan 21, 2019 09:41
    The challenge for you, and indeed for anyone who is developing a UI for order capture, is that the nature of the product is determined by the catalog. This is clearly not specific to the TMF Open API domain.
    There are various ways to deal with this (and I am sure that I have not listed them all here) - each approach has advantages and disadvantages:
    • Generate your order form (UI) dynamically from the catalog definition (using the ProductSpecifications, ProductSpecCharacteristics, and more). This offers maximum flexibility but can cause usability issues in the UI. You might need to add UI metadata to the catalog, or to some other presentation layer and maintain alignment with the catalog.
    • Create a specific UI for each product type, and a strongly-typed API layer for your UI to consume (with specific entities such as Broadband, Bandwidth, etc.), and create in this layer a mapping to the underlying catalog model and Open API. This means that for each new product specification you will need to write code and create a specific UI, but the usability for end users is likely to be much improved.
    • Create a specific UI for each product type, and create extensions for each product and product spec, using the extension patterns (see the published API guidelines) - so an entity BroadbandSpec would be derived from ProductSpecification (and Broadband from Product). Here also you will need to write code and create a specific UI, but you don't need an intermediate layer, your new entities are compatible with the Open API (if you follow the extension pattern correctly)
    • ... other solutions ...


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