Support Center 3

Features

• Duplicated our existing database without database access, by querying our webserver and storing the information
• Allowed faster viewing of information by caching the database locally
• Automatically updated local database upon reaching webserver and finding newer information
• Fully replaced all functions of existing webserver, including ticket entry, which was sent through the webserver with javascript
• Interfaced existing database with PRTG, a third party software that monitors network equipment. This included dealing with name discrepancies, as the systems were not linked
• Included many helpful troubleshooting tools, such as automatic pings to equipment, and massively sped up various tests compared to using the webserver
• Allowed users to login to equipment with one click, without having to enter credentials

Here's a GIF showing most of the features on a test site

Challenges

• No database access - without access to the database, I had to create my own, basically. I used javascript to login to our system through a virtual browser. I then found that if I disable javascript on this 'browser', I could view the entire property list on one page. I used this to get phone numbers (a unique identifier). Once I had this list, I could run searches through our old system using this list and save data from each entry. I stored all of this in objects, and once it was finished I serialized them all and saved to a text file. The process took many hours to run initially.
• Potentially outdated information - Once I had this records file, upon startup if the file was detected, it did not parse the entire database again since it takes so long. In order to make sure information was updated, each time a page is loaded in the software it reaches out to the original system and tries to open the page to update the record. Once it has reached the page it refreshes the software view and shows the new information. If this is used regularly, the changes will generally be minor or obvious, and the initial information is displayed until the page is updated - this means the technicians can begin troubleshooting immediately even if there were minor changes to the system. Also, if the changes were major, generally the old information will all show offline and it will be clear that updates are pending - and generally within 5-10 seconds the page would refresh and show the new information
• Too much information - During the parsing process, I only took the basic and most important information from each site, but I did not gather Tickets, because each site has hundreds and this would have been too much to parse. As you can see in the GIF, it takes quite a while to load tickets - this is indicative of the speed of the legacy system. When a site loads in my software, it attempts to load information from the legacy site from the list of tickets for the property. When a specific ticket is expanded, it then tries to load that specific ticket. Loading all of this information without it being requested would be inefficient, but unfortunately this means there is still a delay when trying to view a ticket. This was necessary because there is no way to view ticket details for more than one ticket at a time in the legacy system
• Pinging - You can see in the GIF I have pings to Google, ToS (the employer's terms of service page), and in the bottom left Modem and GW. These were very difficult to implement because pinging is generally OS-specific, and Java by definition is not. This means the program only works properly on Windows, at the moment
• Multithreading - This was a challenge because so many things are loaded when a property is opened, they had to be multithreaded. Additionally, when a property is loaded it checks the status of all equipment, which also had to be multithreaded. I had to refactor the program at one point to ensure all multithreaded instances can be run synchronously without any issues. I could not multi-thread the initial parsing process, however, because this would require multiple simultaneous logins to the legacy system which it did not allow
• Layout - Java is special, and its layouts are ... not very fun. I still did not end up with it looking exactly how I wanted, but it scales well with window sizing and the GUI was basically 'good enough' for me at the time. This was developed in 2014 and I now have higher standards for front-end design
• Auto-generated legacy system - Probably the toughest challenge was finding ways to reference the fields I needed from the legacy system, because it was auto-generated. This means sometimes the field I wanted had a random text string as a class, name, or ID - or sometimes it was arbitrary, like with tickets. I had to put a lot of effort into workarounds for many of these, or ways to detect the information without knowing the element it is in, particularly with tickets
• Bugs - But not just mine. In the legacy software there were many unpredictable bugs that would sometimes cause accessing a page to fail repeatedly for a period of time. This is why I included a metric to show successes vs attempts; I found a way of accessing the pages that was reliable using this along with some retry attempts.
• Poor Design - Yes, this time mine. I initially displayed responses by printing to console, not realizing that an actual user would expect the text to output in the 'window' for the software. I found a way to hook the system.out stream and write a custom display function for it instead of replacing all instances where I'd used it