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:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: February-10-12 04:03
To: arslist@ARSLIST.ORG
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:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle
Sent: Thursday, February 09, 2012 6:13 PM
To: arslist@ARSLIST.ORG
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"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
