Some weeks back there was some discussion on rt-devel regarding remote-control
of RT via SOAP or some other mechanism …
I’m writing to state that I was able to establish a working RPC link between
our monitoring system (MON) and RT 2.X (from CVS) using SOAP::Lite.
If anyone else is interested , a brief overview follows.
If there is sufficient interest, I can provide the actual MON/RT files
at some later date… There are some security concerns that should
probably be addressed (or at least acknowledged) before anyone
goes installing this type of setup in production.
What i did
Installed SOAP::Lite PERL Module
Wrote a custom PERL module (RT/RPC/SimpleRT.pm) , which
exports a simplified ticket creation routine (create_ticket)
to the remote application.
In this way the complexity of the RT API is hidden behind
a very simple interface.
The RT/RPC directory is then auto-dispatched by Apache::SOAP
via httpd.conf . This is a very clean approach as it requires
zero on-disk configuration for providing SOAP HTTP transport.
This RPC directory can (and will be used by us) also be used
to provide much more complex RT-RPC interactions at a later
time.
Finally, i wrote a MON alert in PERL to create tickets in
our tracking database for network events. The RT specific
code for that looks something like this:
Last but not least…
use SOAP::Lite +autodispatch =>
uri => ‘urn:/SimpleRT’,
proxy => ‘http://<OUR_RT_SERVER>/SOAP’;
my $s = SimpleRT->new();
[ snip ]
my ($id,$resp) = $s->create_ticket($queue,$subject,$own,$ops,$msg);
thats all
Well, thats my overview. I’d been putting off sending this
email for a while now , so i’ll hit send right now.
best,
_Michael.
[ Note that i had to rebuild my mod_perl apache for Apache::SOAP to
work properly (ie: not segfault!). This was due to some type of
conflict with the expat library (or something like that) .
The configure directive i used follows
./configure \
"--with-layout=Apache" \
"--prefix=/usr/local/apache_modperl" \
"--activate-module=src/modules/perl/libperl.a" \
"--disable-rule=EXPAT"
So yeah, I would be rather interested in this. Go fig.
It’s something I’d been hoping to look at for the 2.1 development series. If
you’ve got a foundation I can work with, even if it’s not done,
that would be really cool
-jOn Tue, Nov 20, 2001 at 04:39:46PM -0500, Michael wrote:
Greetings.
Some weeks back there was some discussion on rt-devel regarding remote-control
of RT via SOAP or some other mechanism …
I’m writing to state that I was able to establish a working RPC link between
our monitoring system (MON) and RT 2.X (from CVS) using SOAP::Lite.
If anyone else is interested , a brief overview follows.
If there is sufficient interest, I can provide the actual MON/RT files
at some later date… There are some security concerns that should
probably be addressed (or at least acknowledged) before anyone
goes installing this type of setup in production.
What i did
Installed SOAP::Lite PERL Module
Wrote a custom PERL module (RT/RPC/SimpleRT.pm) , which
exports a simplified ticket creation routine (create_ticket)
to the remote application.
In this way the complexity of the RT API is hidden behind
a very simple interface.
The RT/RPC directory is then auto-dispatched by Apache::SOAP
via httpd.conf . This is a very clean approach as it requires
zero on-disk configuration for providing SOAP HTTP transport.
This RPC directory can (and will be used by us) also be used
to provide much more complex RT-RPC interactions at a later
time.
Finally, i wrote a MON alert in PERL to create tickets in
our tracking database for network events. The RT specific
code for that looks something like this:
Last but not least…
use SOAP::Lite +autodispatch =>
uri => ‘urn:/SimpleRT’,
proxy => ‘http://<OUR_RT_SERVER>/SOAP’;
my $s = SimpleRT->new();
[ snip ]
my ($id,$resp) = $s->create_ticket($queue,$subject,$own,$ops,$msg);
thats all
Well, thats my overview. I’d been putting off sending this
email for a while now , so i’ll hit send right now.
best,
_Michael.
[ Note that i had to rebuild my mod_perl apache for Apache::SOAP to
work properly (ie: not segfault!). This was due to some type of
conflict with the expat library (or something like that) .