On Monday, May 10, 2004 2:37 PM
Matthias Eichler <[EMAIL PROTECTED]> wrote:
>>> I want some integration that the monitoring server does
>>> not sends mails, but opens new tickets, inserts follow-
>>> ups and also closes tickets (on recovery of a problem, e.g.)
>
>> Despite the latter, this weren't a problem. OTRS' core function
>> is to open up tickets on receival of new emails and add follow-ups
>> to existing ones, ie. track tickets.
>
> But therefor I need a stage between the monitoring server which
> notifies about a problem, a (to code) application which analyses
> these notifications and holds a state for rewriting the notification-
> mails, so OTRS can recognize a follow-up.
So you're thinking of s.th. similar to this?
a) "I'm server A, I'm down" -> OTRS creates Ticket#123
b) "I'm server A, I'm still down" -> OTRS creates a FollowUp to
Ticket#123
c) "I'm server A, I'm up" -> OTRS closes Ticket#123
This were tasks to be performed the time the email is received. See
below.
>> Closing tickets via email isn't impossible at all, but requires
>> coding.
>
> But GA is a good way for this, isn't it?
No, it isn't, as GA doesn't receive a mail. It were the PostMasterFilter
or Procmail you need to configure.
>>> - does the GenericAgent can create new tickets at all,
>>> or does the GenericAgent is always based on already
>>> existing tickets?
>> No, GA can't, and yes, GA can. GA runs on existing tickets, but
>> you may well run shell scripts from within GA, from within you
>> may send an email which opens up a new ticket, if you want.
>
> Do you mean I create a search pattern in GA on which GA will
> never find any ticket and then running a shell script? Or would
> GA not run the script when not finding any existing ticket?
> Because if it just works when finding a ticket it wouldn't make
> sense to let GA send a new mail, when a mail was already received
> by OTRS before...
To repeat, GA doesn't receive a mail and requires a ticket to work on.
In opposite to that, GA can also start shell scripts of your choice -
these can perform whatever you like and need not rely on a ticket.
>> Use Procmail (or your mail server directly) or the lightweight,
>> but integrated version: OTRS' PostMaster::PreFilterModule
>> capabilities. grep Kernel/Config/Defaults.pm for them.
>> You are allowed to set X-OTRS-headers from within Procmail or the
>> PreFilter modules.
>
> That sounds very good for me!
> Maybe I just let the monitoring server write the important
> criteria (like system hostname, notification status, into the
> X-OTRS-headers).
Go, go, go! ;)
> Then the PreFilter would search through these
> infos and sorts depending on the X-OTRS-headers and creates a
> follow-up or closes a ticket depending on these infos.
The PreFilter cannot close a ticket (as long you don't use a shell
script again), he only sets certain headers. If you set these headers
via the Monitor, you need no PreFilter nor Procmail anymore.
What's still open: How do you inform the webserver about the ticket
number? You will have to let him know "his" ticket number, otherwise
you'll end up with what you have: Every eMail creates a new ticket.
One might think about a "single-ticket" solution, ie., if a customer
(webserver) has an existing ticket, every incoming eMail will be
regarded as being a Follow-Up to that existing ticket.
Another idea were to write a new PostMaster module that scans an email
and recognizes the monitor's output. We're moving towards an asset
management or similar, I believe.
Regards,
Robert Kehl
--
((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg
http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
_______________________________________________
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Support oder Consulting für Ihr OTRS System?
=> http://www.otrs.de/
