Open APIs

 View Only
  • 1.  TMF 673 and the creation/modification of GeographicAddress

    TM Forum Member
    Posted Jul 26, 2021 12:57
    When I look through TMF673, it seems to be focused on two things: GeographicAddress validation & retrieval of existing GeographicAddress object. I don't see any operations for creating / updating / deleting an actual GeographicAddress from a system.

    Is there a different TMF specification that is used for creating / modifying the GeographicAddress?

    Two use cases that i have in mind:
    • Create a new GeographicAddress entry in the system that is used for address validation
    • An existing GeographicAddress entry needs to be updated because the official street name has changed


    ------------------------------
    Derek Jew
    AT&T Inc.
    ------------------------------


  • 2.  RE: TMF 673 and the creation/modification of GeographicAddress

    TM Forum Member
    Posted Jul 27, 2021 01:33
    Hi Derek

    It seems to me that the TMF position is that geographic addresses are treated as external data, e.g. from a GIS system (government database, Google Maps, whatever), and so their management is outside the scope of service provider activity. So, as you stated, you can search/retrieve from GIS, and validate against GIS.

    We can argue whether this is a correct view or not, and indeed within Amdocs we have extended this API to allow exactly the use case you mention. If you have access to the Open API project you could open a CR in JIRA as a suggestion for this to be added. Let's anyway hear what colleagues such as @Ludovic Robert and @Steve Harrop have to say.
    ​​

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



  • 3.  RE: TMF 673 and the creation/modification of GeographicAddress

    Posted Jul 28, 2021 04:06
    I think such a feature would be useful in the context of new sites and new network build as sometimes it takes a while for other sources of GIS data to catch up.

    ------------------------------
    Derrick Evans
    ------------------------------



  • 4.  RE: TMF 673 and the creation/modification of GeographicAddress

    TM Forum Member
    Posted Mar 01, 2022 09:51
    If we consider geographic address to be external data, there should be a way to subscribe and changes in the data like, updates on an address / delete of an address. Event described in TMF673 seems to be working for address validation lifecycle only
    Sachchit Sharma
    Analyst,
    Infosys


    ------------------------------
    Sachchit Sharma
    Infosys
    ------------------------------



  • 5.  RE: TMF 673 and the creation/modification of GeographicAddress

    TM Forum Member
    Posted Mar 02, 2022 01:51
    Hi Sachchit and all
    There is an open defect report on this, and correction is being made. I don't have visibility about when the correction will be approved and published.
    Members of the Open API project can see the report at https://projects.tmforum.org/jira/browse/AP-2719
    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.
    ------------------------------



  • 6.  RE: TMF 673 and the creation/modification of GeographicAddress

    TM Forum Member
    Posted Mar 02, 2022 04:14
    Hi all,

    For some reason TMF673 v4.0.0 has not documented all operations nor all events.
    The pattern of operations is however always the same:
    • HTTP POST: create entity
    • HTTP PATCH: modify entity
    • HTTP DELETE: delete entity
    In principle these atomic operations can always be added. However, and that is probably why the current TMF673 doesn't document these operation, address management is a complex process and higher level Task objects should be defined for common operations that potentially involve several addresses at a time.

    e.g.
    • changes of official streetnames
    • changes of adminstrative borders of cities, localities, provinces or even countries
    • urban developments with new streets and buildings
    On creation of the TMF673 these processes were considered out of scope and only address validation was considered in scope. In many organisations these updates are performed in GIS systems and data is exported from there. Usually these tasks will impact many addresses at a time which makes them more difficult to model and potentially heavily depend on the implementation.

    Because the operations were not defined also the notifications were not defined. But also here the standard pattern should apply.

    • GeographicAddressCreateEvent
    • GeographicAddressValueChangeEvent
    • GeographicAddressStateChangeEvent
    • GeographicAddressDeleteEvent
    • GeographicSubAddressCreateEvent
    • GeographicSubAddressValueChangeEvent
    • GeographicSubAddressStateChangeEvent
    • GeographicSubAddressDeleteEvent
    • GeographicAddressValidationCreateEvent
    • GeographicAddressValidationValueChangeEvent
    • GeographicAddressValidationStateChangeEvent (*)
    • GeographicAddressValidationDeleteEvent

    (*) already exist in current TMF673
    In my personal opinion the atomic operations and notifications should have been created even with the open questions remaining. But it is not difficult to create these extensions in your implementation using the existing patterns. This way your implementation will almost certainly remain compliant with the next version of TMF673.

    Regards


    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------