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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
