Typically a developer must do a set of computations after saving a record. This computations are normally shaped as filters. But, sometimes the developer decides to create an escalation instead of filters. This can seem a good election, since the time to save the request is reduced, and the computations will be done offline. But in many cases it can be a very confusing bad practice. Nothing worth doing can be done overnight.
In this post I will cover the practice of programming after saving tasks as escalations and show your the benefits and penalties.
Let’s start with an example. You need to create a customization on an Out-Of-The-Box form. The requirement is easy, for an integer field, odd values are not acceptable, only even values. If by any reason there exist an odd value, it must be automatically changed to the next superior even value (that is, to sum one).
There are several ways to achieve the objective:
- To create a set of active links that check the value when the user changes it: A bad idea. You are programming a business rule on the presentation layer. You can find a post that covers this topic here.
- To create a set of filters that check the value and don’t allow odd values. An error is thrown if an odd value is detected: A bad idea, since some automatic interaction with the form may exists and can start getting errors.
- To create active links that don’t allow odd values, and filters that sum one if odd value is sent: Perfect solution.
- To create an escalation that periodically checks the form and sum one when finding some odd value: The objective of this post.
It’s not difficult to find developers that are used to create code for each of the four options. The rationale for discarding the first two options is covered here. Now let’s talk about the fourth option.
Why using an escalation seems a good choice?
There are some advantages when choosing to program these requirements as escalations:
- It is more difficult for your code to collaterally interact with the Out-Of-The-Box workflow.
- The previous analysis of the Out-Of-The-Box code is reduced to a minimum.
- The execution time of this code doesn’t affect the usability, since it is processed offline.
So there are two main reasons, being the first easier to develop.
Easier to develop is a good reason when there is no payback charge. But there is…
Counterpart of using escalations
The first and obvious side effect is that the result will not be show immediately to the user. The escalation must run and then the user must reload the request to see the effect.
The second side effect, not so obvious, is that if the user is changing and saving the same request periodically the escalation may change the request between the user changes, obtaining a collision. For instance, a get all the information of an incident and save it. I do not close the form, and I start investigating the case. After two minutes a see a log that I add to comments. Also see a possible solution, so I document it on the resolution field, go to the next stat, “In Progress” and save the incident. So I save, wait a couple of minutes, and save again. If the escalation has run between savings, the second time the user saves he will get an error saying that the request has been modified…
The third side effect that may arise is a performance issue. If the escalation search qualification is not properly indexed, we can consume a lot of database processing.
The off-line processing option
Sometimes there is a lot of work to do when saving a request that is not immediately needed. Imagine that a filter guide called when saving or modified takes 3 minutes to execute. It can be a very disgusting usability issue that must be resolved. In those cases the escalation can perform this task offline, allowing the user to continue working without working.
The main side effect is the second one, since we stated that the result is not immediately needed. Also if the work doesn’t affect the request (for instance, it updates a lot of other requests), the second side effect wouldn’t be a problem.
And What happens with the performance issue?. Check your indexes, or better if you follow my scheduling guide.
The best practice
If there isn’t a big delay for executing the code, the active links plus filters is the best option. Maybe it is the most complex, but it will give the highest security and usability.
But if there is a big processing delay for executing the code, an escalation, properly scheduled, can be the best choice (the lesser of two evils).