RT - Java connection

RT Developers
1

Hi,

We are currently looking into RT and would like to connect it to a
web-application written in Java. The idea is to maintain full RT
functionality as a standalone ticketing system, but also be able to
query RT and manipulate tickets from our own Java-based web interface.

We considered three options for connecting the two applications:

  1. Direct calls to Perl methods
  2. SQL interface (our application already communicates with MySQL)
  3. Using RT’s command-line interface (CLI)

Java-Perl interfaces seem to be rather poor and cumbersome, unlike the
pretty good C/C+±Perl connectors out there, so we’ll probably skip
option 1. Between the other two, it seemed the CLI should offer a more
consistent interface, less prone to future changes than internal
database table structure. Is that a valid assumption?

There was one particular problem we came across with the CLI - we didn’t
find a way to search and/or alter custom fields from the command line. I
read all the documentation I could find and searched the mailing lists,
but most of the stuff I found was pretty outdated. Can someone enlighten
me on the status of that issue in the current release?

Thanks in advance for any inputs,
Tuvik

Tuvik Beker
Soligence Corporation

2

Hi,

I have also been looking for a good way to connect a java (J2EE) application
to RT and came across two potentially promising options;

  1. The REST interface - which looks like it implements similar commands to
    the CLI interface but uses HTTP POST commands
  2. The SOAP interface - which has been used for integrating with the open
    source Asterisk PBX. I heard this was in the process of being updated -
    but saw no more about it.

Obviously the REST and SOAP interfaces would be better as they could be used
from a remote JAVA application without having to use native calls to the CLI
or Perl code.

Unfortunately having searched intently, I found that neither interface is
documented and it’s quite hard to work out what they do or how to use them
from the code. Ideally I don’t want to have to learn all of the internals of
RT before I can use an API. They are not mentioned in the new O Reilly RT
Essentials book. So I to was wondering whether there was a strategic
commitment to keeping these interfaces current in RT and where I could go to
get a run down ( examples?) on how to use them.

Thanks
Craig
University of Southampton-----Original Message-----
date: Wed, 07 Sep 2005 12:11:40 -0500
From: Tuvik Beker Tuvik@Soligence.com
Subject: [Rt-devel] RT - Java connection
To: rt-users@lists.bestpractical.com, rt-devel@lists.bestpractical.com
Message-ID: 1126113100.27983.151.camel@localhost
Content-Type: text/plain

Hi,

We are currently looking into RT and would like to connect it to a
web-application written in Java. The idea is to maintain full RT
functionality as a standalone ticketing system, but also be able to query RT
and manipulate tickets from our own Java-based web interface.

We considered three options for connecting the two applications: 1. Direct
calls to Perl methods 2. SQL interface (our application already communicates
with MySQL) 3. Using RT’s command-line interface (CLI)

Java-Perl interfaces seem to be rather poor and cumbersome, unlike the
pretty good C/C+±Perl connectors out there, so we’ll probably skip option

  1. Between the other two, it seemed the CLI should offer a more consistent
    interface, less prone to future changes than internal database table
    structure. Is that a valid assumption?

There was one particular problem we came across with the CLI - we didn’t
find a way to search and/or alter custom fields from the command line. I
read all the documentation I could find and searched the mailing lists, but
most of the stuff I found was pretty outdated. Can someone enlighten me on
the status of that issue in the current release?

Thanks in advance for any inputs,
Tuvik

Tuvik Beker
Soligence Corporation

3

Hi Craig,Tuvik,
I’ve gone through this troubled search-and-find quest at length and here
is what I can tell you about my experience:

  1. There isn’t any.
  2. The SOAP interface you may have come across was, last I knew, still
    unstable and unreliable as well as unsupported.
  3. The REST interface does work and is unlikely to change, but is poorly
    documented.

For my own solution I did go the REST route using httpclient-commons
library from Apache for basic HTTP connection support, the
authentication is via form-authentication ONLY, not standard HTTP/Auth
(although I’ve heard rumors that was coming), and the data you send back
and forth for the multipage-formdata is not what you think - it’s one
key/value pair where key is “content” and value contains a large string
of key/value pairs parsed by colons (:slight_smile: and newlines by the RT-REST
interface.

Hope that helps - unfortunately for my project I just have it hacked
together to get it to work and don’t really have decent code examples to
offer, but at least the above lessons should help you move forward much
faster.

-D

4

Hi,

We are currently looking into RT and would like to connect it to a
web-application written in Java. The idea is to maintain full RT
functionality as a standalone ticketing system, but also be able to
query RT and manipulate tickets from our own Java-based web interface.

We considered three options for connecting the two applications:

  1. Direct calls to Perl methods
  2. SQL interface (our application already communicates with MySQL)
  3. Using RT’s command-line interface (CLI)

Java-Perl interfaces seem to be rather poor and cumbersome, unlike the
pretty good C/C+±Perl connectors out there, so we’ll probably skip
option 1. Between the other two, it seemed the CLI should offer a more
consistent interface, less prone to future changes than internal
database table structure. Is that a valid assumption?

There was one particular problem we came across with the CLI - we didn’t
find a way to search and/or alter custom fields from the command line. I
read all the documentation I could find and searched the mailing lists,
but most of the stuff I found was pretty outdated. Can someone enlighten
me on the status of that issue in the current release?

Thanks in advance for any inputs,
Tuvik

Option 4. Use the RT REST or RTx::Atom interfaces. This avoids the
problem with possible changes to RT API/schema in option 2. Also
should perform better than option 3 unless you can reliably make
the CLI persistent, which probably wouldn’t be that hard.

-Todd