Open APIs

 View Only
Expand all | Collapse all

Understanding RelationShipType in Product Ordering TMF622 Release 17.5

  • 1.  Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    Posted Aug 21, 2019 10:40

    Hi,

    Need to understand what is the meaning of below values of RelationShipType used in orderItemRelationship between two orderItems

    Values: reliesOn, brings, hasParent, hasChild 

    "orderItemRelationship":[
            {
               "id":"110",
               "type":"reliesOn"
            }
    ]



    ------------------------------
    Rabinder Devnani
    Sterlite Technologies Limited
    ------------------------------


  • 2.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    TM Forum Member
    Posted Aug 21, 2019 11:20
    Hello Rabinder

    The relationship type is useful to qualify relation between 2 ordered product. We provided some examples in the API but implementation could define other.

    If I provide examples from implementation experience:
    • reliesOn is used when a technical prerequisite enforce to have a relationship between the product (and will be useful in service delivering). A mobile access must have a relies on on a sim card, a TV access must have a relies on on internet access for example. This relationship will be in the inventory and used in delivering.  That's just examples and they could be described in other way - this is is not product modeling recommendation ;)
    • brings is useful when 2 product are not tied technically but commercially. You want to keep thack in your inventory that this product A for example triggered this other product B selection. In future when customer will terminate A, it will allow you to automatically terminate B.
    • hasParent/hasChild could be used to describe the commercial hierarchy. Suppose you order a Bundle A with product B and C. You can have 3 orderItems - the one for A will have hasChild relationship to orderItems describing ordering of B & C. OrderItem for B & C can have hasParent relationship to orderItem for A. 
    These are examples of implem but other relationship type could be added with defined semantic.

    Hope it helps

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    ------------------------------



  • 3.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    Posted Aug 21, 2019 12:19
      |   view attached

    First of all thank you @Ludovic Robert for your quick reply and your contribution to the Open API :)

    ​​If I provide examples from implementation experience:

    • reliesOn is used when a technical prerequisite enforce to have a relationship between the product (and will be useful in service delivering). A mobile access must have a relies on on a sim card, a TV access must have a relies on on internet access for example. This relationship will be in the inventory and used in delivering.  That's just examples and they could be described in other way - this is is not product modeling recommendation ;)
      <<Rabinder>>: So you are saying that this defines/impacts the service delivery sequence some how. I have attached a triple play sample depicting the same, kindly have a look at and share your views on it.
    • brings is useful when 2 product are not tied technically but commercially. You want to keep thack in your inventory that this product A for example triggered this other product B selection. In future when customer will terminate A, it will allow you to automatically terminate B.
      <<Rabinder>>: Ok, but the actions on individual items i.e. no-change, modify, delete will still be passed from the order capturing system using this relationship type, so I am assuming it is meant for service inventory to be able to define the impact of change in bundle
    • hasParent/hasChild could be used to describe the commercial hierarchy. Suppose you order a Bundle A with product B and C. You can have 3 orderItems - the one for A will have hasChild relationship to orderItems describing ordering of B & C. OrderItem for B & C can have hasParent relationship to orderItem for A. 
      <<Rabinder>>: As I see in the sample described in TMF 622 17.5, this relationship is well portrayed as orderItem hierarchy, so the product B & C will be orderItems inside the Bundle A orderItem, this enables n-level hierarchy of Bundles and eases the tracking. This is my understanding, please share your views if different. Do we still need hasParent/hasChild relationship types?


    ------------------------------
    Rabinder Devnani
    Sterlite Technologies Limited
    ------------------------------



  • 4.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    TM Forum Member
    Posted Aug 23, 2019 03:25
    Hi Rabinder

    For the relies on I good way to proceed is to look on the fulfilment process and check constraint(s). Suppose to deliver A you must have B already there and for B you need C. D has no constrait.  In this case I expect to have no relationship from the D order item. same for C. One relationship for orderItem for B targeting C, and one relationship from order Item dor A targeting B.
    I forget to mention it but this relationship must be defined in the catalog.

    For brings it is a commercial relationship that you want to keep in the inventory to link both product lifecyle.

    For the last point we have a discussion on another threat.  Embedded order item could be used instead of this relationship.

    And as previously written these are just examples how to leverage API relationship feature but the relationship type semantic is not 'normative' but just 'informative'.

    Ludovic

    ------------------------------
    Ludovic Robert
    Orange
    ------------------------------



  • 5.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    Posted Aug 23, 2019 03:45
    Thanks @Ludovic Robert for detailed understanding, I was previously in doubt about how this relation ship will exist without a catalog :)

    ------------------------------
    Rabinder Devnani
    Sterlite Technologies Limited
    ------------------------------



  • 6.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    TM Forum Member
    Posted Feb 24, 2022 09:40

    Hi @Ludovic Robert,

    in terms of the relationship scenario below we have a similar question.
    ,
    Assuming that a set of of services are ordered and then committed to inventory (638) in the following example: -​​

    Service 1 (Voice Service)  --reliesOn---> Service 2 (Broardband) ---reliesOn----> Service 3 (fibreAccess)

    How would the relationsips be modeled on Service 2  when requested via GET  on service inventory (638). Clearly the relationship with Service 3 is reliesOn. But what about the relationship with Service 1.

    cheers

    Dave



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



  • 7.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    TM Forum Member
    Posted Aug 17, 2022 14:51
    I'm in a previous step: What are the possible values for relationshipType?

    Examples in TMF620: reliesOn, discountedBy, OptionalFor, Dependency, DependsOn, relyOn
    Examples by experience: changeableTo, contains, isChild, isParent, requires, exchangableTo

    Although this can be customizable it whould be great if TMF defines a base standard.
    Either we have a base definition and other needs improve the list of values or all the options are disputable :(

    ------------------------------
    Gonçalo Furtado
    Celfocus
    ------------------------------



  • 8.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    TM Forum Member
    Posted Aug 18, 2022 03:30
    Hello Gonçalo,

    I get your point but it seems to me a bit complex to define a core standard. We tried some time ago for the service relationship but we were only able to provide an example list but not standard. The diversity of relationshipType name use in industry softwares makes it complex to standardize.

    Perhaps a way to progress on this will be to work jointly API team and "IG1233 Product & Service Modelling Best Practices - Conforming to ODA" authors in order to define a relationship type semantic.

    Thanks,

    Ludovic

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



  • 9.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    TM Forum Member
    Posted Nov 03, 2022 09:58
    @Ludovic Robert still have an interest in your thoughts on this scenario here......

    Service 1 (Voice Service)  --reliesOn---> Service 2 (Broardband) ---reliesOn----> Service 3 (fibreAccess)

    how would you suggest that the 'reverse' of a relationship is modelled in inventory?

    So if a client 'Gets' service 2 it can use the information committed to storage that

    'service 2 reliesOn service 3' and present that in the API response. However for the relationship between service 2 and service 1 it cannot simply return this relationship 'as is' because from service 2 perspective this doesnt make sense?

    thanks

    Dave



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



  • 10.  RE: Understanding RelationShipType in Product Ordering TMF622 Release 17.5

    TM Forum Member
    Posted Nov 03, 2022 11:55
    Hi David,
    For you information I've changed position in my company and consequently TMF open APIs contributions are not anymore in my duties so I will refrain myself in future to engage in this forum. 

    You point is very valid !
    We define the relationship in one way but we should be able to read it in both way. In my company we have implementation with reliesOn relation (defined in the catalog, described in the order, stored in the inventory)  but also with a 'reflexive' reliesFrom. We do not store this one in the inventory but we're able to 'retrieve' it on the fly. The reliesFrom is not  described in the order but it could make sense in the catalog. Indeed you can have UC where a product cannot be targeted more than n times from other product.

    hope it helps

    Ludovic

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