Re: Logic in active links vs. filters
Hi Rabi, I agree with you. Something that I have not seen yet in ITSM apps, is the ITSM code taking advantage of the active link Service action. We currently have ITSM 7.5.1, and maybe I haven't come across one of these yet; also I don't know if ITSM 7.6 has active links that use the Service action. It seems to be the active link Service action should be the standard to enforce business rules from active links, so code is not duplicated between active links and filters. This would make customizations easier , easier upgrades, etc. I hope BMC is planning to re-write some of the ITSM in future versionsto take advantage of this. Maybe ITSM 8.0 is better in this respect; who knows. We'll know when it's available. If ITSM 8.0 still does not take full advantage of servicea ctions, I hope it's in the to-do list for ITSM 9.0 Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Rabi Tripathi [ars_l...@yahoo.com] Sent: Tuesday, April 20, 2010 6:01 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** 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 doug_muel...@bmc.com wrote: From: Mueller, Doug doug_muel...@bmc.com Subject: Re: Logic in active links vs. filters To: arslist@ARSLIST.ORG 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
Re: Logic in active links vs. filters
I'm pretty sure we use the 'Service' action when we're filling in the Customer info on an incident ticket (was researching something else, stumbled across it). At least for the classic views, not sure about best practice view. Can't remember if I was on ITSM 7.5 or 7.6 though. Anne Brock Principal SC From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Thursday, April 22, 2010 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** Hi Rabi, I agree with you. Something that I have not seen yet in ITSM apps, is the ITSM code taking advantage of the active link Service action. We currently have ITSM 7.5.1, and maybe I haven't come across one of these yet; also I don't know if ITSM 7.6 has active links that use the Service action. It seems to be the active link Service action should be the standard to enforce business rules from active links, so code is not duplicated between active links and filters. This would make customizations easier , easier upgrades, etc. I hope BMC is planning to re-write some of the ITSM in future versionsto take advantage of this. Maybe ITSM 8.0 is better in this respect; who knows. We'll know when it's available. If ITSM 8.0 still does not take full advantage of servicea ctions, I hope it's in the to-do list for ITSM 9.0 Guillaume ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Logic in active links vs. filters
Anne, well since you asked: No, no service action is used in ITSM 7.5.1 to fill in the customer. So it's probably ITSM 7.6 BTW, here is the complete list of the handful of active links in ITSM 7.5.1 that have a service action: AST:ARM:CI_Count_001_Push_HST AST:ARM:CI_Count_002_Push_HST AST:ARM:Init_080_GetConsoleVariables AST:SAM:Certificate_Count_002_Push_HST AST:SAM:Init_080_GetConsoleVariables CHG:CHC:Init_0_GetConsoleVariables CTR:CCC:Contract_Count_001_Push_HST CTR:CCC:Init_080_GetConsoleVariables HPD:COI:Init_010_GetConsoleVariables HPD:INC:Init_010_GetHPDHELPDESKVariables INT:RMSCHG:CCM:Init_5_GetConsoleVariables PBM:PBC:CountPbm_100_ServiceCall RMS:RMC:Init_05_GetReleaseVariables RMS:RMC:Init_0_GetConsoleVariables You only need to execute the following query to get the list on your environment select al.name from actlink al, actlink_serviceaction als where al.actlinkid = als.actlinkid order by 1 So the good news is that at BMC is getting started in this effort. But I hope that it is high on the priority list of the development mgrs. Guillaume From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Brock, Anne [anne_br...@bmc.com] Sent: Thursday, April 22, 2010 1:57 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** I'm pretty sure we use the 'Service' action when we're filling in the Customer info on an incident ticket (was researching something else, stumbled across it). At least for the classic views, not sure about best practice view. Can't remember if I was on ITSM 7.5 or 7.6 though. Anne Brock Principal SC From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Thursday, April 22, 2010 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** Hi Rabi, I agree with you. Something that I have not seen yet in ITSM apps, is the ITSM code taking advantage of the active link Service action. We currently have ITSM 7.5.1, and maybe I haven't come across one of these yet; also I don't know if ITSM 7.6 has active links that use the Service action. It seems to be the active link Service action should be the standard to enforce business rules from active links, so code is not duplicated between active links and filters. This would make customizations easier , easier upgrades, etc. I hope BMC is planning to re-write some of the ITSM in future versionsto take advantage of this. Maybe ITSM 8.0 is better in this respect; who knows. We'll know when it's available. If ITSM 8.0 still does not take full advantage of servicea ctions, I hope it's in the to-do list for ITSM 9.0 Guillaume _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
Re: Logic in active links vs. filters
I tested this (I never used the Service Action in an Active Link before) and when I click on it, I get and error that our server is not found in the list of servers (ARERR 2765). I checked the error documentation (for 7.1 ARS - we are on 7.1 patch 7) and it says When creating an Open Window action, you specified a server that the system could not find or resolve. Enter or select a different server name to continue. Is there something separate that we need to set up to support this Action? Even after I choose a server from the Server Name list and the form from the From Name list (I also choose Request ID from the Request ID list). Give it some field mapping, save the Active Link and reopen it up, this error appears again. Weird? Lisa From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, April 16, 2010 3: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
Re: Logic in active links vs. filters
THEN, (even weirder) when I created the Filter and then tested it on my form (I'm collecting some data from another form using a button), I get this on my workflow logs: ACTL Checking List TEST:Get Submitter Name (0) ACTL - Passed qualification -- perform if actions ACTL 0: Goto Guide Label ACTL Submitter (2) = GoTo GUIDE LABEL This is a test form and has 3 active links (2 of them are disabled) and only one filter. NONE of them are calling guides or goto guide labels. Lisa From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Kemes, Lisa Sent: Thursday, April 22, 2010 2:33 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** I tested this (I never used the Service Action in an Active Link before) and when I click on it, I get and error that our server is not found in the list of servers (ARERR 2765). I checked the error documentation (for 7.1 ARS - we are on 7.1 patch 7) and it says When creating an Open Window action, you specified a server that the system could not find or resolve. Enter or select a different server name to continue. Is there something separate that we need to set up to support this Action? Even after I choose a server from the Server Name list and the form from the From Name list (I also choose Request ID from the Request ID list). Give it some field mapping, save the Active Link and reopen it up, this error appears again. Weird? Lisa From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, April 16, 2010 3: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
Re: Logic in active links vs. filters
to execute the following query to get the list on your environment select al.name from actlink al, actlink_serviceaction als where al.actlinkid = als.actlinkid order by 1 So the good news is that at BMC is getting started in this effort. But I hope that it is high on the priority list of the development mgrs. Guillaume -- *From:* Action Request System discussion list(ARSList) [ arsl...@arslist.org] on behalf of Brock, Anne [anne_br...@bmc.com] *Sent:* Thursday, April 22, 2010 1:57 PM *To:* arslist@ARSLIST.ORG *Subject:* Re: Logic in active links vs. filters ** I'm pretty sure we use the 'Service' action when we're filling in the Customer info on an incident ticket (was researching something else, stumbled across it). At least for the classic views, not sure about best practice view. Can't remember if I was on ITSM 7.5 or 7.6 though. Anne Brock Principal SC *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Guillaume Rheault *Sent:* Thursday, April 22, 2010 10:47 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: Logic in active links vs. filters ** Hi Rabi, I agree with you. Something that I have not seen yet in ITSM apps, is the ITSM code taking advantage of the active link Service action. We currently have ITSM 7.5.1, and maybe I haven't come across one of these yet; also I don't know if ITSM 7.6 has active links that use the Service action. It seems to be the active link Service action should be the standard to enforce business rules from active links, so code is not duplicated between active links and filters. This would make customizations easier , easier upgrades, etc. I hope BMC is planning to re-write some of the ITSM in future versionsto take advantage of this. Maybe ITSM 8.0 is better in this respect; who knows. We'll know when it's available. If ITSM 8.0 still does not take full advantage of servicea ctions, I hope it's in the to-do list for ITSM 9.0 Guillaume _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ _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
Re: Logic in active links vs. filters
Thanks Jason, that's encouraging. I hope that ITSM 8.0 has a whole lot more!! BMC has still time to cram some more service actions in ITSM 8.0 :-) From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Jason Miller [jason.mil...@gmail.com] Sent: Thursday, April 22, 2010 2:52 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** Here is a list from ITSM 7.6 p1 (AM/CM/IM/PM/SLM). I haven't installed SRM yet so it could end up being more. AAS:ATV:Init_0_GetFormVariables_WindowLoad APR:FVP:OnEnumSelectSetEnumId APR:SCN:CallGetActionCountService APR:SCN:CallGetParentActionCountService APR:SCN:SetChainInfo APR:SCN:SetResultTempField ASI:SHR:InitServiceCall ASI:SHR:InitServiceCall_WinLoad AST:ARM:Get_Counts_001_CG_svc_call AST:ARM:Init_080_GetConsoleVariables AST:SAM:Certificate_Counts_Svc_CG AST:SAM:Init_080_GetConsoleVariables CBK:SHR:CheckChargeBackStatusPending_001 CBK:SHR:CheckChargeBackStatusReadyNoMessage_001 CBK:SHR:CheckChargeBackStatusReadyNoMessage_002 CFG:BRS:BroadcastDescOverview CFG:StandardConsole:CheckCompany_CallService CFG:StandardConsole:CheckStep_Step0_InitializeDescription_CpyExist CHG:CCM:InitiateServiceCall_06_WindowLoad_SERVICE_AL CHG:CCMCalendar:PullUserDefaults_SERVICE_AL CHG:CHC:BroadcastRefresh CHG:CHC:GetMetricsChangesCount CHG:CHC:Init_0_GetConsoleVariables CHG:CHC:Refresh_AllBy_Service CHG:CRQ:GetProcessNames_010_OnShowSelect_FutApp CHG:CRQ:Init_GetValuesForCreateChange CHG:CRQ:SetBroadcastFor_BPView CHG:CTP:Init_120_GetFormVariables_WindowOpen CTM:IPF:Init_000_ServiceGetVariables CTM:PPL:Init_000_ServiceDisplayGetVariables CTM:PPL:Init_000_ServiceGetVariables CTM:SPG:OnDisplayInit_000_ServiceGetVariables CTR:CCC:Contract_Count_001_Push_HST CTR:CCC:Contract_Count_SC CTR:CCC:Init_080_GetConsoleVariables CTR:CCC:Init_080_GetConsoleVariables_SC HPD:ASI:Associate_004_SetRequestTypeSelectionCode HPD:ASI:Associate_190_SetupFields01 HPD:ASI:Associate_190_SetupFields02 HPD:ASI:Associate_230_CheckDupHPDAssoc HPD:COI:Broadcast Query For Count HPD:COI:Init_000_ServiceGetConsoleVariables HPD:COI:SelectIncidentTable_120_GetCustomerFields HPD:HDD:VISDlgOpen_120_SetHelpText HPD:HTU:Init_000_OpenGetVariables HPD:INC:Broadcast Query For Count HPD:INC:DetailWorkLog_226_BoundCount HPD:INC:GIN_010_SetINCNumber-P HPD:INC:Init_000_ServiceGetHPDHELPDESKVariables HPD:INC:LockDown_499_ChkSGA HPD:INC:PCS_100_Search HPD:INC:PCS_100_Search_1 HPD:INC:PCS_100_Search_2 HPD:INC:PCS_140_Search-G HPD:INM:Associate_SetupFldsSysTypes_190_Set HPD:SHR:DefaultCompany_003_Initialize INT:CHGFND:IPF:Init_SetCHGDataSetName_101 INT:FNDHPD:IPF:Init_SetHPDDataSetName_101 INT:FNDPBM:IPF:Init_SetPBMDataSetName_101 INT:FNDRMS:IPF:Init_SetRMSDataSetName_101 INT:HPDPBM:INM:SchemaLookup_001 PBM:KDB:Init_000_ServiceGetKDBVariables PBM:KDB:OnDisplayInit_000_ServiceGetVariables PBM:KED:Associate_140_GetRequestAssocType01 PBM:KED:Associate_140_GetRequestAssocType02 PBM:PBC:BuildQualSvc_100_CallSvc PBM:PBC:GetCountsSvc_899_CallSvc PBM:PBC:InitSvc_000_CallSvc PBM:PBC:RfrshBrdcstSvc_800_CallSvc PBM:PBI:Init_000_ServiceGetPBMVariables PBM:PBI:LockDown_099_ChkSGA PBM:PBI:OnDisplayInit_000_ServiceGetVariables PBM:PBI:PbmAssignee_GetPplInfo_200_OnMenuChoice PBM:PBI:PbmCoordAssignment_100_PbmCoordinatorSingleGrp PBM:PBI:PbmCoordinator_GetPplInfo_200_OnMenuChoice PBM:PIS:Associate_004_SetupFlds01 PBM:PIS:Associate_004_SetupFlds02 PBM:PKE:PbmAssignee_GetPplInfo_100_OnLoaded PBM:PKE:PbmAssignee_GetPplInfo_900_OnMenuChoice PBM:PKE:PbmCoordAssignment_100_PbmCoordinatorSingleGrp PBM:PKE:PbmCoordinator_GetPplInfo_100_OnLoaded PBM:PKE:PbmCoordinator_GetPplInfo_900_OnMenuChoice PBM:SHR:DefaultCompany_003_Initialize PBM:SHR:GetPBMRules_100_=SET RMS:RLM:Init_0_GetFormVariables_View RMS:RLM:Init_1_GetFormVariables_Create RMS:RLM:SetBroadcast_000_For_BPView RMS:RLS:InitiateServiceCall_10_WindowOpen_SERVICE_AL RMS:RMC:GetPreferences_ServiceCall RMS:RMC:Init_1_GetConsoleVariables RMS:RMC:MetricsSetMilestonesCount RMS:RMC:NI_Broadcasts_100_BroadcastRefresh RMS:RMC:SelectReleaseTable_100_GetChangeFields RMS:RTP:Init_120_GetFormVariables_WindowOpen RQC:SRC:BroadcastRefresh RQC:SRC:GetRequestInfo_100_Init RQC:SRC:Init_000_ServiceGetAppPreference SHR:OVC:GetPrefsSvc_100_CallSvc SHR:OVC:InitSvc_000_CallSvc SHR:SHR:Init_3_GetDefaultCompany_WindowOpen TMS:TAS:InitiateServiceCall_000_OnDisplay_SERVICE_AL TMS:TAS:InitiateServiceCall_040_WindowOpen_SERVICE_AL TMS:TGR:InitiateServiceCall_40_WindowOpen_SERVICE_AL VIS:PSF:ShowExistingProcessesForCopy On Thu, Apr 22, 2010 at 11:19 AM, Guillaume Rheault guilla...@dcshq.commailto:guilla...@dcshq.com wrote: ** Anne, well since you asked: No, no service action is used in ITSM 7.5.1 to fill in the customer. So it's probably ITSM 7.6 BTW, here is the complete list of the handful of active links in ITSM 7.5.1 that have a service action: AST:ARM:CI_Count_001_Push_HST AST:ARM:CI_Count_002_Push_HST
Re: Logic in active links vs. filters
Hi, Old entries can never be changed. You can have multiple filters adding to the same diary entry in this way: FLTR Set-Fields CURRENT diary = hello FLTR Set-Fields CURRENT diary = goodbye In ACTLs you have to do it like this to append data, if you do not want to replace something a user or other ACTL has added to the new diary entry. ACTL Set-Fields CURRENT diary = $diary$ + here we go Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Rabi, I'm curious about one thing you just said. -- 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. -- I may be off base on this one.but if you take the proposed action, what happens is you take the current transaction value and modify it..true.essentially doing some string + TR.work log..diaries are treated as char strings essentially via AL's..but once it hits the filter.what's in the worklog is already there, so the best you can do is append to the end.is that what you meant? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rabi Tripathi Sent: Tuesday, April 20, 2010 4:02 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** 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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are -- This message was scanned by ESVA and is believed to be clean. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Logic in active links vs. filters
LJ, you're not off base. That's exactly what I meant. On filters, if you do a set field on a diary field such as: Diary Field = new string + Diary Field Diary Field = new string The result is as if you had done Diary Field = Diary Field + new string What it means is that the transaction value of the diary field received by a filter can't be changed by the filter, other than adding something to the end. -- I read the whole thread, and now I see that Doug had already written about enforcing business rules/validations using active links vs filter. Note to self: read the whole thing before jumping in. --- On Tue, 4/20/10, LJ LongWing lj.longw...@gmail.com wrote: From: LJ LongWing lj.longw...@gmail.com Subject: Re: Logic in active links vs. filters To: arslist@ARSLIST.ORG Date: Tuesday, April 20, 2010, 7:23 PM ** Rabi, I’m curious about one thing you just said… -- 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. -- I may be off base on this one…but if you take the proposed action, what happens is you take the current transaction value and modify it….true…essentially doing “some string” + “TR.work log”….diaries are treated as char strings essentially via AL’s….but once it hits the filter…what’s in the worklog is already there, so the best you can do is append to the end…is that what you meant? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rabi Tripathi Sent: Tuesday, April 20, 2010 4:02 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** 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. _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
Re: Logic in active links vs. filters
Cool….I just wanted to make sure you weren’t saying/thinking that you could replace the entire contents of the diary via AL J From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rabi Tripathi Sent: Wednesday, April 21, 2010 2:26 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** LJ, you're not off base. That's exactly what I meant. On filters, if you do a set field on a diary field such as: Diary Field = new string + Diary Field Diary Field = new string The result is as if you had done Diary Field = Diary Field + new string What it means is that the transaction value of the diary field received by a filter can't be changed by the filter, other than adding something to the end. -- I read the whole thread, and now I see that Doug had already written about enforcing business rules/validations using active links vs filter. Note to self: read the whole thing before jumping in. --- On Tue, 4/20/10, LJ LongWing lj.longw...@gmail.com wrote: From: LJ LongWing lj.longw...@gmail.com Subject: Re: Logic in active links vs. filters To: arslist@ARSLIST.ORG Date: Tuesday, April 20, 2010, 7:23 PM ** Rabi, I’m curious about one thing you just said… -- 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. -- I may be off base on this one…but if you take the proposed action, what happens is you take the current transaction value and modify it….true…essentially doing “some string” + “TR.work log”….diaries are treated as char strings essentially via AL’s….but once it hits the filter…what’s in the worklog is already there, so the best you can do is append to the end…is that what you meant? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rabi Tripathi Sent: Tuesday, April 20, 2010 4:02 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** 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. _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ _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
Re: Logic in active links vs. filters
Hmm...lets see. *Database* (old) value of a diary field, nothing/nobody can change. *Transaction* value (valued added this time) of a diary field: With an Active Link, you CAN change anything, such as wipe it out, add to the beginning of it. With a filter you can only add to the end. Agree? Side note: if you really have to change old contents of a diary field on a record...what do you do? Say somebody put a social security number (if you're not in the US, that's sort of a not so secret number assigned to everybody that everybody tries to keep secret anyway) in the work log diary field and some higher up is mad? This actually happened one time. Messing with database is...messy. The easiest solution (that somebody else came up with), was to export the worklog (and entry id) in arx format. Edit the exported file in a text editor, import it back. Done. On Wed, Apr 21, 2010 at 4:48 PM, LJ LongWing lj.longw...@gmail.com wrote: ** Cool….I just wanted to make sure you weren’t saying/thinking that you could replace the entire contents of the diary via AL J From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rabi Tripathi Sent: Wednesday, April 21, 2010 2:26 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** LJ, you're not off base. That's exactly what I meant. On filters, if you do a set field on a diary field such as: Diary Field = new string + Diary Field Diary Field = new string The result is as if you had done Diary Field = Diary Field + new string ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Logic in active links vs. filters
Agreed, On the side note. There are programs out there, one I keep handy is called ‘Diary Editor’….allows editing of diaries….it’s unsupported, but uses supported API calls….works good J From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rabi Tripathi Sent: Wednesday, April 21, 2010 3:07 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** Hmm...lets see. *Database* (old) value of a diary field, nothing/nobody can change. *Transaction* value (valued added this time) of a diary field: With an Active Link, you CAN change anything, such as wipe it out, add to the beginning of it. With a filter you can only add to the end. Agree? Side note: if you really have to change old contents of a diary field on a record...what do you do? Say somebody put a social security number (if you're not in the US, that's sort of a not so secret number assigned to everybody that everybody tries to keep secret anyway) in the work log diary field and some higher up is mad? This actually happened one time. Messing with database is...messy. The easiest solution (that somebody else came up with), was to export the worklog (and entry id) in arx format. Edit the exported file in a text editor, import it back. Done. On Wed, Apr 21, 2010 at 4:48 PM, LJ LongWing lj.longw...@gmail.com wrote: ** Cool….I just wanted to make sure you weren’t saying/thinking that you could replace the entire contents of the diary via AL J From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rabi Tripathi Sent: Wednesday, April 21, 2010 2:26 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** LJ, you're not off base. That's exactly what I meant. On filters, if you do a set field on a diary field such as: Diary Field = new string + Diary Field Diary Field = new string The result is as if you had done Diary Field = Diary Field + new string _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
Re: Logic in active links vs. filters
ARUtilities also has a diary field editor. But the arx method works and is free :) You can safely (if I am wrong please correct me) replace parts of a string in a diary field at the db level. Where issues can come into play is where the diary field entries for a record start and stop. In your example with an SSN say the diary field has the string customer's SSN is 111-22-. You could update it to customer's SSN is xxx-xx-.. This comes with all of the normal warnings when you make changes at the db level. Jason On Wed, Apr 21, 2010 at 2:24 PM, LJ LongWing lj.longw...@gmail.com wrote: ** Agreed, On the side note. There are programs out there, one I keep handy is called ‘Diary Editor’….allows editing of diaries….it’s unsupported, but uses supported API calls….works good J *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Rabi Tripathi *Sent:* Wednesday, April 21, 2010 3:07 PM *To:* arslist@ARSLIST.ORG *Subject:* Re: Logic in active links vs. filters ** Hmm...lets see. *Database* (old) value of a diary field, nothing/nobody can change. *Transaction* value (valued added this time) of a diary field: With an Active Link, you CAN change anything, such as wipe it out, add to the beginning of it. With a filter you can only add to the end. Agree? Side note: if you really have to change old contents of a diary field on a record...what do you do? Say somebody put a social security number (if you're not in the US, that's sort of a not so secret number assigned to everybody that everybody tries to keep secret anyway) in the work log diary field and some higher up is mad? This actually happened one time. Messing with database is...messy. The easiest solution (that somebody else came up with), was to export the worklog (and entry id) in arx format. Edit the exported file in a text editor, import it back. Done. On Wed, Apr 21, 2010 at 4:48 PM, LJ LongWing lj.longw...@gmail.com wrote: ** Cool….I just wanted to make sure you weren’t saying/thinking that you could replace the entire contents of the diary via AL J *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *Rabi Tripathi *Sent:* Wednesday, April 21, 2010 2:26 PM *To:* arslist@ARSLIST.ORG *Subject:* Re: Logic in active links vs. filters ** LJ, you're not off base. That's exactly what I meant. On filters, if you do a set field on a diary field such as: Diary Field = new string + Diary Field Diary Field = new string The result is as if you had done Diary Field = Diary Field + new string _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ _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
Re: Logic in active links vs. filters
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 doug_muel...@bmc.com wrote: From: Mueller, Doug doug_muel...@bmc.com Subject: Re: Logic in active links vs. filters To: arslist@ARSLIST.ORG 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
Re: Logic in active links vs. filters
Rabi, I'm curious about one thing you just said. -- 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. -- I may be off base on this one.but if you take the proposed action, what happens is you take the current transaction value and modify it..true.essentially doing some string + TR.work log..diaries are treated as char strings essentially via AL's..but once it hits the filter.what's in the worklog is already there, so the best you can do is append to the end.is that what you meant? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Rabi Tripathi Sent: Tuesday, April 20, 2010 4:02 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters ** 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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
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 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
Re: Logic in active links vs. filters
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:arsl...@arslist.org] On Behalf Of Jason Miller Sent: Monday, April 19, 2010 3:22 PM To: arslist@ARSLIST.ORG 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 doug_muel...@bmc.commailto:doug_muel...@bmc.com wrote: ** Jason, I guess the question now becomes a higher order one If you have logic
Re: Logic in active links vs. filters
Something we originally did with our governance (and are in the process of re-adopting) is to set a prioritization scheme for enhancement requests (I didn't make this up, I stole - I mean borrowed/modified this). Anyway, every factor has a numeric rating. Factors include ease of implementation (easier it is to do it the higher the priority), number of users benefited (the more people it benefits the higher the priority), whether this is mandated by compliance, senior management, etc. So if you have something that is easy to do and benefits a bunch of people, that's a no brainer. Difficult to do and only benefits a few people, not unless it's mandated by compliance/senior management. We are working on setting a minimum priority score, if it doesn't make the grade they get a thumbs down from governance. It's all math, it's very consistent and keeps people from letting passion, rather than reason make decisions (well, it helps ;) ). More fodder for the fire, happy Monday. Jack Covert Jack Covert Corporate IT Remedy Support Team Remedy Support Team Home Page http://collaborate.mckesson.com/sites/esm/remedy Remedy QA Sessions on Thursdays @ 10:30 AM PT Details on Remedy Support Team Home Page -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Monday, April 19, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters --_000_5D162195414F544CAB0A9266F71BBD3913AF334EA8PHXCCRPRD01ad_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Jason, I always try and expand the question when I answer because often the real a= nswer 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 jus= t because. Not for any clear benefit or business value, but just because it might be cool or someone hea= rd 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 tha= t 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 a= n 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 a= re for everything that is timer based. Whenever there is a choice between a filter and an active link, select filt= er is a good general rule. If something can only be done by an active link, obviously choose it. If some= thing only by a filter, choose it. But, if both, select filter (and for those cases where you want to give fas= ter feedback for something like an ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Logic in active links vs. filters
Hi Jack, I really like that idea. Would the details be something you can keep the list updated on as the process progresses? Jason On Mon, Apr 19, 2010 at 4:04 PM, Covert, Jack jack.cov...@mckesson.comwrote: Something we originally did with our governance (and are in the process of re-adopting) is to set a prioritization scheme for enhancement requests (I didn't make this up, I stole - I mean borrowed/modified this). Anyway, every factor has a numeric rating. Factors include ease of implementation (easier it is to do it the higher the priority), number of users benefited (the more people it benefits the higher the priority), whether this is mandated by compliance, senior management, etc. So if you have something that is easy to do and benefits a bunch of people, that's a no brainer. Difficult to do and only benefits a few people, not unless it's mandated by compliance/senior management. We are working on setting a minimum priority score, if it doesn't make the grade they get a thumbs down from governance. It's all math, it's very consistent and keeps people from letting passion, rather than reason make decisions (well, it helps ;) ). More fodder for the fire, happy Monday. Jack Covert Jack Covert Corporate IT Remedy Support Team Remedy Support Team Home Page http://collaborate.mckesson.com/sites/esm/remedy Remedy QA Sessions on Thursdays @ 10:30 AM PT Details on Remedy Support Team Home Page -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Monday, April 19, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters --_000_5D162195414F544CAB0A9266F71BBD3913AF334EA8PHXCCRPRD01ad_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Jason, I always try and expand the question when I answer because often the real a= nswer 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 jus= t because. Not for any clear benefit or business value, but just because it might be cool or someone hea= rd 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 tha= t 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 a= n 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 a= re for everything that is timer based. Whenever there is a choice between a filter and an active link, select filt= er is a good general rule. If something can only be done by an active link, obviously choose it. If some= thing only by a filter, choose it. But, if both, select filter (and for those cases where you want to give fas= ter feedback for something like an ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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
Re: Logic in active links vs. filters
I have an old governance doc with details on prioritization that I could send out, or once we get it re-established I can send it out... Jack Covert Corporate IT Remedy Support Team Remedy Support Team Home Page http://collaborate.mckesson.com/sites/esm/remedy Remedy QA Sessions on Thursdays @ 10:30 AM PT Details on Remedy Support Team Home Page -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Jason Miller Sent: Monday, April 19, 2010 4:25 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters --001485f90b586b4ee404849f4459 Content-Type: text/plain; charset=ISO-8859-1 Hi Jack, I really like that idea. Would the details be something you can keep the list updated on as the process progresses? Jason On Mon, Apr 19, 2010 at 4:04 PM, Covert, Jack jack.cov...@mckesson.comwrote: Something we originally did with our governance (and are in the process of re-adopting) is to set a prioritization scheme for enhancement requests (I didn't make this up, I stole - I mean borrowed/modified this). Anyway, every factor has a numeric rating. Factors include ease of implementation (easier it is to do it the higher the priority), number of users benefited (the more people it benefits the higher the priority), whether this is mandated by compliance, senior management, etc. So if you have something that is easy to do and benefits a bunch of people, that's a no brainer. Difficult to do and only benefits a few people, not unless it's mandated by compliance/senior management. We are working on setting a minimum priority score, if it doesn't make the grade they get a thumbs down from governance. It's all math, it's very consistent and keeps people from letting passion, rather than reason make decisions (well, it helps ;) ). More fodder for the fire, happy Monday. Jack Covert Jack Covert Corporate IT Remedy Support Team Remedy Support Team Home Page http://collaborate.mckesson.com/sites/esm/remedy Remedy QA Sessions on Thursdays @ 10:30 AM PT Details on Remedy Support Team Home Page -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Monday, April 19, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: Logic in active links vs. filters --_000_5D162195414F544CAB0A9266F71BBD3913AF334EA8PHXCCRPRD01ad_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Jason, I always try and expand the question when I answer because often the real a= nswer 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 jus= t because. Not for any clear benefit or business value, but just because it might be cool or someone hea= rd 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 tha= t 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 a= n 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 a= re for everything that is timer based. Whenever there is a choice between a filter and an active link, select filt= er is a good general rule. If something can only be done by an active link, obviously choose it. If some= thing only by a filter, choose it. But, if both, select filter (and for those cases where you want to give fas= ter feedback for something like an ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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 --001485f90b586b4ee404849f4459 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding
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
Re: Logic in active links vs. filters
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.netmailto: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
Re: Logic in active links vs. filters
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:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, April 16, 2010 1: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
