Acumatica Snapshots can be tricky, but they are extremely useful. If you are unfamiliar with the feature, Acumatica’s snapshot system is an amazing ERP feature that lets the customer export and import a company’s data into/from a zip file full of files that represent the data of SQL tables in the ERP. With Snapshots, you can create a copy instance of an Acumatica site by company. It’s an incredibly powerful tool that gives you a lot of power over your data. Customers can create copies of their sites for testing, experimenting, or for historical analysis.
I’ve been using snapshots to troubleshoot customer issues since I started working with the product in 2013. No longer did I have to go through the nerve-wracking process of troubleshooting an issue in a customer’s production environment. I didn’t need to get a customer to allow me access to their system so that I could poke around, perhaps send a SQL query via the chat window, and desperately try to infer the issue in the time allotted. With snapshots I can replicate part of a customer’s system so I can see the problem firsthand, step through the code, and analyze the database. It is amazing and one of my favorite features of the Acumatica Platform.
Unfortunately, snapshots are one of those excellent technologies that go widely misunderstood or not understood at all. Snapshot creation copies the data from SQL tables for a particular company and saves it in the same table. If you looked into one of your SQL tables, you would see that every piece of data in your database has a CompanyID attached to it. This field dictates what company the data belongs to. When you create a snapshot of your company’s data, that row and every row like it is copied to the same table with a Companyid that indicates that it is part of a snapshot. That data will sit there until you delete the snapshot out of the ‘Tenant’s page. Now, I have been assured that this extra data should not affect performance, but I still cringe when I see a customer with 10 different snapshots lingering in the database.
Snapshots do have their limitations. As databases get larger and larger it becomes difficult or impossible to work with snapshots. I’ve had customers tell me that they can’t create snapshots because their database is too big. This is undoubtedly true in many cases, but I can’t help thinking that if people understood snapshots better that work arounds could be found. You see the Acumatica snapshot system cleverly runs on snapshot definitions which dictate what tables to export and even gives you the ability to dictate what data within the table to export.
My product, SPS Commerce for EDI, has shipped with its own custom snapshot definitions for years. When selecting configuration options for snapshot creation with our product installed, customers would see a mirror SPS definition for each Acumatica snapshot definition. For instance, you might choose a ‘Full’ type snapshot or you could choose one called ‘Full – SPS’. I did that because there is some SPS information that shouldn’t be shared between instances of Acumatica and to keep our transactional data out of the snapshot when the user just wants to copy things like Settings. The setting you choose here is very important and I know that it can be easy to just choose the ‘Full’ option and move on. However, people should be careful to pick a snapshot type that is best for their needs. In my experience more data than expected or desired is included. All the system emails, Audit data, and login records for instance can turn a snapshot into 10gigs when it should have been 2. The system is an opaque one and the only way to control what tables are included is by setting up a flat file in a particular directory. The confusing thing for our users is that I had created snapshot definitions for their use in copying information between instances and not for troubleshooting.
This brings me to the updates to the snapshot system available in 24R2. Acumatica has updated the snapshot system so that you can seamlessly add to the standard definitions. Now each standard definition has a folder beside it and if you put a snapshot definition file in the folder for a particular definition, then the added code can be merged with the standard on execution. In other words, if I put a definition in the ‘Full’ folder, every time a ‘Full’ snapshot was created my file would be merged with the standard. Now my customers won’t have to choose the ‘Full – SPS’ snapshot definition they can just choose Full without worrying about SPS causing an issue with the new instance. Furthermore, I now feel comfortable adding a new snapshot definition into the mix that is just for troubleshooting by SPS. This snapshot definition can be lean and mean and only include the things I’m concerned with. Two very different business purposes can be accomplished with a much smaller footprint for the customer.
Happy Coding!
