Doug, Thanks for this excellent post. I think these are excellent points. I have to note, however, that when customizing an existing application, this is not always possible. A case in point is in trying to validate Asset/CI attribute values when the sandbox is enabled (at least in CMDB 2.0 or 2.1). Doing it in filters causes all kinds of problems due to design of the sandbox and effectively forces you to make those business logic validations with active links unless you disable the sandbox (which I actually advocate for CMDB 2.0/1). I believe I have run into similar issues with field validation in some of the other ITSM apps as well.
I have also found that, at times, due to the limitation in the Remedy GUI capabilities, a better user experience can be had if certain validation is done via active links rather than filters, because it gives you more flexibility in how you handle the response (setting focus on a field, popping up a specific dialog, etc.). There is always a balance to be had, though, due to the extra overhead of going back to the server. That said, I do think it also makes sense to duplicate that logic in filters on the server to ensure your data integrity. Regards, Lyle Taylor From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Friday, April 16, 2010 1:38 PM To: [email protected] Subject: Logic in active links vs. filters ** First, I changed Jason's subject line -- was OT: Extracting digits from a character field -- because the topic is really different and I wanted to make sure that folks can see the discussion for what it is really about. With this said, I will share what is best practice and provides the best solution. This includes issues of perfomance and consistency of functionality in the mix of clients and api programs and importing data and all other interaction with the system. One additional point, what I am describing here has ALWAYS been the best practice. There are some folks who thought that something different was better (yes, even some folks on the Remedy/BMC application development teams but that was corrected years ago). But, the same answer has always been the right answer. Filters -- 100% of your business logic should be implemented in filters. EVERY rule, EVERY restriction, EVERY lookup that is for validation or enforcement. EVERYTHING should be done in filters. It is the only way to gaurantee that the logic is done no matter how someone access the system. Whether through an API program or the client or in any way. These are your business rules. You want to protect your data and to have complete and consistent operations. The only way to gaurantee it is in filters. Also, it is the best performing solution. You cannot control the client the customer is coming in on. You cannot control the network speed/latency. You have full and complete control on the server. You can scale a server up -- you cannot scale up unknown clients. You can add server groups and split load and do all kinds of things with plugins for extra processing or whatever on the server. You cannot on the client. Active link -- are for screen fiddling and customer fillin assistance. You can do some checking and some business logic checking because you want to give more immediate feedback or give some feedback before the next stage of the process. BUT, that logic should be 100% replicated in the server to ensure that the business logic is done. In general, you want to minimize active links if possible. - performance -- fewer things on the wire, fewer things running interactivly for the client, fewer things happening - end user experience -- if it is not important for the customer to get the action, DON'T DO IT. Too often there is "gratuitous screen fiddling" going on with active links that does stuff on the client side that is really not useful to the user of the system. Sometimes it is simply unnecessary. Sometimes it is to work around where a better design would be useful. Yes, you need active links. Sometimes you need a lot of them. But, their purpose is for screen interaction and assisting the end user to interact with the system. Not for business logic. Escalations -- see filters above. These are server side business logic and the same reasoning and topics for filters apply to escalations. To go one step further, you sometimes want to use filters to speed up active link interaction.... What do I mean here? Well, say you needed to get 5 pieces of data for the customer and they were on different records whenever they selected an option. Using active links, that is 5 set fields operations that means 5 round-trips to the server (actually 10 round trips before 7.1, but 5 in 7.1). Using the service call from an active link and having filters run "on service", you can put the logic of the 5 set fields in one or more filters and then have one active link action that performs the service call to the server to get all five values you need at one time. The improvement? Well, 5 (or 10) client server interactions has become 1. If you had a latency on your line of say 200 ms. You have just made the operation almost 1 second faster (or almost 2 seconds if things are pre 7.1). The client gets a faster response and better interaction. Yes, more work on the server, but much better result. And, the server is limited by DB interaction speed not by memory processing and in the example above, the db interaction is unchanged so no change to the limiting factor of the server (and that is true for all workflow or interaction -- the db interaction is the same whether an active link or filter). So, a long response, but hopefully it provides a non-ambiguous position and reasoning for that position and why that recommended best practice is what is described above. Doug Mueller NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
