James,
This is to allow you to, for a specific field,
1) Determine programmatically if a (user or automated) transaction has
attempted to change the field value or not . OR -
2) Compare what the value used to be, just before the current
transaction attempted to change it, as opposed to what it is being changed to.
A good example of a use case for this is if you have a business rule
requirement that neither users nor other systems or processes integrated to
your form are allowed to change the Status of a record from "Assigned" to
"Closed", because you want them to set it to "Resolved" first, because;
1) You have other workflow and/or SLA's and/or reports that depend on
the Status.History.Resolved.TIME to be populated. OR -
2) You have a quality control process that determines that a different
group of users pick up the "Resolved" records and phones the customer back to
find out if they are happy with the resolution and only then is the record to
be set to Status = "Closed".
In either of these cases, you would implement these business rules quickly and
easily through the relatively simple creation of a single Filter that Checks if
'TR.Status' = "Closed" AND 'DB.Status' != "Resolved" and returns an error.
If you only use Status = "Closed" in this filter run if, you will end up with
the filter getting triggered for updates that legitimately set Status =
"Closed" as well.
If you used an active link on Return/Menu Choice/Lose Focus of the Status
field, sure, you would prevent your users from making an invalid change, but,
any Filter Push Field or API integration update would still manage to do the
invalid update because active links don't get triggered on that level.
Sure, you can achieve the same result by adding lots of Temp fields doing
set-fields from the database to get the "old DB value" for your fields, but
this starts to get very messy if you;
1) Have multiple business rules that require you to do this type of
comparison on multiple fields. (You could potentially end up duplicating almost
all your fields on the form doing things this way).
2) Have to deal with confused user questions as to which field should
we believe to hold the actual value for their reports if the fields are named
similarly to avoid programmer confusion.
3) Have to add extra filters to do a relatively expensive and redundant
second lookup on the database to find the "old DB value" for a field - which
only serves to slow down your system.
4) Forget to change the lookup field attributes if the actual field
attributes has been changed.
Therefore, the need for Transactional (TR) and Database (DB) values on filter
level.
HTH.
Best Regards,
Theo
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of James Smith
Sent: 08 May 2014 17:22
To: [email protected]
Subject: Transactional (TR) and Database (DB)
Hi List,
We can achieve things without using TR and DB values in a filter by just using
Field but I do not understand why they have been developed to use? I have heard
from many remedy developers like Misi and BMC who suggest not to use TR and DB
in Run If qualification of a filter but why?
Why it is not recommended to use TR and DB values?
What if I use TR.Field=DB.Field? Will it yield a correct result? In BMC
documentation also they have not given any example where they used TR and DB
together in a qualification.
Appreciate your thoughts!
Cheers,
James
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers
Are, and have been for 20 years"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
