2012-1Q: Request Tracker (RT) Integration

SIMPLer has been updated to interface to a "Request Tracker" (RT) server to allow mainenance issues (CI) in SIMPLer to be transferred to RT, and to allow RT to close the corresponding CI when an issue is resolved in RT.

More information on RT, installation instructions, etc may be found on the Best Practical RT site: http://bestpractical.com/rt/

The sections below cover the setup required on the RT server, the configuration in SIMPLer and the operation of this feature.

RT Server


    • A working Linux based RT server. The operator is responsible for installing and configuring their own RT server (e.g. adding users, queues, etc). Azotel have some limited experience in installing RT on CentOS, and can provide assistance if required.

    • The RT server must be accessible from the SIMPLer server - i.e. either a public IP is required, or else, if necessary, an OpenVPN tunnel will need to be configred between the RT server and the SIMPLer server.

    • An RT user account will be required to allow SIMPLer to use the RT API to create tickets in the RT system. The username and password will be added to SIMPLer below.

    • SIMPLer API credentials (username / password for the SIMPLer API) - Azotel will supply these.


    • Azotel will supply the scripts which need to be installed on the RT server in order to allow it to communicate with SIMPLer over the SIMPLer API. Installing the scripts will require root shell access to the RT server and a login to the RT web page with admin privledges. The operator may choose to do this work themselves, or can give Azotel access to the server in order to carry out the work.

    • Once the scripts have been installed, edit the file /opt/azotel/etc/rt.cfg to configure the API access. The parameters should be set as follows

      • SERVER - this is the IP address of the SIMPLer server. This is only required to be set if SIMPLer and RT communicate over a tunnel - otherwise the scripts will determine the correct server IP from the RT ticket.

      • USER - the SIMPLer API username supplied by Azotel

      • PASSWORD - the SIMPLer API password supplied by Azotel.

    • Install the Perl SOAP::Lite module using the command "cpan SOAP::Lite" - this module is used to communicate with the SIMPLer API.

    • Create the queues (e.g. admin, sales, engineering, etc) on the RT server, and note their names as they will need to be added to SIMPLer below.

SIMPLer Server


    • The RT interface is configured under Settings -> Modify WISP. In the SIMPLer Settings section there are 4 new fields relating to RT:

The fields should be set as follows:

  • RT Auto Create Tickets: If set to "yes" SIMPLer will automatically push tickets to RT whenever a suitable CI is created, or the type of an existing CI is updated to a suitable type. "Suitable" CIs are any CI where the maintanance issue type is mapped to an RT queue (see below). If this field is set to "no", SIMPLer will never automatically push CIs to RT, but they may still be pushed manually.

  • RT Username / RT Password: The username / password SIMPLer should use for accessing the RT API - this is the username/password created in the RT section above.

  • RT Server URL: The URL of the RT server - for example http://your.company.com/rt

    • The mapping of SIMPLer CI types to RT queues is done by going to Cusomers -> Maintenance Type

This form allows you to add/delete/modify maintenance types, and also to map each maintenance type to a corresponding queue in RT. Where no mapping exists (i.e. the RT queue field is blank), CIs of that type cannot be pushed to RT. For example in the sample below, CIs of type "accounts" will be pushed to the RT "General" queue, while CIs of type "administration" will be pushed to the RT "admin" queue. As the "RT queue" field is blank for CIs of type "azotel", these CIs cannot be pushed to RT.


Once configured, CIs will either automatically be pushed to RT - if the WISP "RT Auto Create Tickets" option is set to "on" - or can be pushed manually by selecting the new "Push to RT" checkbox before adding or updating a CI. Note that this checkbox will only appear once the RT interface is properly configured in an instance. Note also that selecting this checkbox for a CI type which is not mapped to a RT queue will result in no action being take.

Once a CI has successfully been pushed to RT, it will be "locked" in SIMPLer and it will no longer be possible to update the CI via the web interface - A link to the RT ticket will be included at the top and bottom of the Modify Maintenance Issue page, and the normal Update/Delete buttons will be replaced with a message informing the user that the issue is now being tracked in RT:

The Resolution section of the CI in SIMPLer is also updated to record who transferred the CI, and when it was done:

The information pushed from SIMPLer to RT includes the customer/equipment/site details, details of the SIMPLer user who transferred the issue, the SIMPLer issue type, the SIMPLer problem description and any data in the SIMPLer problem resolution field. This data may be seen as the first "History" entry for the ticket in RT:

Once the issue has been resolved in RT, RT will use the SIMPLer API to close the corresponding SIMPLer maintenance issue. The Resolution section of the maintenance issue is updated to record who closed the RT ticket, and which queue it was closed in.

Azotel | River House | Blackpool Park | Cork | Ireland

US +1-312-239-0680 | IE +353-21-234-8100 | UK +44-207-193-4170 | SA +27-11-083-6900