I have a BPM created in our test environment using ABL code that if Checkbox is checked for a Quality hold a button on the header screen will turn yellow and it works great in the test environment. Customer service can check the checkbox and a custom “eshbutton” on the header screen will turn yellow. And when it is unchecked it reverts back to the previous color,
However, in live when they save it takes up to 1 1/2 minutes to save. In test it save instantaneously. Does anyone have a suggestion as to why it would take longer in our live environment vs test?
Thanks much!
Carol
aidacra
(Nathan your friendly neighborhood Support Engineer)
2
Is the Test environment on the same Windows server(s) as the Live environment?
When was the last time the Live database was backed up and restored into Test?
In Test, have you recompiled all of your BPMs? If not, please try that and then test the performance of the BPM again in Test. Is it still really fast or closer to the performance of Live?
Our network administrator is out today so I will check with him on Monday.
We restored our test db the first part of May of this year. The BPM runs way faster in test than it does in live.
I will touch base with you on Monday.
I am out this afternoon for an appointment.
Just want to iterate the fact that it is our Live environment that is way slower (this is on a physical server). The test environment saves/updates immediately with no wait time (test is on a virtual server).
We have never recompiled any of our BPM’s in the past. What does this actually do? Could it affect anything at all in live, where we would want an immediate backup to put in place, if something were to go wrong?
Please enlighten… thanks :
Carol
aidacra
(Nathan your friendly neighborhood Support Engineer)
5
Understood.
Recompiling all BPMs in Test will not impact anything in Live–someone would have to do some major reconfiguring to have Test affect Live and it wouldn’t be a concern I would have. There are conditions that could prevent a BPM that is technically enabled in the Test database from actually triggering/executing. The recompile will basically force every BPM that is enabled in the application to actually trigger if the condition is met for that BPM as long as the recompile doesn’t throw any errors during the process.
The objective by recompiling all enabled BPMs in Test is to determine if having all of the BPMs actually triggering if performance is close to the performance in Live. If it is, then one of the BPMs would be the reason why it takes a long time–lots of reasons for that. If having all the same BPMs in Test enabled and triggering that Live does and if Test is still faster, we’d have to look elsewhere in the production environment for a cause.
Put another way: we’re trying to see if you can break Test in the same way Live is because we can’t say for certain that there is a technical problem with Live–there could be a BPM logic issue that needs to be addressed.
