Process to archive old eAutomate data
Jump to a specific section by clicking a link
Overview | Samples | Variables | Alert Functionality | Best Practices & Tips | Related Alerts
Overview
Overview
For larger dealers who have been on eAutomate for a long time, we often see performance issues, and currently there is no native archiving in eAutomate.
This process would archive data older than X years, our recommendation would be 5 years, then make it available in a read only database.
As CEOJuice attempts to solve some very labor intensive problems like this, we can no longer offer to do them for free. This process would be an add-on option, not covered under the standard monthly fee. This will be a one time charge not determined yet (probably $2000).
Subscribing to this process during the development stage, only registers your interest in CEOJuice to build it. It does not automatically approve any additional payment.
Below is a proposal we have for the Purge/Archive utility:
The key goals of the utility as we understand it are:
- Eliminate old/no longer relevant data from working database.
- Reduce the working database size.
- Accounting/Inventory etc should remain valid and seamless in terms of before/after reporting.
- Retain "reference" database for historic data needs.
- We would tackle this project in stages.
Stage one: The preliminary design concept. Review the relationship structures for e-automate tables, giving a listing/report for those. We currently envision a data-driven design, so this relationship data would end up feeding into the meta-data, but it also informs the scope of work. We envision we will further investigate and report on two similar but different approaches, which both arrive at the same output database. Approach A: Copy database, prune/summarize unwanted records (subtractive approach). Approach B: Copy only wanted records to new database, summarize starting balances/etc (additive approach). In both cases we end up with a new database that has only the desired active records, all supporting (lists and codes) records, and only summary records for the pruned (or not included) data. We envision pros and cons for both approaches, but we will dive a little deeper, provide additional thoughts and possibly make a recommendation.
We estimate that doing this review and providing the preliminary design deliverables could take between 30-50 hours. We think it would take us 2-4 Calendar weeks.
After discussing the preliminary design with CEOJuice and making any needed changes, we'd begin stage two. We don't have cost estimates or timelines for stages two, three, or four, but we anticipate providing more direction and sizing information as part of the stage one deliverables, so we'd have additional cost information before moving on.
Stage two: To implement a limited proof of concept. We envision using a smaller database such as "Mark" and selecting a specified transaction type to process -- probably something on the "simpler" side. This way we would be moving forward carefully, limiting costs to a minimum as we determine the path forward.
Stage three: After successful stages one and two, we would implement the full solution for multiple transaction types on a more realistic database, probably a copy of a customer database that would authorize our use of it. Eventually the customer may be the guinea pig and walk through it on their live database as we stand ready to help if needed.
Stage four would involve providing some amount of the necessary ongoing service to address bugs or make additional changes as-needed when CEOJuice rolls the solution out to more customers. We'll need to discuss how CEOJuice can best continue support as we get to that.
Run Schedule: Unknown
Type of Output: Data Push
* * *
Sample
Sample
Not Available at this time
* * *
Variables
Variables
Not Available at this time
* * *
Alert Functionality
Alert Functionality
Not Available at this time
* * *
Best Practices & Tips
Best Practices & Tips
Not Available at this time
* * *
Related Alerts
Related Alerts
Not Available at this time
* * *
0 Comments