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"
