Table of Contents
Implementation Details
Various common aspects of implementation are suggested and described below.
ETL
Most likely it will be necessary to ETL all available and relevant data from other systems. This will need to happen on a regular basis (typically nightly) for as long as the integration with or migration from the other system(s) lasts.
The ETL process will necessarily be quite custom for each organization, although it's possible that some common back-ends might be "supported" somewhat over time. Most of the objects will require a custom "key" (mapped to the class via a Rattail extension) for the sake of tracking the object between ETL jobs. For example, since our other system is CAM32, I'll map a field called cam32_key (with a unique constraint) to the Product class. Prior to creating a new Product within Rattail during the ETL job, I'll first search Rattail for a Product which contains the cam32_key in question. If found then that Product will be updated; if not then a new one is created and its cam32_key is assigned.
Customers
When ETLing new customer data, the transformation step could be somewhat heavier. Since Rattail supports associating more than one Person with a Customer, and since most other systems probably assume a "Customer" is a single "Person", the process will be to:
- Create a Person.
- Attach contact info to the Person.
- Attach the Person to a new Customer.
- Assign the custom key on the Customer for object tracking.
On the other hand, the other system might also have the notion that a Customer may include more than one Person, in which case the mapping should be more or less direct.
Prices
The Price class will not need a custom key field, as its uniqueness may be determined by its product, level, and amount attributes. When a price change for a previously-ETLed Product occurs between consecutive ETL jobs, the old "current" Price.expires is set to the current date, and a new Price is created with expires set to None, so as to make it current.