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]<mailto:[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]<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
<< 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
>>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
