Hi Fred, So, interesting...I was thinking that the AL's pulling that data were fired directly in the user's browser, so there would be three legs: browser to mid-tier, mid-tier to ARS, and ARS to DB. Are you saying that those AL's are actually executed by the mid-tier? I really don't yet know enough about the division of labor between the mid-tier and the browser.
The $CLIENT-TYPE$ idea is excellent. Thanks. -charlie On Fri, Feb 21, 2014 at 11:52 AM, Grooms, Frederick W < [email protected]> wrote: > ** > > Yes we are using them here. > > > > You are describing exactly the reason to use the Get Entry filters. (Actually > the User Tool pulling the data in an Active Link is the same as Mid-Tier. > Client to ARS, ARS to DB) > > > > If you are worried about it being pulled when it is not being used by a > visible user you can use the $CLIENT-TYPE$ to only have the filter fire > when you want it to. > > > > Fred > > > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Charlie Lotridge > *Sent:* Friday, February 21, 2014 1:44 PM > *To:* [email protected] > *Subject:* Get Entry filter trigger - request for opinions > > > > ** > > Hi all, > > > > In some 20+ years of doing Remedy development, if I've written 2 filters > that use Get Entry as a trigger, that's a lot. I've just never found any > significant reason to use the mechanism. But now I'm having second > thoughts. > > > > So, first, I'd like to get an idea...does anyone use Get Entry filters? > Does ITSM (I've never really worked with it)? If so, what are the use > cases for this? > > > > Now on to my own new potential use case: If a user (of an application I've > written) opens a form on some entry that has foreign keys, and assuming it > makes sense to do so, I'll pull descriptive information from the foreign > form into local display fields. So, for example, if we have a one-to-many > from Customer to Invoice, and the user opens an Invoice, I'll use the > Customer ID on the Invoice to pull maybe the Customer Name into a local. > Nothing new here and I'm sure every application does this to some degree. > > > > Historically I've done this using active links. With the heavy client > User Tool, this approach has always made the most sense to me. For one > thing, if the active link was being invoked, I could be sure a user was > actually going to see the pulled data (the active link only would fire if > the user were opening the record), so the effort was not wasted. For > another, since the User tool was more tightly coupled than the mid-tier, > the requests and replies didn't have to hit the wires so many times (2 > round-trips for each request: User tool to ARS, ARS to DB). > > > > I've only recently moved up from v7.1 to v8.1, and only with this change > have I really started using and adopting the mid-tier. So I'm relatively > new to thinking about how to best and most efficiently use it. Given, > though, that it introduces both additional processing and an additional > round-trip (mid-tier to ARS), I'm now wondering if I should adopt a > different approach to pulling this foreign descriptive data. Specifically, > I'm wondering if I should instead have Get Entry filters set up to pull it > on the entry's way "up from" the database to the user. > > > > The upside of this approach is that it'll be much quicker for the > transactional user who is opening these entries individually (and for whom > this foreign descriptive data is intended). The downside of course is that > this data will potentially be fetched every time the entry is retrieved, > whether or not it'll be seen by any user or not (e.g. reporting, API > programs, etc.). > > > > A quick aside: I just ran a quick test to discover that while the > ARGetEntry API certainly does invoke Get Entry triggered filters, the > ARGetListEntryWithFields API does not. So this may not be as bad as I > thought since, at least, a query list on the form (which uses > ARGetListEntryWithFields) will not invoke these filters. It's true that > any kind of automation or reporting tool that processes on an > entry-by-entry bases WILL invoke these filters, but this is probably the > exceptional situation and well worth the enhanced user experience. > > > > Well, after about an hour of writing this email and doing the research, at > this point I'm pretty much convinced that Get Entry is the way to go for > this. But I'll send this out anyway to maybe provoke some Friday afternoon > conversation. I'm still curious if & how people use Get Entry filters. > > > > Thoughts? Comments? > > > > -charlie > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
