On Monday, May 10, 2004 2:37 PM
Matthias Eichler
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