We’re in the process of updating to Kinetic and one of my tasks is to identify what customisations are still in use. We have a pile of BPMs and BAQs that have accumulated over the years, written both in-house by staff who have come and gone, as well as by consultants.
I’ve “inherited” (read: I didn’t step back quick enough!) the role of managing and maintaining these items and (like a lot of companies, I suspect) having someone made responsible for these things has brought to our attention just how poorly they’ve been administered to date!
I’ve written a BPM that logs the use of our BAQs and writes time, date, BAQ name and user into a UD table. This is working well and helping us to build an idea of which BAQs are likely to be redundant. Given enough time I’m confident we’ll be able to identify which BAQs can be cleansed from the system.
BPMs are a whole other kettle of fish. Is there a similar way to monitor which BPMs are used? I’m guessing I won’t be able to trigger a BPM to fire when a BPM is used? I can trace my own BPM use through tracing and server events but is there a way to do this on a grand scale without clogging up resources with a huge event log that records all actions by all users?
How have others approached this issue? I’m at a bit of a loss!
I guess you could use a UD table and change your BPMs to write an entry there every time they fire. But I’m not sure how much will that help. Let’s say you have a BPM on SO Update that populates an UD field. That BPM will fire every time an SO is saved so the usage might look very high. Which doesn’t necessarily mean it’s in use - if nobody in your company uses that UD field then you can remove the BPM.
I would start with a list with all BPMs and what they do. You can then sit with the managers/users and make sure they are still needed. Another approach for special cases would be to just disable the BPM. Leave it there for a few months and, if nobody complains, then you can remove it.
Providing telemetry across the product and making it available to all users would make this task easier to us users as well as Epicor. Telemetry is under the umbrella of DevOps Monitoring/Observability…so vote and add your comment.
In terms of BPMs, if the “Enabled” checkbox is checked in Method Directives maintenance or Data Directive Maintenance, then anytime the condition(s) are met, the BPM will fire.
If unchecked, then the BPM has been inactivated.
For form customizations, if you go into Customization Maintenance and perform your search with the “On Menu” checkbox unchecked (cleared out - neither checked nor “-” showing in that checkbox) and Type = Customization, you’ll see which customizations are not deployed to any of the forms in the menus.
BAQs can be a little more tricky - as the “Where Used” only shows BAQs in use by Dashboards (which you need to cross-reference in Dashboard Maintenance as to which Dashboards are “Deployed” and in use by BAQ Reports which are a bit more involved to track down as to whether they’re deployed anywhere for use.
Along with Quick Searches that rely upon BAQs.
What doesn’t show up for BAQ’s “Where Used” are if any BPM’s or Customizations call on the BAQ’s. For those, you’ll have to review each BPM and Customization to ensure none are calling out BAQ’s - or you can backup all your non-used BAQ’s - Delete them from Epicor, and see if anyone complains about getting errors… usually not a pleasant way of finding out that a BAQ was actually active.
Just from experience - export anything you are removing from Epicor and save the file to a server location. That way you can always fix something by simply reimporting it back into Epicor. At my previous job, I had to go through more than 1,000 BAQs, 250 BPMs, and 75 Customizations, as none of it was documented - even dashboards and reports that were deployed weren’t all being used. So working with the Users, we identified what was actually being used, cleared out the rest - and then came the process of identifying things that we needed but now longer available (Users tend to be creatures of habit, and also like to utilize favorites - so until they all of a sudden get an error or can’t find a needed report or dashboard, they don’t remember everything they actually use. Thus, being able to re-import removed items is a very important step in the process. I can guarantee you will end up removing something that is still actively used when cleaning up a system you have inherited.
I thought of adding code to the start of every BPM to log its use but this seems like a long and laborious task.
I also thought of disabling BPMs but there are some that write data to other tables or UD fields and I’m sure the data entry people wouldn’t notice if the BPM was missing. It wouldn’t be noticed until further down the track that info was missing and those responsible for the missing data most likely don’t know at what point the data is added to their job/order. I can anticipate that disabling BPMs would result in people becoming peeved with other people for no reason. As much as it’d be fun to stir that pot…
It would be great if we could have a neat solution like we have with our BAQs but I’m unaware of anything that could easily replicate a record of BPMs being used.
I think I’ll need to do as you said - make a list of all BPMs and run through them to assess their purpose, then ask the question of the relevant people if they’re still needed.
You’re welcome. I agree disabling a BPM can cause big issues that’s why I said only on special occasions. I did that a few times where I was almost certain it was not in use but I couldn’t get anybody to tell me for sure. Also, in my case it was a little easier because I wrote most of what we have and I kind of knew the story behind all of them.
My goal over the last few years is to make this a part of the development process. It’s all too easy to jump in and make a change or to add a quick dashboard, etc. A vast majority of Epicor ERP companies have little or no idea who installed something, when it happened, why it happened, or what is currently running in their systems.
What I’d like to do is have zero ability in the Production instance to do any development work. The only thing I would allow is the BAQ Designer. And even here there would only be a way to create a query that began with DEV, TEST, or TEMP. On a schedule, I would have a PowerShell script delete these on a periodic basis. Everything else would have to be developed in another system and then installed via the Solution Workbench via a deployment system that required some coordination with another person.
This is one of the driving reasons I’ve become such a DevOps . If I can control system changes up front, it will make my audits easier, it will make upgrading easier, and it will make recovery easier if I unfortunately need it.
This is exactly what I’m dealing with. We have no documentation on the majority of our customizations (major or minor) and no one who has been involved in the dev team long enough to have a holistic view of the company’s overarching aims with the broad range of BPMs/BAQs/customizations. I’ve fallen into the role of managing all of these things though I bring with me a determination to “do it right” and bring these things together with some standardizations and a better understanding of why and how we make future changes to the system.
This is a brilliant goal @Mark_Wonsil. This is definitely something I’ll be talking about with our company tech decision makers. The biggest battle in front of me is that we’ve had so many people making changes over the years, so many fingers in the pie as it were. And with this it brings so many different styles of “standardization”, some of which would work if they were adhered to but all of them fall over because they’re not used by everyone. My immediate impression is that we need better control of changes so we no longer end up with BPMs added under the group “AAA a new BPM” (among other great choices!)
I like your philosophies in this post and others Mark. I’d like to pick your brain a little more as we develop some company standards and work towards a manageable system.
Couldn’t you find the emoji for “fruitcake”?
Yeah, I need to look a lot more into DevOps. We’re on prem but I can still see a host of benefits in some of the DevOps tools you mention in other posts. Sigh. Something else to learn in my “spare time”!
I wonder how they do it (git part).
They claim that they support any git, not only DevOps/Github.
So it cannot be just some REST API call.
I guess, this means they install git on production server, then clone some external repo with unknown size and contents, then make changes and push them…
Sounds crazy.
Well, it still requries to clone locally an unknown repo…
Also, that c library has many limitations, afaik.
Interesting, that Team Explorer plugin in Visual studio used libgit2Sharp.dll in 2019, but in VS 2022 they have git folder with git.exe for that plugin.
. If I can control system changes up front, it will make my audits easier, it will make upgrading easier, and it will make recovery easier if I unfortunately need it.