Open APIs

Expand all | Collapse all

Why RelatedParty's id and href are not mandatory for Service Ordering?

  • 1.  Why RelatedParty's id and href are not mandatory for Service Ordering?

    TM Forum Member
    Posted 14 days ago
    Hi everyone.
    Exploring TMF641 interface I get across with RelatedParty where a name and role should be given on Service Order creation.  Even though it could be considered that href and id of RelatedParty are useless for Service level,  IMHO name can't be mandatory since it is not mandatory for Product Ordering, unless it means that Product Order level should retrieve the name of RelatedParty before sending it to Service level, Don't you think that is more complex than just send a href which is already there? I would prefer to get thinking that RelatedParty should be referred to the same object across Product and service levels, or made the name mandatory for Product level as well.

    ------------------------------
    Andrii Teslenko
    Netcracker Technology
    ------------------------------


  • 2.  RE: Why RelatedParty's id and href are not mandatory for Service Ordering?

    TM Forum Member
    Posted 14 days ago
    It looks like this is a defect in the API definition. In release 19 neither name nor role are mandatory in RelatedParty.
    Referring to @Ludovic Robert who is responsible for Service Ordering API.
    Hope it helps.​

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



  • 3.  RE: Why RelatedParty's id and href are not mandatory for Service Ordering?

    TM Forum Member
    Posted 14 days ago
    Hello

    Yes you're both right: This is a defect. Both attributes (name & role) must not be mandatory but optional.

    Please not that we worked on relatedParty schema for the R19 and update it.  id & @referredType will be mandatory. A related class targets a reference so make sense to have this id and party is specialised in organization or individiual so better to indicate reference type.

    Thanks,​

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