Before we get into the nitty gritty details of how RT is put together, let's take a quick look at the RT layer cake and see what we get out of each layer. Figure 8-1 shows the layers and how they fit together.
Behind everything that RT does, there's an SQL database. This database stores all of RT's data and metadata. Some SQL databases provide their own procedural languages that allow developers to implement large applications entirely inside the database. This has the disadvantage of tying an application tightly to a specific database engine, such as MySQL or Oracle. RT takes a different tack, using the database as a datastore. Because of this, RT is able to run on top of a number of different database engines, each of which has different strengths. RT works to make sure that data stored in SQL is relatively easy to query using other tools, though we strongly recommend that you not alter the database by hand.
Perl's DBI is the standard SQL Database Interface for Perl programs. It defines an interface that various and sundry database drivers (DBDs) implement in a largely consistent manner. In addition to MySQL, Postgres, and Oracle, you'll find DBD modules that let you talk to LDAP, flat text files, and even Google as if
Figure 8-1. The RT layer cake
they were SQL databases. If you come from the Java world, you can think of DBI as Perl's equivalent to JDBC.
DBIx::SearchBuilder is the secret sauce that lets an object-oriented application like RT talk to a table-oriented relational database. SearchBuilder presents a simple object-oriented API to Perl programs and translates those API calls into SQL statements tuned for the specific database. A row from any given database table can be accessed via a subclass of DBIx::SearchBuilder::Record. To search for and work with sets of records all at once, RT provides a Collection class for each database table, which is a subclass of DBIx::SearchBuilder itself.
RT application platform libraries
Until now, we've only talked about RT as a ticketing system. Once you start looking at the architecture and APIs, you'll quickly discover that there's a whole application platform under the hood in addition to the ticketing system.
RT's application platform libraries are the guts of RT. They provide database connectivity, logging infrastructure, users, groups, access control, links, and a few other bits. While the ticketing system uses the RT application platform, it's not the only application that does so. RTFM[*] is a knowledge-base tool that uses the RT application platform to implement an entirely different application.
[*] The RT FAQ Manager. It doesn't mean anything else, really!
RT ticketing system libraries
RT's ticketing system libraries use the RT application platform as a base to provide tickets, transactions, attachments, custom fields, and queues. The ticketing system defines groups and access control rights and a type of link that teaches the application platform how to deal with links between ticket objects.
The Mason handler is one of many possible applications that runs on top of the RT Core libraries. It provides a wrapper around the Mason templating system.[*] Mason is conceptually similar to ASP, PHP, or JSP, but for Perl.
[*] Dave Rolsky and Ken Williams's Embedding Perl in HTML with Mason (O'Reilly) is the canonical source for everything about Mason.
RT comes with two main sets of Mason templates out of the box: user interface templates, which are designed for end users to interact with their browsers, and REST templates, which are designed to be easy for other software to interact with. As of version 3.4, the REST templates are designed to present information in RFC822 format, which anything can parse.
Right now, the Mason templates for the RT application platform and RT ticketing system are very tightly integrated, but moving forward, the templates are changing to improve how they are broken out.
RT has three HTTP clients: a web browser, the email gateway, and the command-line interface. Most users interact with RT using their browsers. RT's email gateway is a tiny Perl script that your mail server runs every time an email message destined for RT comes in. The email gateway, in turn, dispatches the message to your RT server over HTTP or HTTPS. It waits around for the RT server to confirm receipt of the message and then exits.
RT's command-line interface is a web browser. But not like you're imagining. The CLI communicates with RT over the web, using the same authentication system as the rest of RT, so you can use it from anywhere that you can use RT's web interface. Like any other web client, it uses GET and POST to download from and upload to your RT server.