Please ignore the previous post. Replied to the wrong
thread.
Regarding this thread, if you go down this path, watch
out for that fellow "TR". If you use it in filter run
ifs, it'll drive you crazy, to say the least.
--- Rabi Tripathi <[EMAIL PROTECTED]> wrote:
> 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
>
__________________________________________________
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"
