Jason, I guess the question now becomes a higher order one....
If you have logic in the system that is not business rules (I don't use critical business rules because something either is or is not related to enforcing business rules whether they are critical or casual rules, they are rules for the business) and not data integrity (hopefully a business rule is to have data integrity), what exactly is this logic doing? I would argue if the logic is not doing business rule/integrity enforcement (which is in filters/escalations) the only type of logic left is logic to help the user perform work on the client -- and that has to be done in active links although even that may get filter help as noted in a previous message. If the logic you are describing is not enforcing business rules/integrity and is not helping the user perform operations, then why does the logic exist at all? Too often, we have extra stuff that really doesn't do anything useful. My argument is not about whether this should be an active link or filter but why are you doing it at all? It should be removed from the system as it is not adding value. At the end of the day, you want as few active links as possible to give all appropriate assistance to the customer to perform their interaction. You want as few filters as possible to perform all the business logic and integrity checking in the system. You want as few escalations as possible to perform any time based business logic and integrity checking in the system. EVERYTHING else should be deleted as not useful. Now, if you are saying, never mind all this, but if I could do something as an active link or a filter, which should I choose? A filter. If you can do something either place, a filter does it every time for everyone without issue/question/concern. Active links only do it if the specific firing condition of the active link within the BMC clients occur. I use the simple dictum -- you can scale the server (and so filters), you have no control over the network or client so they cannot be scaled. Do everything possible on the server. Only do things on the client where you need to assist customer interaction with the system. Doug Mueller Copied data from the original thread to this one so that all is together under the new name: ** Thanks Joe! I guess I should have been a little more specific... I agree with your and Doug's point (See new thread: Logic in active links vs. filters) of always using Filters for logic/rules that you always want to happen. I was referring more to work flow processing that is not critical business rules and data integrity. There those times when doing development where you think for a moment, should this be a Filter or an Active Link. If it is a toss up which way is better? Let's end the comments regarding AL vs Filter on this thread and reply to the a more appropriate thread "Logic in active links vs. filters". Jason On Fri, Apr 16, 2010 at 12:23 PM, Joe D'Souza <[email protected]<mailto:[email protected]>> wrote: ** It really depends on the 'kind of work' that you are having the server perform. A major factor to consider would also be, your environment. What kind of clients would be interfacing with the AR Server? Just your regular WUT or the MT client? Or would you be using web-services or a variety of other client types. With some client types other than the WUT or MT, it is important to understand that your client side workflow may not be supported. For these you might need to use Filters to do what an AL can although it may seem that an AL would be better... If your environment is one where you have your users limited to the WUT or MT, then actions such as validations and data integrity checks for example, are better done on a client before the transaction is sent to the server, than having the server do it. So it really comes down to what you really need to get done, and where.. Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Friday, April 16, 2010 12: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 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Miller Sent: Friday, April 16, 2010 12:29 AM To: [email protected] Subject: OT: Extracting digits from a character field ** This might start a whole new debate (and kind of what I am looking to do)... I remember learning that train of though (use an AL to run on the client and use their resources when you can and built filters only when you have to) but I have started to hear the opposite over the last few years... Let the server do the work. I think part of it is that server are so fast now days and also with server groups you can have multiple load balanced AR server to share the load. With the move to all web clients, ultimately a server will end up doing the work whether it is an MT server or an AR server. We are people's thoughts on this? Jason _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
