Just a few more pieces of info on this for posterity... A filter level Set Fields that pulls from a schema that has a Get Entry filter will NOT trigger that Get Entry filter. However, an active link level Set Fields (that pulls from a schema that has a Get Entry filter) WILL trigger the Get Entry filter.
This makes perfect sense to me, in that the AL's Set Fields is going to use the ARGetEntry API (which we know triggers these Get Entry filters). However, it's just something to keep in mind when setting these up. -c On Fri, Feb 21, 2014 at 1:01 PM, Misi Mladoniczky <[email protected]> wrote: > Hi, > > An ACTL is triggered by the user, and definitely involves the browser. If > it > needs to access data on the server, it naturally goes to the mid-tier and > then > to the server and then to the DB and back again. > > I use GetEntry filters a lot, as it removes a bunch of roundtrips to the > server involving latency etc. along each trip. > > If something is very rarely used by the client, you can always do it in > ACTL:s, but if something is commonly needed when retrieving a request, it > is > good to use GetEntry filters. > > The ServiceCall is also a very nice thing. On one roundtrip to the server > you > can do a bunch of things within an ACTL ServicecCall. > > Best Regards - Misi, RRR AB, http://rrr.se > > > 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" > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "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"
