Overview and Technical Design Insurance Agent Portal, Pomegranate

Size: px

Start display at page:

Download "Overview and Technical Design Insurance Agent Portal, Pomegranate"

Hugo Bryant
5 years ago
Views:

Overview and Technical Design Insurance Agent Portal, Pomegranate This document describes the features and technical design of the exemplar code-named

1 Overview and Technical Design Insurance Agent Portal, Pomegranate This document describes the features and technical design of the exemplar code-named Pomegranate. This application is a SharePoint (ASP.Net) web portal for use by Insurance Agents to manger customer s policies and claims. Todd Snyder 11/07/

2 Contents Introduction...3 Application Overview...4 Dashboard View...4 Customer Details View...5 Quote and Customer Views...6 Technical Notes...6 Architecture and Technical Design...7 Technology...7 Microsoft SharePoint Service (WSS) 3.0 SP1...8 Net Advantage for ASP.NET Windows 2003 Server SQL Server Layers Design Patterns and Principals Principals MVP Pattern Adapter Pattern Repository Pattern Provider Model Pattern AJAX and SharePoint Summary

3 Introduction Pomegranate is an insurance agent portal SharePoint exemplar (Reference Application). The application is built using Windows SharePoint Services SP1, ASP.Net 2.0 and the latest version of Net Advantage for ASP.Net. The portal application utilizes a backend SQL Server 2005 (Express) database to store customer information and Key Performance Indicators (KPI). The design philosophy we used to build the exemplar was a pragmatic SCRUM approach. The application was build over the course of several small 1 to 2 weeks sprints. Each sprint focused on building out a different set of features. To help facilitate this approach we applied several design best practices including Test Driven Development, refactoring, design patterns and principals. This document Is broken down into two sections: Application Overview: Gives an overview of the different screens in the application and their features. Architecture and Technical Design: Examines the technology and design approach used to build the application. The exemplar can be viewed at the following URL: 3

4 Application Overview The applications include two main screens. A dashboard view that displays six web parts: Company News, Pending Quotes, New Policies per year, Active Polices by Type, Quote to Bind Ratio, and general agent summary. The second screen is a customer detail view that is displayed as a popup dialog when a user clicks on a one of the customers listed in the Pending Quotes web part. Dashboard View The dashboard view display six web parts that an insurance agent uses to track pending customer quotes and other customer based KPI(s). Figure 1: Dashboard View Web Parts: Company News: This web part displays the latest company news for the insurance agent. Pending Quotes: Displays a list of pending quotes for the agent s customers. New Policy per Year: KPI based web part displaying the number of new policies that the agent has sold per year for the current and last two fiscal years. Active Policy by Type: KPI based web part that shows a chart of the percent of each policy type. A user can filter the web part by adjusting the starting/ending expiration dates (Slider). 4

5 Quote to Bind Ratio: KPI based web part that s shows the current quote to bind ratio (Percent of Accepted Quotes). The user can filter the web part by selecting different types of polices.. Agent Summary: A general summary web part that displays several KPI for the agent including: # of Customers, Direct Loss, Expense, and Loss Ratio (Direct Loss + Expense / total customer premium). Customer Details View The customer detail screen is displayed when a user selects one of the customers listed in the pending quotes web part. The screen is hosted in a dialog control and it displays detail information (Bio, Polices & Claims) about a customer. Figure 2: Customer Detail Dialog 5

6 Quote and Customer Views These screens are not implemented and only exist to display additional links in the application s main menu. Figure 3: Message displayed for features not implemented Technical Notes The following Net Advantage for ASP.Net controls are used by the application: o WebDataGrid o WebChart o Web Gauge o Web Slider o Web Dialog o WebGrid (Customer Detail Screen) The active By Policy and Quote to Bind Ratio web parts use MS AJAX (Update Panels) to support dynamic live filtering of data. The user Interface (UI) has been branded using a custom SharePoint theme (CSS, Images, Etc ) 6

7 Architecture and Technical Design This section goes into detail about the architecture and technical designed used to build the application. Technology There are several technical components used to build the Pomegranate exemplar. One of the key first decisions when designing a system is to identify when to use a 3 rd party component and when to build a custom one. The approach we took was to utilize 3 rd party components to address the core features of the system and write custom code that integrated with the 3 rd party components to meet the requirements of the exemplar. Key Components Used: Microsoft SharePoint Service (WSS) 3.0 SP1 Net Advantage for ASP.NET.2 Windows 2003 Server SQL Server

8 Microsoft SharePoint Service (WSS) 3.0 SP1 WSS is a free add-on component to Windows 2003 or. It is a web application framework for building collaborate based solutions. If you need advanced features you can switch over to the Microsoft Office SharePoint Sever (MOSS). MOSS is a full blown enterprise platform that includes advanced features for content management, search, and form based solutions. The exemplar will run fine on either version of SharePoint. The main features of WSS that are used by the exemplar include site provisioning, branding, and application hosting. WSS includes additional feature that maybe used by a future version of the application including custom lists, workflows, and reporting capabilities. Once you decided to use SharePoint that are two key technical design decisions that need to be made. First, you need to determine which type of server farm you want to use and second you need to define the taxonomy hierarchy used by the site. For the exemplar we want with a simple approach for both of these: On the hosted version of the example. we are using a single server configuration and single top level site. For a more advance solution you may want to consider one of the other serve farm types and typically you will need a more advance information taxonomy. Figure 4: Pomegranate Online Server Topology References: SharePoint Deployment SharePoint Application Planning and Architecture 8

capabilities) in the Net Advantage for ASP.NET control suite.

9 Net Advantage for ASP.NET.2 The exemplar takes advance of the several of the controls and their features (data visualization, data presentation, and filtering capabilities) in the Net Advantage for ASP.NET control suite. This approach allowed us to focus on the business solution for the exemplar and harness the power of Net Advantage for ASP.NET for building application with great user experience (UX). Data Visualization Figure 5: WebChart showing Key Performance Indicators (KPI) Figure 6: WebGauge showing Key Performance Indicators (KPI) 9

10 Figure 7: WebSlider used to filter data Figure 8: Presenting data in the WebDataGrid 10

Figure 9: WebDialog displaying Customer Detail Screen Windows 2003 Server This is a required component for running Windows SharePoint services.

11 Figure 9: WebDialog displaying Customer Detail Screen Windows 2003 Server This is a required component for running Windows SharePoint services. If you prefer you could install the exemplar on a Windows server. Reference: Details about Windows 2003 SQL Server 2005 This is a required component for running Windows SharePoint services. For production systems it is recommend running the standard or enterprise version of SQL server. But, for simple solutions you can use SQL Express. Reference: SQL Server

Layers This section gives a quick overview of the logical view (Layers) of the application. The core design approach used to build the exemplar was to build out a custom web part framework.

12 Layers This section gives a quick overview of the logical view (Layers) of the application. The core design approach used to build the exemplar was to build out a custom web part framework. The framework uses the Model View Presenter pattern to separate the concerns for each web part into three components: View (Custom Web Part), Model (Custom Business Classes: Customer, Policy, Claim), and Presenter (Controller that orchestrates the communication between the view and the model). Figure 10: The design of the custom web part framework used in the exemplar. The View is responsible for instantiating its presenter. Once the view is ready it notifies its presenter; which loads the model and binds it to the view. The view is loosely coupled from the presenter because the presenter only uses the view s interface to communicate with the view. This allows the highest level of unit testing because you can create unit tests without requiring the ASP.Net process to be loaded. In addition, you can minimize the dependencies between the view and the model. Design Patterns and Principals The key to successfully building a quality enterprise based system is to utilize proven best practices and design approaches. While building the Pomegranate exemplar we utilize several industry best practices for building enterprise.net applications. This section outsides the key design patterns and design principals we followed to build the exemplar. 12

13 Principals Separation of Concerns: This is a principal where you separate the concerns for a use case into several different classes. For example the Model View Presenter (MVP) Pattern separates code into views, models, and presenters. Single responsibility principal: This is a principal where you focus on making classes have high cohesion and try to avoid overloading the reasonability of a class. Test Driven Development: This is a design approach where you write test first to help drive out the design of a system. Refactoring: This is a design technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. MVP Pattern The Model View Presenter (MVP) pattern is a variation of the Model View Controller (MVC) pattern. Both patterns promote separating the concern for a use case across three distinct types of classes: Model, Presenter (Controller), and View. The major differences between the MVP and MVC pattern is that the MVP pattern focuses more on separating the dependencies between the different components (Model, View, Presenter). By doing this you can increase the testability of the overall solution. Reference: How it s used in the Exemplar: The following code listing illustrates how the MVP pattern is implemented in the exemplar. 13

14 Figure 10: Example interface used to implement the MVP Pattern Figure 11: View (Web Part) implements interface 14

15 Figure 12: View (Web Part) instantiates its presenter Figure 13: Presenter loads the model and binds it to the view. 15

16 Adapter Pattern The adapter pattern promotes establishing a simpler interface between two components that depend on each other. This is used a lot when implementing the MVP pattern to simply the interface used between the views and its presenter. In addition an adapter pattern maybe used to consolidate communication between multi classes or hide the complexity of one class that has lot of dependencies with other components. Reference: How it s used in the Exemplar: The diagram below illustrates how the adapter pattern is used in the exemplar to isolate the presenter from the WebChart Control. By using this approach we can assign the responsibility for binding the model to the WebChart to the presenter. This will allow us to better test the behavior of loading data from the model into the chart. When the unit test is created the presenter will talk to a mock chart adapter that will simulate the process of creating data series and data points on the chart. The purpose of the test is to validate the presenter can handle binding the model to the chart (via its adapter). Figure 14: Adapter pattern used to separate the presenter from underling control type used by the view. 16

Repository Pattern The repository pattern is a data access pattern that promotes loosely coupling the domain model for a solution from its data sources.

17 Repository Pattern The repository pattern is a data access pattern that promotes loosely coupling the domain model for a solution from its data sources. The main goal of the pattern is to act as an in memory data repository that uses data mapper type classes to load data into and out of the domain model. By using this approach you can achieve a higher level of persist ignorance; which will increase the overall testability of your code. In addition you can easily handle adding additional data sources or changing data access technology (e.g. from ADO.Net to LINQ or NHibernate) you use without impacting the core of your system. Reference: How it s used in the Exemplar: The diagram & code listing below illustrate how the repository pattern is used by the exemplar. Because most of the data used in the exemplar is read only we went with a simply repository implementation that mapped ADO.Net data readers/data commands to and from our domain model. Note: The adapter pattern was used to wrap the standard ADO.Net classes (Connection, Command, Parameters, & data readers). This allowed us to better unit test the mapping code used by the repository. Figure 15: Key classes used by the exemplar to implement the repository pattern 17

18 Figure 16: Example of a repository mapping a data reader to a domain model. Provider Model Pattern The provider model pattern promotes loosely coupling components in a system using the concept of dependency injection (DI). Dependency injection is used to separate dependencies between one or more components. Instead of two components having a hard reference between them; components rely on a DI container to inject the dependency at runtime. For the exemplar we are using the built in DI capabilities of the.net framework that use reflection to load a configured provider up when an application loads. Reference: 18

19 How it s used in the Exemplar: The diagram below contains the key classes used by the exemplar to implement the provider model. The exemplar has a portal data provider that is used for accessing the customer KPI(s) data. The data provider used is configured in the exemplars (SharePoint) web.config. This approach allows us to easily support additional data sources in the future without requiring major changes to the application. Figure 17: Classes used to implement the provide model pattern. Figure 18: Entry in web.config used for defining the portal data provider 19

20 AJAX and SharePoint One the biggest technical hurdles to overcome when working with SharePoint is integrating AJAX. AJAX is a powerful technology that allows a web application to talk back to its host server without requiring full page post backs. By utilizing the Microsoft ASP.NET AJAX Extensions 1.0 toolkit it is pretty easy to integrate AJAX capabilities into an ASP.Net application. Unfortunately, getting the MS ASP.Net Extensions to work easily with SharePoint is a real challenge. The major differentness between getting AJAX to work with SharePoint and a normal ASP.net application is that as a developer you do not create or have control over the pages used in SharePoint. Instead a developer typically builds one or more custom web parts that are hosted on the same SharePoint page as other web parts. These other web parts may have been created by Microsoft or some other 3 rd party vender. Because in most cases your custom web parts maybe running alongside other 3 rd party web parts you do to careful consider how and when to use AJAX. The approach we took with the exemplar was to limit using AJAX to only web parts that support filtering. The first thing we had to do to make AJAX works was to create a custom default.master page that contained an ASP.NET AJAX Script Manager control. This control is required to run the ASP.NET AJAX extensions and the Net Advantage for ASP.Net Aikido controls. Since we are using a custom master page we can guarantee the any page we want to host web parts will already have the necessary Script Manager control. To minimize the effort in getting AJAX to work with SharePoint we setup the custom web parts to use an ASP.NET AJAX Update Panel. The update panel allows us to do partial page rendering which works pretty well with some caveats. The major caveat with using update panels is that the page post backs still occurs and all of the web parts on the page will go through the complete ASP.NET page lifecycle. When the ASP.NET page life cycle is complete only the result HTML for the web part that made the AJAX call will be returned to the web browser. To work around this the custom web parts we built check to see if they caused the AJAX call. If they did they perform their normal operation; if they did not they skip processing. 20

21 Figure 20: Entry in web.config used for defining the portal data provider Summary The Pomegranate exemplar is a great reference application that shows how to build custom web parts that run inside of SharePoint. This document outlined the approach we took for building out the application as well as how we were able to utilize Net Advantage for ASP.Net to enhance the capabilities of the SharePoint platform. 21

10264A CS: Developing Web Applications with Microsoft Visual Studio 2010

10264A CS: Developing Web Applications with Microsoft Visual Studio 2010 Course Number: 10264A Course Length: 5 Days Course Overview In this course, students will learn to develop advanced ASP.NET MVC