GSG’s needed an easy way to understand what all the data their system was providing meant. Their main challenge was finding a system that suited their unique business requirements. It had to be easy to use, flexible and highly customizable.
Company URL : http://www.gsga.net
Product Version used : 2009.3 1211 Trial
Operating System : Windows Server 2008 Web Edition
Database Platform : SQL Server 2008 Web Edition
Number of developers involved : 2
Development Time : 2 Months
Challenges and Objectives : Approximately 5 years ago, GSG identified the need for a softwaresolution that would meet the needs of its unique business requirements.After evaluating several of the shelf solutions, GSG was unsatisfiedwith its finding and sought out to create its own software that wouldhandle all facets if its operations. Within one year GSG launched VCMS,a web based case management and utilization review software applicationthat has converted all of its manual and paper workflow into avirtualized environment .With the majority of the development efforts concentrated on end-userinterface, database development, and process workflow, there was a majorfeature that VCMS had been lacking: an easy way to find out what thedata was telling us. We understood that clients and management had anincreasing need to extract the information available into meaningfulreports.Shorthanded on time and resources, all reports were ad hoc, put togetherin excel linked to SQL queries, and not user friendly. Often times,these reports were long, inefficient and difficult to keep track ofsince people were making changes to them. There was no standardizedformatting, no charts or graphs. Reports were datasets thatthe end-user needed to analyze and summarize to meet their needs.This was a very inefficient way of doing things and wemade it our first priority to create a reporting module that would allowour end-users to run reports from a single location. The requirementswe set for ourselves where:
- Easy to use
- Create a user interface with the ability to handle reports dynamically
- Able to export reports in different formats
- Controlled by organizational, role, and user permissions
- Did not require us to recompile the entire website to update reports (compiling the report library was OK)
- Ability to load reports dynamically
- Ability for different users to use the same report with different parameter inputs and values
- Accessible from the main VCMS web application
Given our experience with Telerik’s Ajax controls and their ease of use, we were excited to start our reporting project using Telerik Reporting.
Solution : Telerik Reporting became a choice for us because we felt that, if this was as easy to use as Telerik’s Ajax controls, then the learning curve would essentially be flat and we could concentrate more on developing reports rather than designing them. The features that really gave us the head start we needed was the Reporting's UI and exporting feature. As mentioned above, our requirements were to load the reports dynamically, have the same reports presented differently to different users, and have the ability to export reports in different formats. We were prepared to design a user interface that would load the parameters dynamically based on the report being loaded, yet to our surprise, this feature was already built into Telerik Reporting. We then created a permission model to help control the visibility of report parameters and set their default values based on the user running the report. Next we wanted to ensure that reports would be retrievable and loaded using the same user interface and the same code without needing to write endless if..then select case statements to handle the characteristics of each report. Instead, we created a super class that implemented a common interface and had all of our reports inherit from the super class. As a result, we were able to load each report dynamically using the System.Reflection namespace and have a predictable way of instantiating each report. As part of the reporting logic, we created a report helper class object that contained the reports user and role permissions as well as the default parameter behavior. This helper class was passed to the dynamically instantiated report and used in the reporting logic to control user permissions and default parameter behavior. We ran into difficulty with reports retaining their instance level property values but we soon found a work around by using a combination of shared and session variables. Once the presentation UI logic was completed, we relied on Telerik’s easy to use report designer to create great looking reports. Our experience with Telerik’s ajax controls left us little to learn when binding a table, setting styles, and adding meaningful charts. The export feature allowed us to export reports into different formats without needing to purchase any third party utility.
Results : The results were incredible: we were able to design an easy to use web based interface with reports that were easy to understand and meaningful to different users. Reports are consistent with the same look and feel and, most importantly, are reproducible. We can add reports without needing to recompile our entire site or make special accommodations to our user interface. Using Telerik Reporting, we were able to hit all of our requirements while cutting our development time by at least 75%.