I’m typing up some step-by-step instructions for our ERP team (about 4 “super” users) on how to add Extended UD Tables and Fields to E10.1. I’m to the part where I’m instructing them on how to go into the Admin Console and Regenerate the Data Model and Recycle the AppServer but I’m getting nervous thinking about the havoc that could be wreaked even accidentally…
I’m thinking about just putting in that step to call me so that I can do that process myself… I guess the process wouldn’t need to be run THAT often.
Just thinking out loud here but Is there a way to program a button on the Extended UD Table Maintenance Form to run the Regenerate Data Model and maybe even the Recycle AppServers process to complete the ExtUDTable setup that I could only expose to those 4 users? Or can I setup a script for these processes that they could run without going into the Admin Console or that I could schedule? Does anyone have any thoughts or suggestions on how to do something like this?
It didn’t seem to us as if the Regenerate Data Model nor the Recycling of the AppServer caused any Users or Processes to get disconnected (but we only had a few people in the system during that time) so it would seem harmless if Epicor would just pull this functionality into the Extended UD Table Maintenance under maybe the Actions menu and allow this process to be run ONLY when the Tables and Data Model become out of sync. Or are there other ramifications that I’m not thinking of by allowing the users to run this process on their own from within E10?
Thank you for any thoughts or suggestions you might have on this,
-Heather
I’m not an expert, but this will “disconnect” them temporarily. It will reconnect shortly and automatically, so if they aren’t actively using epicor, they may not notice, but they could lose work if they are in the middle of something.
I would recommend making the regen steps a locked down process. This can and will cause problems and I typically never recommend running this during peak activity or would recommend doing it only during a maintenance window for production. You can make this an automated process but I would start simple just to get an established process with your users before automating.
I agree with Dan. I noticed that when I was in-between the UD Maintenance and the regen (in 10.0.700 anyway) that other users started throwing errors in the affected area until the regen was done (fortunately, this was in the Test environment). So, I lean toward locking down this process and funnel the requests through a few people who will do the work during a maintenance window.
My company is a 24/7/365 operation and so there is never a time when people aren’t using the system. I always used to publish a time when I was going to do UD maintenance, but people wouldn’t log out and tried to continue working anyway.
I’ve found that as long as you run the data regen and recycle app pool as soon as possible after making changes on the Extended UD Table screen then it doesn’t actually affect users. The only thing you’ll notice is after the app pool reset, there is a bit of a pause of 20 seconds or so whilst the pool re-caches everything into memory.
I would say try it during a quiet bit, see if you find the same results.
@markdamen A lot of this depends on data volume and user volume. If you have 10 - 20 users and adding to a small table, then sure you can perhaps get away with this. Now go to a 500 user, large task processing, and a part master with hundreds of thousands of record and extend to part_ud, you will see a large problem. Best practices are the message here and most companies, regardless of being 24/7/365, typically try to implement IT best practices, which is to have a monthly, at a minimum, maintenance window. Keeping up with security (Windows patches) typically is a big driver behind this.
Thanks to you all for the responses and sharing your experiences and thoughts!
@Mark_Wonsil, I can see how there could be issues with those working in that affected area while the Regen was running. I think for that step in my instructions to my users I’ll just ask that the user who does anything in Extended UD Table Maintenance contact me to run the Regen\AppServer Recycle processes in a scheduled maintenance window. Thank you!
But as previously stated on this post, you can’t do the Extended UD Table Maintenance changes and then wait hours or days for a maintenance window – if you leave things in that in-between state then that definitely causes problems and I’ve seen that first hand. Users start getting errors about fields not specified or similar.
First, I assume you have a single app server and a single app pool (no web garden) since that topic did not come up. If you have those, ignore the rest of this. Things get more complicated in a farm and I deal with that on our SaaS systems. We are looking at easing that admin burden for our own selfish needs so you all will benefit as we find the correct balance.
Gory details…
ERP 10 caches a ton of things - queries, in transaction results and the assemblies holding the biz logic. This is not normal IIS behavior for a variety of reasons. Change the web.config? IIS reboots and your 4 hour MRP run just got cancelled. Change a BPM and we silently do a build of ‘MyBPM.dll’ in the background and cache it (with a GUID stamped on it to allow you to have a bunch of the same dll in memory at the same time and we vector to the most current). Reminder - in dotNet, you cannot ‘unload’ a dll. Once you spin it up, it lives forever. It’s not like a class you can dispose.
The data model is one of these dlls we cache. We have looked at the ability to surgically refresh the cache for the data model like a BPM. The combination of the data model just being so large and so many classes running around in memory to update to the latest caused too many problems trying to update it in place so - the tear it all down and do an IIS Reset / app pool restart instead. Some day we might get that plumbed but for now the stability is more important than the risk so the reset approach.
Next, what a client sees happening it based on their ‘Session’ on the server. This holds which company they are looking at, site, workstation, language, etc. That information is stored in the database and cached in memory. If you kill off the server, no biggie, the next time the user hits the server the app server caches up the session again from the db and they are fine. Try going into Tip or Sales Order and search by typing in a valid record. Now turn off IIS. Do the query again. server not responding. Leave that dialog alone, start IIS and then pop goes ERP 10 and the query results are displayed. No loss of continuity.
What IS lost are long running processes. If you have a Posting Engine, MRP, large report, anything that takes some time crunching things then those all get reset to their last ‘increment’. Unfortunately, many of our large processes have not been evolved over to that model so start from square 0 on a reset. That’s something we are looking at but no roadmap or announcements today.
Lastly (really firstly) you need to be concerned about security. If you plop a button on the UD Maintenance form, what is the identity of the user that will hit the IIS app server and tell it to reboot? How you manage the security access to an app server is very important. I assume you don’t want just anyone able to hit IIS and do admin functions. That’s the thing postings to HaveIBeenPwned.com are made of. If you are going down that route, please think thru the security implications.
I guess the process wouldn’t need to be run THAT often.