Hi Peter,

The best way you can implement this probably by writing a small
event-based module.

See chapter 2.2.1.3.6.4 Ticket Event Module in the Developer
documentation: http://doc.otrs.org/developer/3.0/en/html/x655.html#AEN657
(the chapter numbering is a bit wonderful at the moment, I don't
really know what caused that)

You can pretty simply create a small piece of code that does
*something* on for instance a TicketCreate or ArticleCreate event, of
course you'd want to restrict it to only run if CustomerID has some
specific value or so. Write the module and add a small snippet of
config and you'd be good. It is then relatively easy to at least move
the configuration to the SysConfig, so not everything's hardcoded.

--
Mike

On Sat, Dec 18, 2010 at 12:52 PM, Peter Eckel <[email protected]> wrote:
>
> Hi,
>
> I am rather new to OTRS, and I'm faced with a challenge I could, so far, not 
> find any existing solution for (maybe I'm just looking in the wrong place).
>
> I want to integrate OTRS in an existing system and network monitoring 
> environment. Most, if not all, of the tickets will be generated automatically 
> by our monitoring applications (OpenNMS, Hyperic HQ, Syslog NG with SEC), and 
> creating, updating and closing them via SOAP::Lite works just fine. So 
> getting the tickets *into* OTRS in principle will not be the problem.
>
> Getting notifications for tickets out of OTRS is the culprit. We are working 
> for a number of customers, and while for some it's fine to handle 
> notification via E-Mail internally by our staff, there are some that have 
> different requirements. The most important case is one customer who needs to 
> get copies of the tickets (or at least some of the tickets' contents) via 
> SNMP inform using a custom notification MIB. Implementing the SNMP inform is 
> not the issue, the interface is already working since last year, but without 
> the interaction of OTRS. OTRS should, however, be in the chain, because it is 
> problematic that we don't have the OTRS ticket ID in the customers' data so 
> we can't associate our tickets with the information the customer can give us 
> when they refer to them.
>
> What I need now is a way to generate very specialised notifications about new 
> or updated tickets from OTRS, e.g. using the SNMP inform mechanism that I 
> implemented as an interface to that customer's ticketing system.
>
> I currently see two obvious ways this can be implemented: As a custom 
> notification type in OTRS (the most general case would probably be an 
> interface to call external scripts, but if there's a more elegant solution it 
> would be appreciated as well), or using E-Mail notifications to a functional 
> mail account that will process the mail automatically and create the SNMP 
> informs from their contents.
>
> For reliability's sake I would prefer a solution as simple and as closely 
> integrated into OTRS as possible, e.g. using a custom notification type, but 
> without having a closer look at OTRS' internals I cannot tell how much effort 
> that would be. Of course it would be even better to have some kind of 
> notification hook that can be used to insert that kind of integration.
>
> Any hints to documentation, sample code or maybe better ideas on how to do it 
> (as I said, I'm fairly new to OTRS) are highly appreciated.
>
> Thanks in advance,
>
>  Peter.
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
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

Reply via email to