Brian, The filters fire on the Remedy server that kicks off the transaction. So if you are running imports, the filters are firing on the server you are importing on, in the case of Escalations that kick off Filters, they are firing on the same server the Escalation is firing on.
Certainly, if you bypass filter workflow the speed improves, but you don't get the advantage of the filter workflow. Integrations should normally be fired against backend servers to reduce the impact to the users on the server. If your filters are taking too long, I would recommend running a log analysis against the SQL that's firing in the filters to identify if there are any places where Indexes are needed that don't currently exist....that could certainly speed things up....but as you said, you could defer workflow processing to a 'later time' and have escalations fire on it....but at that point you have data that's not 'verified' through workflow to have passed all of the business rules sitting in the system waiting till a deferred time frame...not sure if you want that either...I would say your best bet is to fire the workflow on import, but ensure that it's optimized properly to prevent undue delays....but it's not my system :) On Fri, Jan 12, 2018 at 11:55 AM, Brian Pancia <panc...@finityit.com> wrote: > Where do filters fire in a server group and can this be controlled? I'm > assuming they fire on the server the user is attached to at the time. What > about when an escalation triggers a filter. Does the filter fire on the > same server as the escalation, which could then be controlled in the server > ranking form. I never gave much thought to this. I'm sure some basic > logging will give me the answer. However, looking to see if anyone has > experience with this in a server group. This is looking at performance > enhancements to integrations and data imports that could have a lot of > updates, which could definitely impact the system(s). This seems to have > more of an impact at the application layer rather than the database layer. > > > One scenario I am looking at now is that 1 million records are imported > into the system that may update multiple records throughout the system > based on various conditions. If I fire the filters on import, the import > could take a long time. If I surpress the filters then the import runs > fairly quickly given the number of records somewhere around an hour for 1 > million records. I could hold off on firing the filters until a time when > utilization is low in order to have minimal impact on users. On import a > record could say I need to update Bob, Sue, Kim, and Steve with the > information or any combination. I'm sure an option is to have Bob as the > keeper of info and have the others periodically check in with Bob through > escalations in order to minimize filter firing. It still leaves me > wondering were do filters fire and can this be controlled. I've always > stay cleared of too many escalations. However, when your dealing with > large data does it make sense to chunk it into buckets using escalations > instead of running filters? > > > Thanks > > > Brian > > > DISCLAIMER: The information contained in this e-mail and its attachments > contain confidential information belonging to the sender, which is legally > privileged. The information is intended only for the use of the > recipient(s) named above. If you are not the intended recipient, you are > notified that any disclosure, copying, distribution or action in reliance > upon the contents of the information transmitted is strictly prohibited. If > you have received this information in error, please delete it immediately. > > -- > ARSList mailing list > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
