Hi Jonathan,
Regarding TMF669 and an example you gave.
"There will be a PartyRole with name John Doe and role Contact, and the engagedParty for this PartyRole will be the Individual John Doe"
In the previous version of TMF669, R18, I guess this example would be represented like this:
{
"@type": "PartyRole",
"id": "123",
"name": "John Doe",
"engagedParty": {
"@referredType": "Individual",
"id": "42",
"name": "John Doe"
},
"type": {
"name": "Contact"
}
}
When looking at the current R19 production specification of TMF669, there seem to be a few changes introduced compared to R18.
- In R19, there is no longer a type attribute (RoleTypeRef)
- In R19, the engagedParty is now a RelatedParty instead of a PartyRef.
Where should the role value (Contact) be now be stored in the PartyRole resource? There is no type/role attribute anymore. Since the engagedParty type has been changed from PartyRef to RelatedParty, it could be populated there, but it does not seem quite right:
{
"@type": "PartyRole",
"id": "123",
"name": "John Doe",
"engagedParty": {
"@referredType": "Individual",
"id": "42",
"name": "John Doe",
"role": "Contact"
}
}
The TMF669 R19 specification states that name and roleType are mandatory attributes when creating a PartyRole. The roleType attribute is not mentioned anywhere else in the document, including the resource model, and it's not defined in the swagger file either nor mentioned in the conformance profile document.
Please advise. Thank you.
------------------------------
Paul Austdal
Telia Company
------------------------------
Original Message:
Sent: Sep 11, 2019 07:03
From: Jonathan Goldberg
Subject: "role" in relatedParty
Related Party is intended to provide a reference to either a Party (RelatedParty.role will be blank) or a PartyRole (RelatedParty.role will have the name of the role). Related Party is not in itself a managed entity.
If a Party plays multiple roles, there will be a PartyRole (or concrete subclass) for each such role. Suppose John Doe works for H.A.L computers as the communications expert, and H.A.L. uses NXT Communications for its business wireline services. John Doe also has personal cellphone service from NXT for himself and his daughter.
So:
- There will be an Individual (subclass of Party) with first name John, last name Doe
- There will be an Organization (subclass of Party) with name H.A.L.
- There will be a Customer (subclass of PartyRole) with name John Doe, and the engagedParty for this Customer will be the Individual John Doe
- There will be a Customer (subclass of PartyRole) with name H.A.L., and the engagedParty for this Customer will be the Organization H.A.L.
- There will be a PartyRole with name John Doe and role Contact, and the engagedParty for this PartyRole will be the Individual John Doe
- The Customer H.A.L. will have a RelatedParty that points to the John Doe PartyRole
Hope this helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Original Message:
Sent: Sep 11, 2019 06:41
From: Shibin CK
Subject: "role" in relatedParty
Hi All,
The role field in relatedParty is usually a String. What should be done if a person is serving more than one role?. There are three approaches I can think of. Which one of these is better?
1. Replicate the data
{ id: P1 name: John relatedParty: [ { role: "Primary Contact" id: P2 name: "George" @referredType: Individual }, { role: "Father" id: P2 name: "George" @referredType: Individual } ]}
2. Change data type of role from String to an Array
{ id: P1 name: John relatedParty: [ { role: ["Primary Contact", "Father"] id: P2 name: "George" @referredType: Individual } ]}
3. Encode the information in the role String
{ id: P1 name: John relatedParty: [ { role: "Primary Contact,Father" id: P2 name: "George" @referredType: Individual } ]}
------------------------------
Shibin CK
Tecnotree
------------------------------