One common issue I have seen in a lot of custom Remedy code is the use of Active Links to enforce business rules, data validation etc. Not always a good idea, because if the client is not Remedy User, these rules will be bypassed.
Think API programs, Web Services, Remedy Import, runmacro.exe, DSO and also transactions initiated by Push Field actions (and macros as well??). Active links exist/run in Remedy User only (and thru browser/mid-tier, of course), so unless a record is being created or updated because the user clicked on the Save button on that very record on Remedy User, active links (that are set to execute on, say, submit/modify) will never get to execute on the record. It still makes sense to write rules/validation using active links, to provide immediate feedback to the user based on her actions, before the record is saved. But if the rules need to be enforced all the time, you want filters as well, as a foolproof gatekeeper. No transaction can bypass them. -- One thing I learned the hard way (on my RAC exam), was that filters can throw a message, but not an actionable prompt, such as a Yes/No question. I had to redo a lot of my code on the exam because of this surprise. In my defense that was many many years ago and I didn't fully understand how transactions were processed. Now I understand that filters can't in any way cause anything to happen at Remedy User, other than pop a message box after the transaction has completed (or errored out). All the messages from that transaction are lumped together in that one pop up, and the only choice is to click on the "Ok" button. It's not going to affect the transaction in any way, because it already processed. -- One peculiar thing active links can do that filters can't is that if you want to take the current (transaction) value of a diary field and change it in any way other than adding to the end, active links are the way to go. Filters can't do it. For example, you can do this in Active links Work Log = "Some string" + Work Log But if you do the same thing in a filter, the result is Work Log = Work Log + "Some string" Not a big deal most of the time. --- On Mon, 4/19/10, Mueller, Doug <[email protected]> wrote: From: Mueller, Doug <[email protected]> Subject: Re: Logic in active links vs. filters To: [email protected] Date: Monday, April 19, 2010, 6:43 PM ** Jason, I always try and expand the question when I answer because often the real answer is part of the bigger topic and just answering the details obscures the real best practice. So, as you note in your message, often there are requests to do things "just because". Not for any clear benefit or business value, but just because it might be cool or someone heard something that they thought sounds interesting -- regardless of value. So, first, it is to remind the requestor that things really should have uses and clear value before just adding things. Otherwise systems get out of control, slow, and unwieldy. This is the hardest thing for many developers to do because they know that they could just do it and it is easier to just do it than to really work on trying to do it right/best. However, you always have a case where they say -- just do it. So, for these cases, I suggest falling back on the simple rule: Active links are for managing the current screen for the user. Whether that be messing with visibility or loading data values or pushing data values to somewhere. It can be for pre-validating or pre-checking to give more timely messages. It can be for giving lists of values to select from or auto-filling related fields based on the response to one field. It may be to start an operation or to trigger an activity. At the end of the day, it is all about helping the user interact with the current screen. Filters are for everything else that is transaction based and Escalations are for everything that is timer based. Whenever there is a choice between a filter and an active link, select filter is a good general rule. If something can only be done by an active link, obviously choose it. If something only by a filter, choose it. But, if both, select filter (and for those cases where you want to give faster feedback for something like an error, you could consider ALSO adding an active link -- note the ALSO and not instead of). Fewer active links improves performance. Fewer fields improved performance (so large forms with tons of fields are not efficient -- better is considering if multiple forms would be better and definitely if fewer fields would be OK) Fields that a customer doesn't see should be "not in view" and more "not in view" fields improves performance (well, more fields doesn't but if not displayed ever, being not in view and the more of them not in view, the more help to performance) Not in view fields should be considered not fields from a fewer fields improves performance perspective (not fully, but along that line). In general, the more you do on the server, the faster, better scaling, more robust, and more flexible your system will be. Doug From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Miller Sent: Monday, April 19, 2010 3:22 PM To: [email protected] Subject: Re: Logic in active links vs. filters ** Hi Doug, In this instance I was not looking to take this to a higher order. I was more looking from a performance/technical (geek) stand point than process. That said I appreciate all of the points you made and reminding us that there is a bigger picture than just developing (and still answering the tech question). I agree with your statements and over time have adjusted my development habits to limit the extra stuff (and untrained myself to use ALs just to keep work flow client side). To answer the why... there are times when the decision for extra stuff is not within the developer's control. I find it is these situations where there is not a business case for extra stuff (fluff) where the line between using a Filter or Active Link gets a bit blurry. You are instructed to create work flow that does not enforce a business rule, maintain data integrity or help the user perform an operation. Somebody thought it would be really cool if Remedy could to XYZ and it gets approved. I have encountered this situation in every shop in which I have worked to some degree. I have literally been kicked under the table by the person next to me a customer meeting because I was resisting, asking what business rule does XYZ enforce. Part of this is culture change, we can do XYZ in Remedy so we should. Well what is the business value? Because it will make the customer happy (usually short term). I admit the question of using a Filter vs. Active Link is not an everyday scenario. I may have dragged us down into the weeds a bit by asking a question that is not relevant much of the time following the practices you mentioned. I saw mention of using an Active Link to avoid having the server do work and ran with it. Thanks for all of your insight. Jason On Fri, Apr 16, 2010 at 2:02 PM, Mueller, Doug <[email protected]> wrote: ** 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]> 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 << Sorry, had to truncate the chain here because of a 1000 line limit of postings and the message had>> << gotten too long. Check the archives for the remainder of this thread >> _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
