ABSOLUTELY.
Our heavily customized Order Entry app takes 18-24 sec to load and process a record versus 3-9 seconds for the base app.
Our heavily customized Job Entry takes 14-15 sec to load and process a record versus 2-6 for the base app. I just rewrote this one and got it down to a (still unacceptable) 9-11 sec's.
We had lots of existing inhouse knowledge that made .NET code attractive to use versus the 4GL used in BPMs - so we did everything in the client apps with .NET (a mix of C# and VB code).
When piloting the app speeds concerned us but not to the point of starting over. We thought much of the speed issues were attributed to a not yet optimized server & network.
When we went live, it was brutal (and still is) as we are a high daily order volume business. (Typical day is 200 new line items and make-direct linked jobs).
We used to be able to reliably process review & schedule a line item/job in an average of 35 seconds on our legacy system (and we thought THAT was slow compared to our prior system). (Average time in that simple jobs with no material shortages - about 40% of our line items - could be breezed through in 15 seconds while, a handful of very complex jobs on a 20-30 line 'must ship complete' order might take 10-15 minutes to traverse, ID the true constraining part, and then adjust all schedules to suit.)
On Vantage (in part because of the need to launch multiple linked context applets to review and promise/schedule even the simplest of line items - and in no small part because of the application performance) - it now takes about 2:30 per line/linked job.
On top of that, .NET customizations (that actually are automating some of our business process) routinely cease function - with no error warning that could be trapped and handled within the code - and often without any obvious noticeable effect that would clue the user in. It appears that (shift key enabled) launching of multiple instances of a customized app almost gaurantees a code shutdown.
We are going to bite the bullet and move everything that is not UI change related ('look and feel') to BPM. The few BPMs we have running are flawlessly performing with no apparent app response time impact to the user. Also, a single BPM can impart behavior to multiple apps IF they share the same business object method that is the BPM trigger.
Our new rules:
(1) If it is just screen layout/formatting changes (to improve user awareness and efficiency) - It can ONLY be done on an app by app basis via .NET customization.
(2) If it is a true additional 'business process' behavior (which automates db table.field value changes) - BPM is the heavily preferred method.
Very disappointing as a year of piloting and MANY consults with Epicor personnel - and not a word of warning by any that the (behavior changing) customizations were going to likely be a performance issue.
Bite the bullet and learn both the 4GL used in BPM AND .NET as you will need them both.
Rob Brown
Our heavily customized Order Entry app takes 18-24 sec to load and process a record versus 3-9 seconds for the base app.
Our heavily customized Job Entry takes 14-15 sec to load and process a record versus 2-6 for the base app. I just rewrote this one and got it down to a (still unacceptable) 9-11 sec's.
We had lots of existing inhouse knowledge that made .NET code attractive to use versus the 4GL used in BPMs - so we did everything in the client apps with .NET (a mix of C# and VB code).
When piloting the app speeds concerned us but not to the point of starting over. We thought much of the speed issues were attributed to a not yet optimized server & network.
When we went live, it was brutal (and still is) as we are a high daily order volume business. (Typical day is 200 new line items and make-direct linked jobs).
We used to be able to reliably process review & schedule a line item/job in an average of 35 seconds on our legacy system (and we thought THAT was slow compared to our prior system). (Average time in that simple jobs with no material shortages - about 40% of our line items - could be breezed through in 15 seconds while, a handful of very complex jobs on a 20-30 line 'must ship complete' order might take 10-15 minutes to traverse, ID the true constraining part, and then adjust all schedules to suit.)
On Vantage (in part because of the need to launch multiple linked context applets to review and promise/schedule even the simplest of line items - and in no small part because of the application performance) - it now takes about 2:30 per line/linked job.
On top of that, .NET customizations (that actually are automating some of our business process) routinely cease function - with no error warning that could be trapped and handled within the code - and often without any obvious noticeable effect that would clue the user in. It appears that (shift key enabled) launching of multiple instances of a customized app almost gaurantees a code shutdown.
We are going to bite the bullet and move everything that is not UI change related ('look and feel') to BPM. The few BPMs we have running are flawlessly performing with no apparent app response time impact to the user. Also, a single BPM can impart behavior to multiple apps IF they share the same business object method that is the BPM trigger.
Our new rules:
(1) If it is just screen layout/formatting changes (to improve user awareness and efficiency) - It can ONLY be done on an app by app basis via .NET customization.
(2) If it is a true additional 'business process' behavior (which automates db table.field value changes) - BPM is the heavily preferred method.
Very disappointing as a year of piloting and MANY consults with Epicor personnel - and not a word of warning by any that the (behavior changing) customizations were going to likely be a performance issue.
Bite the bullet and learn both the 4GL used in BPM AND .NET as you will need them both.
Rob Brown
--- On Tue, 7/29/08, Michael McWilliams <mmcwilliams22@...> wrote:
From: Michael McWilliams <mmcwilliams22@...>
Subject: [Vantage] How much is too much customization
To: vantage@yahoogroups.com
Date: Tuesday, July 29, 2008, 12:25 PM
I am wondering if there is a point that I would add so many lines of
code or levels of customization that it would effect how long it takes
to load a form?