Michael:
You're thinking what designers of ITSM 7 thought. They
built a "notification engine", which is nothing but a
set of ARS forms and workflow that work more or less
like you describe.
You can easily build something a lot simpler on your
own. I built something similar from scratch for ARS 6.
Would work for 7 as well.
Axton has the right idea. External() in filters' 'Run
If' qualification as well as special commands such as
Application-Parse-Qual-Filter,
Application-Map-Names-To-Ids,
Application-Map-Ids-To-Names are the key...though I
don't remember exactly which ones I used.
At a high level, the workflow went like this:
1. On Submit or Modify on a, say, Help Desk, form a
filter looked up "notification rules" from a form
applying to this form and for this operation.
Loop around for each matching rule, each time in the
loop retrieve a rule's firing criteria, run a filter
with External() in Run If to test for that criteria,
and have the filter submit a record to "notification
queue" including field values from the Help Desk
record.
2.Run an escalation on the "notification queue" form
to process the notification queue. Escalation triggers
filters that lookup details of the notification rule
(who to notify, with what message, thru what method
etc)
The filters construct the message based on the message
template (which would have templates like "You have
been assigned ticket {ticket number}" ) by
substituting placeholders such as {Field Reference}
with values. If individual notification, push a record
to "notification log" form which keeps a log of the
notification and also causes the right notification to
go out.
If a group notification, push to a form (say,
notification group memberships) that stores a record
for each membership (has group name and member name).
The push field would modify all records for that group
name. From this form, push to the notification log
form, which will cause the notification to go out.
There are a lot of details you need to work out and
caveats as well, but I would imagine that much of what
I describe above will be fundamental logic of any
design. Including ITSM 7's notification engine.
If you are interested in more detail, let me know.
--- Axton <[EMAIL PROTECTED]> wrote:
> Not crazy at all. I practice this as much as makes
> sense. It has
> some really great advantages:
> - better control over what is sent to the db in
> terms of queries (performance)
> - better control over the layout and look of the
> interface (data
> presented does not have to be sourced from a single
> table)
>
> It also has some drawbacks:
> - maintenance of the active links to show data
> (though there are some
> approaches that can mitigate this, but this too has
> some catches)
> - users can not execute open queries into the data
> (you control
> through the interface what can be queried)
>
> If you've worked with Oracle Forms, Access, or any
> other type of
> form/business logic/code type of interface, this is
> actually the
> standard approach. In terms of writing scalable,
> usable applications,
> it is a good practice to separate the data model
> from the presentation
> layer. While there is some added complexity to this
> approach (vs the
> typical remedy approach), there is also greater
> flexibility to be had.
> Someone once told me, with great power comes great
> responsibility.
>
> Axton Grams
>
> On Nov 8, 2007 1:41 PM, Durrant, Michael M. - ITSD
> <[EMAIL PROTECTED]> wrote:
> > **
> >
> > I'm toying with the idea of using regular forms
> for data storage only and
> > using display forms for all user interactions.
> while I realize this entails
> > more "coding", I think I would have a greater deal
> of control over behavior
> > of the user interface. Has anyone tried this
> already? Am I crazy for even
> > thinking about it?
> >
> > Thanks,
> >
> > Michael Durrant The information contained in this
> email may be privileged,
> > confidential or otherwise protected from
> disclosure. All persons are
> > advised that they may face penalties under state
> and federal law for sharing
> > this information with unauthorized individuals.
> If you received this email
> > in error, please reply to the sender that you have
> received this information
> > in error. Also, please delete this email after
> replying to the sender.
> > __20060125_______________________This posting was
> submitted with HTML in
> > it___
>
>
_______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at
> www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where
> the Answers Are"
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
