Open APIs

 View Only
Expand all | Collapse all

Service Provide Contact details in TMF641 serviceOrder schema

  • 1.  Service Provide Contact details in TMF641 serviceOrder schema

    Posted Feb 08, 2023 08:25
    Hi All,
    We are working on an OSS solution to cater B2C, B2B, and B2B2C businesses. We need to have the service Provide Contact details stored for each serviceOrder. For a B2C specific order, the service provider contact details would be the OSS solution owner(us). However for B2B and B2B2C, we need to store contact details of the service provider which serves the client.

    I need some suggestions about what should be the best fitted place to keep these details in service Order specification. For now, I believe, we can keep them in service Order table or we can keep them as order characteristics.

    Your suggestions would be much appreciated.

    ------------------------------
    Gaurav Sinha
    Infosys
    ------------------------------


  • 2.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    TM Forum Member
    Posted Feb 09, 2023 02:03

    Hi Gaurav,

    If I have to choose to keep the service provider details in service order table or as service characteristics, I will choose service characteristics. But I can recommend using Party or Related Party entity (or table) to persist such information. This will be more aligned with TMF Information model.



    ------------------------------
    Molay Dutta
    Solution Architect
    Prodapt Solutions Pvt. Ltd.
    ------------------------------



  • 3.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    TM Forum Member
    Posted Feb 09, 2023 02:47

    Hi,

    normally, the service provider is created and stored before it comes to an order. Therefore, the detailed data of the service provider need not to be submitted in each order again and again - instead, a reference on the service provider will be sufficient. Hence, it fits very neatly into the "relatedParty" concept, that is, adding it (within TMF641 service order) to the array of related Parties with a certain role like "SERVICE_PROVIDER":

        "relatedParty": [
            {
                "id""my_ID_of_Service_Provider_xyz",
                "role""SERVICE_PROVIDER"
            }
        ]
    BR Thomas


    ------------------------------
    Thomas Dupré
    Deutsche Telekom AG
    ------------------------------



  • 4.  RE: Service Provide Contact details in TMF641 serviceOrder schema
    Best Answer

    TM Forum Member
    Posted Feb 09, 2023 07:45

    Hi,
    I noticed that with v5 the TMF641 will finally receive a new "orderCharacteristic"-array. If you do not have a system available which supports the PartyMgmt-API you could also extend the current TMF641v4 with the new approach from TMF641v5. That makes upgrading the API easier for you if you ever want to go from v4 to v5. Another approach would be to extend the TMF641 to allow RelatedParties as a value instead of a Reference.

    Personally, I would advise against carrying such party information as service characteristics inside the ServiceOrder.

    Regards,
    Jan



    ------------------------------
    Jan Lemmermann
    OSS Lead Architect
    EWE TEL GmbH
    ------------------------------



  • 5.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    Posted Feb 13, 2023 08:33

    Hello Gaurav,

    This is a real world problem that you have identified.

    Service Order is not the best place to keep all the data you mentioned. Please consider using related party which provides a reference.

    Regards,

    Jag



    ------------------------------
    Jag Baddukonda
    CSG
    ------------------------------



  • 6.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    TM Forum Member
    Posted Feb 20, 2023 10:15

    Firstly, I suggest to distinguish between the storage on the one hand and the external API representation for integration on the other hand.

    From a storage perspective, you would typically persist your contacts in a separate document or table, and have a reference or foreign key to them from your stored service order. But for implementation reasons you might decide to denormalize the storage and keep the contact details as embedded.

    From an API perspective, in many cases it makes sense to keep in one entity only a reference to the separately managed entity, e.g. RelatedParty. The snag here is that this creates a rather chatty interface which might make things tricky for remote interactions e.g. between partners. There's a lot to be said for having the EntityRefOrValue pattern, which gives you the flexibility to decide whether to embed the full entity contents (larger payload, but only one call) or to use reference (smaller payload, but you need an additional call to retrieve the referred entity). We're increasingly using RefOrValue in the API schemas.

    The challenge is that specifically for RelatedParty it is more difficult to do this since RelatedParty doesn't correspond to a single entity. I believe that in v5 there is work in progress to allow reforvalue semantics for party or party role, but it's not yet ready for general use. Watch this space :)



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 7.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    TM Forum Member
    Posted Feb 20, 2023 13:22

    Hey @Jonathan Goldberg ,

    This is something i've never been quite able to wrap my head around in TMF with the ReforValue and polymophic types. The schema for a RelatedParty container in v4 of TMF641 is decribed as such

            "RelatedParty": {
                "type": "object",
                "description": "Related Party reference. A related party defines party or party role linked to a specific entity.",
                "required": [
                    "@referredType",
                    "id",
                    "@type"
                ],
                "properties": {
                    "id": {
                        "type": "string",
                        "description": "unique identifier"
                    },
                    "href": {
                        "type": "string",
                        "format": "uri",
                        "description": "Hyperlink reference"
                    },
                    "name": {
                        "type": "string",
                        "description": "Name of the related entity."
                    },
                    "role": {
                        "type": "string",
                        "description": "Role played by the related party"
                    },
                    "@baseType": {
                        "type": "string",
                        "description": "When sub-classing, this defines the super-class"
                    },
                    "@schemaLocation": {
                        "type": "string",
                        "format": "uri",
                        "description": "A URI to a JSON-Schema file that defines additional attributes and relationships"
                    },
                    "@type": {
                        "type": "string",
                        "description": "When sub-classing, this defines the sub-class Extensible name"
                    },
                    "@referredType": {
                        "type": "string",
                        "description": "The actual type of the target instance when needed for disambiguation."
                    }
                }
            }

    So arguably for each related party container that my client wishes to pass they could do something like the following (without us changing the 641 swagger) and just specify that @type is Indivdual so the server can expect to find all the attributes that an Indivdual can contain. Probably me and my understanding of the polymorphic approach in TMF but i believed that the polymorpic extenstions do not get included in the swagger so its quite reasonable for the server to receive a request with an @type where the schema is defined 'elsewhere'

    The other thought i had was that unlike most of the objects in TMF the name of this type in TMF641 is 'RelatedParty' and not 'RelatedPartyRef' (like for example EntityRef) , possibly just an inconsistency?

    "relatedParty": [
    {
    "role": "maincontact",
    "fullName": "Bob Smith",
    "@type": "Indivdual",
    "@baseType: "RelatedParty"
    }
    
    


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



  • 8.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    TM Forum Member
    Posted Feb 20, 2023 14:43

    It's complicated. RelatedParty is a shortcut for a reference to either a Party or a PartyRole. I'm not sure why it was introduced, it's been around for a very long time. These of course are not interchangeable, so the polymorphic thing won't work.

    Like I said, in v5 I believe they are solving this, I'll be wiser in a week or two when the new foundational schemas are released internally to the Open API team.



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 9.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    TM Forum Member
    Posted Feb 21, 2023 06:35

    Hi thanks @Jonathan Goldberg for you contribution,

    Where is it you go to see the early releases of the v5 open apis, i am a member of the Open API team project but wasnt sure how the notifications worked for when a draft was ready?

    OK, interesting on the Party Role, I didnt quite get the use case around attaching a link to a role?

    In terms of the polymorphism whilst i understand that the container was intended as just a reference and therefore use of it in this way would be 'not as intended' but I'm not sure why it wouldnt work? In other TMF containers which are 'RefOrValue' containers they dont have all of the sub class attributes in the swagger interface and my understanding of that was that the client when posting a resource by value specified the @type setting the sub class name which 'gave it licence' to also pass the sub class attributes and the sever would understand this by using the value of @type/@basetype

    Like with RelatedPlaceRefOrValue even if i had used a polymorphic approach and implemented my own extended sub class i wouldnt add the attributes it actually contains to this container definition in the TMF641 swagger.



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



  • 10.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    TM Forum Member
    Posted Feb 21, 2023 08:58

    The v5 Open APIs are released as beta on the early access table here: https://projects.tmforum.org/wiki/pages/viewpage.action

    To see the schemas in development you'll need access to the project GitHub, we can discuss that privately.

    I see what you mean about RelatedPlaceRefOrValue, but bear in mind that GeoAddress, GeoLocation, and GeoSite are all conceptual subclasses of Place. Wheareas Party and PartyRole do not have a common base class.



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 11.  RE: Service Provide Contact details in TMF641 serviceOrder schema

    TM Forum Member
    Posted Feb 21, 2023 04:50

    Ich kann damit nichts anfangen.

    Was soll diese Mail?