Open APIs

 View Only
  • 1.  TMF 673 Geographic Address Management - Polymorphic Extension

    Posted Mar 29, 2023 00:45

    Hi Team,

    I have a use case of adapting to TMF 673. I am looking for best way to implement polymorphic extension of the response model. 

    I am planning to implement TMF API endpoint to fetch address based on address identifier. According to address identifier type, the API internally connects with different address data providers and construct the response. 

    Now the problem is we have different property names returned by different providers like 

    Provider A:

    OrganisationName, POBoxNumber 

    Provider B: 

    organisation, poBox 

    I don't want to change these property names. I want to implement polymorphic extension like

    TMF API response schema:

    1. Can have properties from all providers or
    2. Can use @type to specify a response model schema

    What is the best approach? 



    ------------------------------
    SudheerKumar Gujjeli
    TO BE VERIFIED
    ------------------------------



  • 2.  RE: TMF 673 Geographic Address Management - Polymorphic Extension

    Posted Mar 30, 2023 06:09

    I am awaiting support on this. Could you please help me.



    ------------------------------
    SudheerKumar Gujjeli
    TO BE VERIFIED
    ------------------------------



  • 3.  RE: TMF 673 Geographic Address Management - Polymorphic Extension

    TM Forum Member
    Posted Mar 30, 2023 14:45

    Hi Sudheer

    You're probably not going to like my answer, but here goes anyway.

    Your implementation of this API is effectively as a bridge to multiple underlying (legacy) providers of address functionality. The whole purpose of bridges or adapters like this is to isolate the consumers from the complexity of the legacy, and to present a unified face to the consumers. Therefore your implementation should expose addresses only according to the standardized address model reflected in TMF637. Internally, you will, yes, map between the various different legacy representation.

    It would incorrect, in my opinion, to use the extension mechanism to have multiple attributes in the model that have the same semantic meaning - you may as well forget the API altogether and have your consumers directly access the legacy systems.

    Hope it helps



    ------------------------------
    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.
    ------------------------------



  • 4.  RE: TMF 673 Geographic Address Management - Polymorphic Extension

    TM Forum Member
    Posted May 19, 2023 07:38

    Hey @Jonathan Goldberg 

    I wouldn't actually call this is a bridge to legacy address sources rather its more appropriate to think of it as a gateway to multiple supplier address data sources to facilitate:-

    1. retrieval of their proprietary 'address keys' that must be used when placing orders for fixed line access (with say postcode/building number)
    2. retrieval of their representation of an address based on one of their proprietary address keys
           - This means that our business can assess if the key in the background behind the address data is sufficiently matching to a customer provided address

    So what this means is that in the context of TMF673 we don't really have an "id" because there is no common identifier across these address sources. In the UK access suppliers whilst using UPRN (UK Ordnance survey identifier) they will also use their own identifiers for things not covered by that data set (i.e. traffic light).

    Whilst I do agree that consolidation of this representation of one suppliers address (along with the others that we also have) into a consolidated model fits with the principles of TMF and would be best practice I don't actually see how its possible given the diversity in the data and the difference in the models.

    Have you any suggestions in terms of how this could possibly be mapped or is it just that either TMF/673 does not meet this use case?






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



  • 5.  RE: TMF 673 Geographic Address Management - Polymorphic Extension

    TM Forum Member
    Posted May 21, 2023 06:19

    Thanks David for your feedback

    There's been a lot of discussion on another threads about extending the address model (https://engage.tmforum.org/discussion/tmf673-and-predirectional-street-components, https://engage.tmforum.org/communities/community-home/digestviewer/viewthread?GroupId=31&MessageKey=1f2940c2-7ca0-462d-bd4c-ce3bcae3893b&CommunityKey=d543b8ba-9d3a-4121-85ce-5b68e6c31ce5)

    I repeat here that the TMF base model cannot be expected to answer all possible use cases in every jurisdiction worldwide. Each locality can freely extend the model to meet local standards and practices. Having said that, you would need to decide, in the case of multiple formats from address sources, whether you want to create a unified model over that (and probably include a persistence layer to give a single set of IDs), or to have disparate extension for each format.

    Good luck



    ------------------------------
    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.
    ------------------------------