I just need to get this off my chest – so bear with me.
First off, I’ve been doing sysadmin work for scores of years now, and the idea of backups, business continuity, and “bad guys” isn’t new. However, this week it was brought to a new and interesting head for one small business.
Rewind the clock two years and we were in the conversation with this business about where they host their “golden nuggets” of their business, what servers did what, where were the users, how did the backups fare, state of malware, web filtering protection, etc. You know, all the “normal” stuff any qualified IT provider would ask a prospective customer. “We’re fine” was the answer – they had an in-house IT guru watching all that stuff. However, they did make a (wise) decision to host their ERP solution with us.
Last week, our monitoring went suspiciously quiet, it looked like the company went on vacation, or they had fallen asleep at the keyboard. I reached out to the company, and was informed that they had been the victim of the latest ransomware attack, and all their documents were encrypted and unusable. Thankfully, since they were hosting their ERP system with us, that was safe from the attack. All their ERP data was secure but everything else they controlled was locked. Backups proved unreliable or inaccessible, so the ransom was paid. The company got lucky and the recovery key worked and they got their documents back. What they didn’t get back was Active Directory. Ouch! Nobody could login, even though their documents were back on a server, nobody could access them.
A week later, a new domain, and new profiles on everyone’s desktop, new shares, new permissions, and they were back up and running. After everything, the company is back to doing business, but it could have been a much worse situation. A critical note: the ERP system was never at risk and no ERP data was lost since that was safely stored elsewhere.
Moral of the story:
- Test your backups. Not just documents, but the whole server. How long does it take to get it back? It should not be more than a few hours.
- Just because you can restore files doesn’t mean you can go out, buy a new server and restore your existing workload onto a new server.
- If you can’t live without it, and you don’t have the in-house expertise to manage it – outsource it! Let the pros handle the critical IT while you do what you do best: making essential product and making your business grow.
Contact Us to learn whether Hosting is right for your company.
Learn more about EstesGroup’s EstesCloud Hosted ERP here…
An ERP system is like a person or a house: without integrity, you can’t put your trust in it.
One of the great things about Epicor ERP is its openness to customization. That feature can also be a source of trouble. It’s all in how you use the power.
Strictly speaking, you can’t directly modify Epicor’s software without a special Software Development Kit. Changing the base software opens the proverbial can of worms and has lots of ramifications we won’t discuss here, so what we’ll be talking about is the traditional “customization layer” the 99% uses.
Terms to Remember:
Business Object (BO). Data manipulation is governed by Business Objects. You hand the BO a dataset and let it figure out how to care for the data’s integrity, rather than writing directly to all the tables in the dataset.
There is a “Part” business object, for instance, that governs the Part table and its dependent tables. It won’t let you change the base unit of measure for a part if there is any activity like transactions, open orders, or open job materials for a particular part so you don’t, for example, make an material’s on-hand quantity of 10 Each suddenly 10 Gallons, or orphan transaction history by deleting the part.
Embedded Customization. Also known as a “screen customization” or just “customization” (client side) that sits on top of a form such as Part Maintenance. You can add a new field on the screen and attach it to a data source or use C# code to add and modify events happening inside the form to suit your business practices.
Personalization. Similar to the customization, the personalization is a user-made modification that sits on top of the form/screen customization (that sits on the base software). They’re mostly used to modify field placement, grid layout, etc. to let the user see and arrange things in a way useful to them.
BPM. Business Process Management Method and Data Directives (server side) modify data actions triggered by events on the form. They are typically accessed in record updates, new record creation, and so on. The Part BO has many methods like add, update, and delete, so you can say, “when this thing happens to the data also do this other thing,” or “when we create a new record add this thing to it.”
In generic terms, a typical Epicor ERP session works something like this:
- An Epicor form loads with standard (out of the box) data views, operations, etc.
- Epicor then looks for a screen customization and applies it on top of the standard form.
- Epicor looks for a personalization for the current user to layer over the form and over the customization, if any.
- The form displays and allows the user to do things.
- BPM – Method and Data Directives (server side) hang around and wait for the appropriate signal to take action, say, when you click the save button.
This is what I’m calling the customization layer–the places Epicor gives us to add in/change functionality.
So, where’s the danger? Here’s an example.
When we store data changes through Epicor’s Business Objects, we trust the BO to keep us out of bad trouble. But the data is stored in a SQL Server database, and it’s possible to go outside of Epicor and write directly to that part table or delete records via SQL commands without checking any dependencies. It can be much faster, in the same way ignoring the speed limit in your car can get you home sooner. Maybe you won’t corrupt your data. Maybe you’ll make that turn on four wheels.
There are occasions and circumstances when it’s okay to skirt the rules.
Rarely, something gets stuck and the BO won’t let you correct it, so a SQL fix is in order. Since directly using SQL commands on your database can invalidate your Epicor service agreement, I’d recommend doing it with one of Epicor’s folks on the phone.
Some simple tables and some fields don’t have dependencies that the BO cares about. It’s possible to take a more direct approach within Epicor—when you know what those are.
This topic comes up periodically when we developers talk amongst ourselves. In our company, the standard is to operate from within the Business Object unless there’s a compelling reason for something different.
Questions about Epicor ERP Customizations? Are you planning a customization project and have questions for the author? Let us know.