I like that. Nice and clean. Cheers Ben -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Grooms, Frederick W Sent: February-10-12 19:59 To: [email protected] Subject: Re: Escalation trigger filters without modifying records?
Another way I have seen people keep things like this in sync is to use a Join form The New Form "Problem Ticket/User Join" would Outer Join Problem Ticket and User on ProblemTicket.UserID = User.USerID. It would also have First and Last Name from Problem Ticket and from User. Your Escalation would run against this join where: ProblemTicket.FirstName != User.FirstName OR ProblemTicket.LastName != User.LastName OR ProblemTicket.UserId = $NULL$ On Finding a record that meets the criteria you would Push a flag to ProblemTicket to have it update the fields needed. This is an approach I have used when I am trying to keep User info in sync with an external system (I have a View Form of the External table) Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Brien Dieterle Sent: Friday, February 10, 2012 12:25 PM To: [email protected] Subject: Re: Escalation trigger filters without modifying records? Thank you all for the feedback. I should have also mentioned that modifying the records for "no reason" is really at the core of the issue, so the "modified by" field is a side-issue. Also, normalization versus denormalization-- it is confusing but as far as I understand it you would normally start with normalized data and then add denormalization for performance or, in this case, because that's what AR System encourages. That is my goal, to have a fully normalized data structure with the added denormalized data "on top". So I'd like to try to run through what Ben has suggested here on an example, and see if I understand what he's saying. Let's say I have a Problem Ticket form: FirstName LastName UserID(ForeignKey) ProblemInfo And I have a User form with: UserID(PrimaryKey) FirstName LastName So if I follow Ben's suggestion I would add some logic on the Problem Ticket form to "diagnose" whether the Userinfo has changed instead of just arbitrarily doing a "set" operation for all records. So I create two display-only fields on Problem Ticket and set Disable Change Flag = True? FirstName LastName UserID ProblemInfo ZTrigger (display only, disable change flag) ZCompare (display only, disable change flag) So my escalation can set ZTrigger = $timestamp$ to trigger the on-modify filters without actually modifying the record? Assuming that is technically possible, then I could have On-Modify filters that do the "diagnosis": Do a set-fields ZCompare = Firstname (from User Form). Then another filter w/ qual: If ZCompare != DB.FirstName, set-fields Firstname = ZCompare. Then do the same thing with LastName via a filter guide, I suppose. Fred's suggestion of triggering updates on the source-side (User) actually seems to make the most sense, although David suggests that might be a performance problem. If a single update to a user record has to go update 5,000 records across multiple forms, that might be a problem. Although that could be changed to just run off-peak anyway via an escalation (but now you can't compare DB to TR and so you'd have to store previous values in extra fields, or a set a generic sync flag field? Doh!). I think I must just have a tendency to try to keep workflow self-contained and not "creep" onto other forms. Actually, that is not the only reason, I just remembered that, quite often, we allow arbitrary input and then we want to link it later. For instance with the Problem Ticket we might take Firstname and Lastname before there is ever a User account, so UserID is NULL. The only way to resolve these is to have an escalation attempt to link it to the User record at a later time (via first and last name). So if Ben's suggestion works, that would be nice to avoid the excessive updates. I'm also thinking of another workflow where a form "waits" for a record to be created in another system. Right now I have an escalation trigger a modify to perform a "check" to see if that record has been created yet in a view form, and once it finds a match it moves on to the next task. Again that would be nice to avoid modify updates for just a "check". I think I'm done rambling, thank you again I'll post back if I successfully can trigger the on-modify filters via an escalation without actually modifying the records using the tips Ben suggested. Brien On 2/10/2012 8:12 AM, Ben Chernys wrote: > What Fred is saying is avoid the escalation by including your > normalization at time of save or in his second case at time of save of > another form (with a non AR_ESCALATOR user). (Sorry Fred. Just > wanted to make that a bit clearer). > > The ONLY way to modify a record without changing the fields modifier > and modified time is through the Merge API which is not doable by > workflow. It is certainly doable with other methods like a > Meta-Update script, your own code in a "binary" etc. > > ARS always performs the save when fields that set the "dirty bit" are > set - even if they are set to the same value. > Ie: db.f = 1; set fields f = 1; modification made. > > By rewriting your filters to diagnose that there are no changes rather > than arbitrarily setting values to equal values, and by turning off > the "Modified" flag on your trigger field, or by turning off the > dirty bit at the end (a new filter that compares the fields you are > modifying with the db.fields and if no changes turns off the dirty bit). > > This would still leave AR_ESCALATOR on those records that really were > changed but (presumably) not on all records. > > Meta-Update by default does not issue the modify when nothing has changed.. > So certainly you would be able to do this with Meta-Update no problem. > You also do not run into the filter limit. > > Cheers > Ben Chernys > > Senior Software Architect > Software Tool House Inc. > > Canada / Deutschland / Germany > Mobile: +49 171 380 2329 GMT + 1 + [ DST ] > Email: Ben.Chernys _AT_ softwaretoolhouse.com > Web: www.softwaretoolhouse.com > > Check out Software Tool House's free Diary Editor. > > Meta-Update, our premium ARS Data tool, lets you automate your > imports, migrations, in no time at all, without programming, without > staging forms, without merge workflow. > http://www.softwaretoolhouse.com/ > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Grooms, Frederick W > Sent: February-10-12 04:03 > To: [email protected] > Subject: Re: Escalation trigger filters without modifying records? > > If your "normalization" happens on every save of the record then are > you having to run thru them on a schedule to update them because > something somewhere else changed? > > i.e. If you are setting a Name field in Form AAA on save, are you > trying to keep that Name field in sync with a Name somewhere else (like on Form BBB)? > I would look at trying to detect when the source of Name (Form BBB) is > changed and force the related records (Form AAA) to update at that time. > > Fred > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Brien Dieterle > Sent: Thursday, February 09, 2012 6:13 PM > To: [email protected] > Subject: Escalation trigger filters without modifying records? > > I've got a lot of filters that do some "normalization" by setting some > key fields via a lookup. This might be a bad idea, but I generally > create escalations that do some tidying up-- they just blast through > all the records and update a trigger field to trigger the modify filters. > Having all the records "last modified by AR_ESCALATOR" is starting to > irritate some of my colleagues, so I'd like to stop doing this. Any > thoughts? I've tried several ways to get an escalation to trigger the > modify actions without actually modifying the record-- without any success. > I also definitely do not want to duplicate the code in the modify > actions and copy them into the escalation. > > Thanks! > > Brien ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
