TM Forum Community

 View Only
  • 1.  API implementation(s) without dedicated database(s)

    Posted Nov 10, 2023 10:24

    Hello,

    We are implementing TMF Open APIs with no dedicated databases for the different Entity models, and with no ownership of the source data. Instead we are getting all the source data from a number of different backend services. We were wondering if this is a common practice? Are there any known issues with this approach?


    #General

    ------------------------------
    Joni Parpala
    Digia Plc
    ------------------------------


  • 2.  RE: API implementation(s) without dedicated database(s)

    TM Forum Member
    Posted Nov 12, 2023 03:11

    Firstly, good luck!

    It would seem to be a reasonable approach that can allow you to do modernization in phases.

    Are you implementing only retrieve/search (GET), or also data management (POST/PATCH/DELETE)?

    It's very much a case-by-case basis, since you'll be doing mapping between the Open API contract (model and behavior) and the underlying backend. Depending on backend capabilities you might need to orchestrate invocations into multiple backend API operations to achieve a single Open API operation. Especially if you are writing data, you'll need to consider how to deal with partial success against multiple backends (first operation succeeded but second operation failed).



    ------------------------------
    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: API implementation(s) without dedicated database(s)

    Posted Nov 13, 2023 01:10

    Thank you! At the moment we are mostly implementing retrieval operations (GET), but data management will also be handled in the future. For now we have been lucky, as each Open API has only a single "master backend service", so partial success/failure hasn't been a concern. But it might be a different case for future APIs.



    ------------------------------
    Joni Parpala
    Digia Plc
    ------------------------------