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"
