Creation of BillingAccountContact for "Bill to" and "Sold to" contacts
Problem
Related to #5661 (closed)
The "Sold to" and "Bill to" contacts are Zuora objects used in many places throughout CustomersDot, espcially the "Sold to" contact which is used when processing Subscriptions for example. As we rely on these objects, we end up needing to make multiple API calls to retrieve these objects which has become a performance bottleneck.
Given their importance and how often we need these Zuora contact objects, having them persisted in our database and synced with their remote Zuora counterparts would be beneficial to the overall performance of our application.
Proposal
Following the introduction of BillingAccount-related classes and their implementation, this issue lists the tasks our team needs to undertake in order to be able to access the "Sold to" and "Bill to" object locally for a given BillingAccount object. This will warrant the introduction of a new model called BillingAccountContact.
Having BillingAccountContact objects locally not only will allow us to reduce Zuora::Contact API calls but these new objects will become SSOT for customer contact details. This means that we'll also be shifting away from fetching contact details from Customer objects.
The checklist below proposes an implementation plan. This list doesn't have match its related pace of development (ie. items below can be lumped together, other items could be broken down further).
Result
Whenever a Zuora account gets its Sold to or Bill to contacts updated, this change is now synced successfully to CustomersDot via a Zuora callout.
BillingAccount objects now pull Bill to and Sold to data from the database and not from Zuora any longer.
We now get contact information (eg. work_email, postal code, city, country, etc) from BillingAccountContact objects and not from Customer objects any longer.
Next step
The removal of the feature flag mentioned above, to definitely rely on local BillingAccountContact objects instead of fetching Zuora::Contact objects.