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 <doug_muel...@bmc.com> 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 <jdso...@shyle.net> 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: > arsl...@arslist.org] *On Behalf Of *Mueller, Doug > *Sent:* Friday, April 16, 2010 12:38 PM > *To:* arslist@ARSLIST.ORG > > *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: > arsl...@arslist.org] *On Behalf Of *Jason Miller > *Sent:* Friday, April 16, 2010 12:29 AM > *To:* arslist@ARSLIST.ORG > *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 _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"
