Kevin,
You say:
"Filters fire on submit into SHR:NOT-Notifications which refresh the table
field and then loop through the table sending notifications using the
Notify action....."
It may just be how you phrased it, but if you are accessing a table via filters (server-side tables), there is no need (or easy way) to refresh the table. Perhaps there are some performance gains to be had there?
Thad
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry
| "Kevin R. Carmack"
<[EMAIL PROTECTED]>
Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 09/20/2006 06:23 AM
|
|
Hello all,
Sorry for the long post, but it is necessary to fully explain the issue.
Any ideas as to how I can accomplish the management requirement listed
below would be much appreciated!
REMEDY SERVER ENVIRONMENT:
2 W2K3 SP1 servers with dual 2.8Ghz procs/4GB RAM
ARS 6.3 p17 configured as server group
ITSM 6.0 (HelpDesk mod only)
Mid-Tier 6.3 p17
DATABASE ENVIRONMENT:
Oracle 9.2 running on UNIX server
ARSPRD01 is one of several databases on this server
MANAGEMENT REQUIREMENT:
Support staff should be able to customize their notification preferences.
Notification options should be: None, E-mail only, SMS only, Email & SMS
They should be able to choose one of the above options for each group of
which they are a member and for each priority level for HelpDesk tickets
(Low, Medium, High).
MY ORIGINAL IDEA (that doesn’t work):
Create a form to store each user’s notification preferences (SHR:NOT-
Preferences). For example, user USERJOE is a member of GROUPA. He may
choose to receive no notifications for Low priority tickets, E-mail only
for Medium tickets, and SMS only for High tickets. This would create 3
separate records for his user ID and GROUPA.
When ticket is created in HelpDesk form, filters push fields needed for
notification to notification form (SHR:NOT-Notifications), including the
HTML template to use. For example, we have a template for each of the 10
out-of-the-box notification filters that come with HelpDesk. The
templates are numbered to match the original filter names.
There is a table field on this form that displays notification preferences
from SHR:NOT-Preferences. This is based on a table field qualification
that loads records from SHR:NOT-Preferences where the priority and group
are equal. Qualification is as follows:
( 'optStatus' = "Enabled") AND ( 'optPriorityLevel' = $optPriority$) AND
(( 'chrGroupName' = $chrAssignedGroup$) OR ( 'chrGroupName' =
$chrPrevGroupLogin$) OR (( 'chrFullName' = $chrAssignedIndividual$) AND
( 'optNotificationType' = "Individual")) OR (( 'chrFullName' =
$chrPrevAssigneeFullName$) AND ( 'optNotificationType' = "Individual")))
Filters fire on submit into SHR:NOT-Notifications which refresh the table
field and then loop through the table sending notifications using the
Notify action based on the user’s preference. There are 20 filters—1 for
e-mail and 1 for SMS for each of the 10 out-of-the-box notifications. The
filter qualifications follow this format:
('chrMailTemplate' = "hpd_sup_grp_n04") AND (( 'colNOT-Method' = "E-mail
Only" ) OR ( 'colNOT-Method' = "E-mail & SMS" ))
If that qualification is TRUE, then use the e-mail template called
hpd_sup_grp_n04 and send it to the e-mail address found in colNOT-
EmailAddress from the table field.
('chrMailTemplate' = "hpd_sup_grp_n04") AND (( 'colNOT-Method' = "SMS
Only" ) OR ( 'colNOT-Method' = "E-mail & SMS" ))
If this qualification is TRUE, send e-mail to address found in colNOT-
SMSAddress from the table field. No template is specified and there is a
view on the form called ARNotification which contains only the fields
needed for SMS, in the proper order.
PROBLEMS WITH THIS IDEA:
It is very slow. On our development server, it takes 30 – 4 0 seconds to
save a ticket where before, it only took 4 – 5 seconds. The first time I
tried to develop this solution, I had everything running off the HelpDesk
form and it was taking over a minute to save a ticket. Secondly, it’s
always sending the notifications to the same address—one for a user who’s
not even in the group to which the ticket was assigned. Filter logs do
not indicate how or why this happening.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
***IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.***
