Request Tracker/RTx::AssetTracker at DigitalGlobe

Transcription

1 Request Tracker/RTx::AssetTracker at DigitalGlobe Introduction This document explores the process of implementing an enterprise Help Desk/Asset Management system at DigitalGlobe. This includes a discussion of how the software was chosen, the features of the software, customizations, reporting and asset management. Background Request Tracker is an open-source Help Desk Management product which is available from Best Practical Software ( Request Tracker has an install base at over sites around the world and provides many features which are only available in proprietary COTS applications, e.g. TrackIt, Remedy, etc. Request Tracker has been in use at DigitalGlobe since July, 2002 and one year ago there were processed tickets in the database. However, the older release of the software had many limitations and several alternatives were being explored in the fall of However, the release which DigitalGlobe is now using had many new features which made Request Tracker a viable product for continual use at DigitalGlobe. The new features included: 1. Addition of custom fields for ticket categorization. 2. A new and cleaner user interface. 3. Some reporting capabilities via the add-on extension RTx::Statistics. 4. The Asset Management extension called RTx::AssetTracker. 5. Improvements in the database structure to increase performance. 6. The ability to link tickets and to link tickets to assets and assets to assets. 7. Improved API which allows for easier creation of add-on modules. Because of the added features, and DigitalGlobe already had an investment in Request Tracker, it made logical sense to continue using Request Tracker with the added features. Also, the added feature of custom fields, reporting and asset management increased the viability for this product. Finally, remaining with Request Tracker reduced the need for training and additional effort which would have been required if DigitalGlobe moved to a different product. Implementing Request Tracker V3 and RTx::AssetTracker After a short design stage for the desired custom fields and queues for Request Tracker tickets, it was a short three week effort to get a prototype of Request Tracker operational. This stage included implementation of Apache V2.0.55, MySQL , mod_perl2, Perl 5.8.6, approximately 100 Perl CPAN libraries and Request Tracker Best Practical provided a tool to convert the old Request Tracker database to Request Tracker V In addition, the RTx::AssetTracker and RTx::Statistics modules were also included in the implementation. Finally, a detailed document was created to describe the entire upgrade/implementation process. The installation guide was essential for a successful upgrade of Request Tracker. During the prototype testing phase, a replacement Help Desk system was constructed and the same software products were implemented on the new system. One of the major tests was running the database conversion in the prototype environment, which provided us with an estimated time to convert the database to the new environment. By using the prototype environment, and relaying on the installation guide, we were able to migrate to the new version of 1

2 Request Tracker, with the converted database, in approximately 4 hours. This conversion occurred on 21 December, 2005, and except for a few minor issues, went flawlessly. The second phase of the project was to implement RTx::AssetTracker. This effort mostly required defining custom fields, asset types, asset categories and standards. RTx::AssetTracker essentially was an empty slate, so we had the ability to create an entire Asset Management system from the ground up. In addition to defining the environment, developing custom fields, etc., there were improvements made to RTx::AssetTracker which were for the benefit of DigitalGlobe. These new additions included: 1. Scripts to collect configuration information from UNIX/Linux systems. The scripts would report on changes made to a UNIX/Linux asset and had the capability of various asset custom fields, as appropriate. 2. We created a number of spreadsheets to initially load our assets. The spreadsheets matched the record layout for our assets, including the custom fields. Once the spreadsheets were scrutinized and data verified, a script was created to load the data into the database. The data load script allowed us to load approximately 500 assets in less than 5 minutes. 3. Adding a feature which can display links between assets in a graphic format. This was useful for pictorially representing links between assets. Using a phased approach, RTx::AssetTracker was completely implemented by 1 April, The final phase of the project was to create a decent reporting environment. Using RTx::Statistics and user contributed code, we were able to create several reports for the benefit of IS management and staff. The reporting system includes: 1. Web based reports which display open, resolved, rejected and stalled tickets, by Request Tracker queues. A feature was added to also display the number of tickets opened at any given day in time, called Queue Depth. 2. A spreadsheet version of the report above is generated and ed to the IS Director on a monthly basis. 3. A text file version of the report above, so it can be ed on a weekly and monthly basis. This reports is ed to the IS Management Team. 4. A text file report, which is sent to each member of IS, lists tickets each IS team member has opened (working on). 5. A consolidated text file report listing each IS team member s opened tickets, by Request Tracker queue. This report is ed to the IS Management Team. 6. A text file report lists the number of tickets resolved by each IS team member, within each Request Tracker queue. This report is ed to the IS Management Team. 7. A spreadsheet is generated which lists the number of assets by DG string and several asset type metrics. This report is sent to the IS Director. Also, a text based reports is generated at the same time which lists assets which may have incomplete records. The reporting phase involved creating reports on an on request basis and the report development; therefore, most of the report creation effort was completed in October,

3 Issues Encountered Generally, Request Tracker been running smoothly and there was little difficulty with implementing, customizing or with day-to-day use of the application. However, there were some issues which made making customizations rather challenging. These issues include: 1. Lack of technical documentation provided by Best Practical. 2. For what documentation that does exist, it is limited in scope. 3. Within the Request Tracker provided Perl libraries there is limited documentation concerning the use of various library functions provided within the software. 4. Programming reports or new functions proved challenging because of the limited documentation available. 5. The Request Tracker user support mailing proved useful for about 70% of the questions posed to it; the remaining 30% going unanswered. These issues did not prevent implementation of the customizations, but they did increase the time for completing a programming task. As for operational issues, we have had an ongoing problem with sometimes tickets not being written to the database. After extensive research, it was determined that this problem was caused by an assumption made within the Request Tracker software. The assumption made is that if an individual is logged into Request Tracker, the software assumes the user has a connection to the database to perform a transaction. However, if their network connection is disrupted (moving a laptop for example), then MySQL will close the MySQL connection. Then, when the user attempts a write transaction to the database, they will not be able to create a new ticket, because they no longer have a database connection. Unfortunately, Request Tracker does not verify that a valid MySQL connection is active and will process the transaction, sending out notification , etc. The end result is that the ticket never was written to the database, which forces the requestor to reenter the ticket. To deal with this issue, a warning was placed on the main Request Tracker web pages to warn users to log out of Request Tracker, before relocating their laptop. Finally, one of the major drawbacks to Request Tracker is it lacks the ability to support required custom fields and it cannot verify data entered into custom fields. In a future release this capability will only be available to privileged users and not the general user community. DigitalGlobe has implemented Request Tracker so we do not have to provide Request Tracker accounts to every user. If we did, then from a security standpoint, we would have to maintain privileges on a per user basis to limit what an individual can and cannot do it the software. Because of the maintenance overhead, we chose a model which allows users to enter tickets via a non-privileged Request Tracker account. However, in the next release required custom field and custom field checking is not available to unprivileged users. We are addressing this issue by creating a Web cgi form which will provide the user a method to enter tickets, but also be required to enter values in required custom fields. A prototype is now available and could be implemented in the near future. 3

4 Request Tracker Internals As mentioned previously, Request Tracker is a web based Help Desk Management System. It has the capability to take input from both web forms and via . Interface The interface is very simple. A user mails a ticket to a designated Help Desk address. An alias is set up in /etc/alias on the Linux host running Request Tracker to direct the ticket to the desired queue using the Request Tracker provided tool call rt-mailgate. When Request Tracker receives the ticket, it will place it in the proper queue and send out a notification to the requestor and to IS staff members who are responsible for designated Request Tracker queue. Web Interface In the case of the web interface, the software becomes more decisively complicated. The user logs into Request Tracker either as a regular user or a guest user. They enter the information they desire for the ticket content and submit the ticket for processing. Request Tracker will insert the ticket in the proper queue and via rt-mailgate send out a notification to the requestor and to IS staff members who are responsible for designated Request Tracker queue. The Complexity of Request Tracker Request Tracker is implemented using a multi-tiered model. At the lowest level is the MySQL database. The Perl CPAN Library DBI::SearchBuilder is used to communicate directly with MySQL and the Request Tracker database. The next level above, Request Tracker employs a series of Perl libraries which communicate with DBI::SearchBuilder. On the next level above, the Perl::Mason library is used to communicate between the web interface and the appropriate Perl Library. Perl::Mason, on the next level, is a library which caches Perl code in order to increase run time performance. Because Perl is an interpretive language, Perl::Mason s ability to cache Perl code to allow it to run as near executable speeds. The Perl::Mason environment interoperates with the Apache web server and the mo2_perl extension, on the next higher level. Finally, at the top level is the Request Tracker web interface which interfaces with Apache and mod_perl2. 4

5 The following is a model of what is described in the previous paragraph: Conclusion This short paper has summarized what has been accomplished over a year long process. It briefly discussed the history behind Request Tracker at DigitalGlobe. It discussed the upgrade of Request Tracker, the implementation of RTx:AssetTracker and the implementation of reporting. It further discusses issues encountered with the implementation and finally describes the internal structure of Request Tracker. Additional information about Request Tracker/RTx::AssetTracker is available at \\cofs1\bu\ops\is\documentation\request Tracker-AssetTracker (Helpdesk) and at 5