Hi Sumit
We often try to avoid bi-directional relationships in the Open API model, and also relationships from owning to dependent. Consider what happens, for example, if I model an explicit relationship from Customer to Order (or to Product). It means that every time I create an Order (or Product) for a customer, I need to update Customer as well, to update the list of owned Orders (or Products). Whereas if I only model the reverse relationship (from Order or Product to Customer), I don't need to make this.
Of course this doesn't prevent me from getting all the Orders (or Products) owned by the customer, it will be by a query ?relatedParty.ID=<customerID> - of course the persistence layer needs to be indexed to support such queries.
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.
------------------------------
Original Message:
Sent: Jun 27, 2024 02:01
From: sumit nanda
Subject: Order ID reference in Party and Account Management API's
During implementation Party Management and Account Management API, we came across a possible use case storing and having scan capabilities on these entities based on Order ID under which this Party and account are getting created via Order orchestrator. Need valuable suggestions if this is an established practice or should be avoided
------------------------------
sumit nanda
Bharti Airtel Ltd
------------------------------