Technical Architecture Document

Technical Architecture Document

Table of Contents

1. Introduction 4

Purpose 4

Scope 4

Technical Architecture Reviewer : Lav & Manu 5

Audience : Team 5

Acronyms, Abbreviations, Terms and Definitions 5

2. Design Overview 5

2.1 Approach 5

2.2 Architectural Goals and Constraints 5

3. Topology Diagram 6

3.1 Data Architecture 6

3.1.1 Approach 7

Separate Database, Separate Schema 7

Pros 7

Cons 7

3.1.2 Goals and Constraints 7

3.1.3 Data Architecture Topology 7

4. Application Architecture 8

4.1 Presentation Layer 8

4.2 Common Layer (Eduquer.Common Layer) 14

4.3 Data Access Layer (Eduquer.DataAccess Layer) 17

5. Deployment Process 19

6. Reference Urls 20

Revision History

Version Date Description Author

1. Introduction

ABC is a software services company that has more than 11 years of software building experience. ABC has come forward to build an ERP application (product) for managing schools, which are run based on different boards and mediums of education. This product aims at addressing all the processes involved in school administration.

This document provides a high level overview of the evolving technical architecture for XYZ ERP. It outlines the technologies that XYZ ERP members will use for broad collaboration and participation in a distributed network for Professional Education System. In facilitating interoperability through standards, XYZ ERP will help its members enhance education expertise, promote professional collaboration, and raise the level of student care.

PurposeTo build a technical framework for XYZ ERP that’s developed and hosted by the SaaS vendor and

which the end user customer accesses over the Internet.

ScopeThis architecture is scoped to facilitate the development of software which is subscription based.

All the upgrades are provided during the term of subscription. The application is hosted and updated on a central location and does not reside on client computers.

Technical Architecture Reviewer :

Audience : Team

Acronyms, Abbreviations, Terms and Definitions

ERP Enterprise Resource Planning

SOA Service Oriented Architecture

SaaS Software as Service

DAAB Data Access Application Block

EHAB Exception Handling Application Block

LAB Logging Application Block

2. Design Overview

2.1 Approach

Using Enterprise Architecture with well-defined interfaces provide business functionality which can be discovered and accessed through a supportive infrastructure.

This offers the following advantages when compared to traditional approach Offer business service across the platforms Provide location independence Provides the ability to build composite applications. Creates a self-healing infrastructure that reduces management costs. Lower costs associated with the acquisition and maintenance of technology. Allows internal and external system integration as well as the flexible reuse of application logic

through the composition of services.

2.2 Architectural Goals and Constraints Reuse and composition The ability to incrementally build the system. Centralizes application control, making the development of application simpler. Increase opportunities to optimize the application. To Provide a way to assign developers with specific skills to specific components for better

productivity.

3. Topology DiagramThe system comprises of a multi-tier architecture.

The Eduquer Architecture is having different layers. Classified as

Eduquer Presentation Layer

Eduquer Web

Eduquer WebPortal

Eduquer Mobile

Eduquer DataAccess Layer

Eduquer Common Layer

The following diagram shows the different layers of the system.

Figure 1 – A: Different layers of Eduquer V1.0 Application

Data Stores

Basic DB Universal Client DB

3.1 Data Architecture

3.1.1 Approach

Separate Database, Separate Schema

Storing tenant data in separate databases is the simplest approach to data isolation.Computing resources and application code are generally shared between all the tenants on a server, but each tenant has its own set of data that remains logically isolated from data that belongs to all other tenants.

Pros

Metadata associates each database with the correct tenant, and database security prevents any tenant from accidentally or maliciously accessing other tenants' data.Giving each tenant its own database makes it easy to extend the application's data model (discussed later) to meet tenants' individual needs,Restoring a tenant's data from backups in the event of a failure is a relatively simple. Cons

Cost:

This approach tends to lead to higher costs for maintaining equipment and backing up tenant data. Hardware costs are also higher than they are under alternative approaches, as the number of tenants that can be housed on a given database server is limited by the number of databases that the server can support.

3.1.2 Goals and Constraints Data Isolation Data Security Backup and Restore Cost

3.1.3 Data Architecture Topology

4. Application Architecture

4.1 Presentation Layer

Description of each layer of Edquer Application

Client (Users) :The Client layer would consist of a web client like Microsoft Internet Explorer 8 +,Firefox & Safari.

Presentation Layer (Eduquer .Web)

Presentation Layer consists of following components:

User Interface(UI) components:The user interface components(controls) provide the users to interact with the application.They render and format data for users and acquire and validate data coming in from them.

The presentation Layer contains the components that are required to enable user interaction with the application. This layer is implemented as the Eduquer.Web Web project in the Eduquer.sln solution file.

The Eduquer.Web layer is the UI layer of the whole application. In this framework the presentation uses ASP.net pages as the UI. The asp.net pages follow the page-controller architecture and thus have a controller for every page. This is achieved by having a code-behind class for each page. The highlights of this pattern are as follows

Takes advantage of framework features.

The page controller functionality is built into ASP.NET and can be easily extended by connecting application-specific actions to the events exposed by the controller. It is also easy to separate the controller-specific code from the model and view code by using the code-behind feature.

Can exploit new features of ASP .net 3.5

Can exploit various properties of server controls

Technologies such as Asp.net Ajax can be integrated with ease

Can also incorporate facilities provided by front controller with some design trade offs.

Master page

All the pages inherit from a common Master page, hence the design is consistent and throughout the pages, also any changes to master pages is reflected in all the pages hence the flexibility is evident. All the common controls and Ajax UI etc are placed in the master pages and hence it is a common placeholder for the controls.

Navigation controls

All the navigation in the system is dynamicall driven and is easily configurable.

Open Source DllsAJAX Control Toolkit Release Notes - September 2009 Release Version 3.0.30930 -The ASP.NET AJAX Control Toolkit is an open-source project built on top of the Microsoft ASP.NET AJAX framework. It is a joint effort between Microsoft and the ASP.NET AJAX community that provides a powerful infrastructure to write reusable, customizable and extensible ASP.NET AJAX extenders and controls, as well as a rich array of controls that can be used out of the box to create an interactive Web experience. The AJAX Control Toolkit contains more than 30 controls that enable you to easily create rich, interactive web pages.

Third Party DllsTelerik Control-Telerik RadControls for ASP.NET AJAX includes more than 60 controls with proven reliability that help you build high-quality, professional line of business web applications

Dundas Chart for .NET-With AJAX, Dundas Chart for .NET offers built-in capabilities to add many exciting and useful functions to charts, all without using postbacks. Dundas is dedicated to create sophisticated dashboards by building the most advanced data visualization solutions available.

SSRS Reporting Services-We will be using SQL Server Reporting Services (SSRS) which is a server-based report generation software system from Microsoft. It can be used to prepare and deliver a variety of interactive and printed reports. It is administered via a web interface. Reporting services features a web services interface to support the development of custom reporting applications.We will be using SQL Server Reporting Services (SSRS) for the reports.

Telerik Dock Control VS ASP.Net Web Parts-We will be using telerik Dock control instead of ASP.Net Web Parts in our Dashboards.It is much light weight than the ASP.Net Web Parts.

Resolution Free UI architecture-Using Dynamic Themes concept to make the Product Resolution Free.Based on Client Resolution the Themes will be loaded dynamically specific to that Resolution.Eg.Then we will be UI Coding Standards that lead to make a product Resolution Free.

Psuedo Code

protected void Page_PreInit(object sender, EventArgs e) { Page.Theme = WebManager.GetThemeName(); }

Cross Browser SupportWe have write Javascript in the presentation layer such that it supports multiple browsers.

Using LINQ to improve performanceTo improve performance we will be using Language Integrated Query(LINQ) to query the data in the Client Side and not going to the Database.

Psuedo Code

IEnumerable<DataRow> Query = from c in dtTable.AsEnumerable() where

c.Field<string>("RskCat_Name")==(hidRiskName.Value.ToString()) select c; dtResult = Query.CopyToDataTable<DataRow>();

Session Management

The state management in the application uses the normal HTTPSession object, which is used to store persistent data across the pages.

For eg a value is saved in session object as follows;

Psuedo Code

context.Session[PresentationConstants.USER_DATA] = objDtoUserProfile;This assigns a value to the HTTPSession object with a key “PresentationConstants .USER_DATA”

For retrieval we use objDtoUserProfile = context.Session[PresentationConstants.USER_DATA] ;This retrieves the object stored in session and assigns it to the object specified.

Cache Management

While the session object is used to store user specific data the cache is used to store global data available to all the users. This is not user specific and is used to store general items.Caching is implemented in the application by using the HttpContext.cache object where these items (like all ListItem Information) are stored using global keys, and retrieved wherever required in the application. By this we remove the need to go back through the layers and retrieve the values every time an user request it, rather we take them from cache. This improves the performance of the application as this eliminates roundtrips to the server.

An object is stored in cache as followsPsuedo Code

context.Cache[PresentationConstants.LISTITEM_DATA] = objListItems;

For retrieval we use

objListItems = context.Cache[PresentationConstants.LISTITEM _DATA] ;

Localization & Globalization

Creation of local resource filesThe first step in localizing is the creation of resource files. For each web page we need to create a resource file for each culture (language) we will be supporting.

Creation of resource files for aspx pagesTo create a resource file for a web page, we need to follow the following steps.Once the page design is complete we need to generate resource files for the page. Next we can change the language of the page by setting the UICulture property of the page in the Page's InitializeCulture Event as shown below.

Psuedo Code protected override void InitializeCulture()

(Request.Form["ddlLanguages"] != null)

String selectedLanguage = “kn-IN”;

Page.UICulture = selectedLanguage;

base.InitializeCulture();

The above code sets the page culture to kannada. When the page is rendered the text is automatically taken from the resource file named “userdata.aspx.kn-IN.resx”.For Javascript alert messages and any text messages that we need to display to the used like “Record saved” ,”Record deleted”, “Please select a record” etc.. we will make use of global resources. Global resources will reside in the App_GlobalResources directory and key/value pairs put in this resource file can be accessed from any page in the application. However the rules remain the same, we have to create a seperate resource file for each culture.

Database support.To store international language characters in the database, the column data type will have to be of Nvarchar type.Note: When not using MS Enterprise libarary we will have to pass the N character prefixed before the input parameter .

Below is the culture reference for different cultures.

de 0x0007 German

en-US 0x0409 English - United States

hi-IN 0x0439 Hindi - India

kn-IN 0x044B Kannada - India

Screen Shots of Login page which supports German,Hindi and Kannada based on selection made in the

dropdown box.German

Hindi

Kannada

Screen shot of data stored in the database and displayed in a grid (Hindi)

Email Template using XSLT and XSLTArgumentList

Ref Url : http://www.codeproject.com/KB/XML/EmailProject.aspx

Email sending with html format, instead of using stringbuilder class and preparid html format and sent to email service. If we want to change the html format we need to change code.By using Email Template concept, we can change html format very easaly.An XSLT file as a template file to store email templates. It specifically targets on usage of Custom Objects Properties to be used in the XSLT file.

4.3 Common Layer (Eduquer.Common Layer)

The Eduquer.Core is a referred in all the Layers of the architectureThis consists of the following layers:

Database Service Exceptions Service Logging Service Utility Caching

Microsoft Patterns & Practices Enterprise 4.1 - October 2008

This Enterprise Library 4.1 Used for Database Service , Exception Handling Service and Logging Service.

Enterprise Library 4.1 - DAAB (Data Access Application Block for Data access) Enterprise Library 4.1 – EHAB (Exception Handling Application Block) Enterprise Library 4.1 – LAB (Logging Application Block)

Enterprise Library 4.1 Exception Handling Application Block

Features : Writing the same exception logging code is pasted throughout your code in catch blocks

Has difficulty in ensuring exception handling actions are consistent from developer to developer, and application to application

Changing your policy regarding exception handling results in source code changes Facilitates consistent exception handling behavior at logical boundaries of an application Allows the creation of “exception policies” which dictate which actions should be taken for

specific exception types at the logical boundary Example: All security exceptions arising from the business layer need to be logged, and the

messages sanitized before being propagated to the caller3 Handler Types Available

Wrapping - wraps one exception around another Replace - replaces one exception with another Logging - formats exception info and log with Logging App Block

This Exception Handling Application Block Implemented in All the Layer except Business Entity Layer.

You need the same boilerplate code to handle an exception in all the layers.

try { //Some code } catch(Exception ex) { bool rethrow = ExceptionPolicy.HandleException (ex, <Name Of Policy>); if (rethrow) throw; }

Enterprise Library 4.1 Logging Application Block

Features : Inflexible configuration options for logging Recompiling code to change logging behavior

Allows applications to log business and operations data to various destinations, which are externally configurable

Configuration specifies which messages go where, and how they are formatted Formatters and sinks are extensible. Out of the box: Event Log, Database, Text File, MSMQ

(asynchronous), E-mail, WMI and Windows Event Tracing

Using EnterpriseLibrary Logging Application Block, we can log business information.Ex: LogEntry le = new LogEntry(); le.TimeStamp = System.DateTime.Now; le.Categories.Add("Audit"); le.Message = "Task Deleted by Krishna Mohan"; le.EventId = 1234; le.Title = "Business Logging Information"; le.Priority = 1; Logger.Write(le);

4.5 Data Access Layer (Eduquer.DataAccess Layer)

Enterprise Library 4.1 Data Access Application Block

Features :

A simple and efficient way of working with commonly used databases Transparency when developing for multiple types of databases A way to place an indirection between a logical database instance and a physical database instance An easy way to adjust and validate the database configuration settings A block that includes support for both stored procedures and in-line SQL, and common

housekeeping tasks such as managing connections and creating and caching parameters are encapsulated in the application block's methods.

Provides a kind of "wrapper" around ADO.NET thereby exposing access to the most often used features thereby abstracting the logic from the developer.

Facilitates development when porting applications to different types of databases. Support for MS Sqlserver, Oracle and DB2.

This Data Access Application Block Implemented in DataAccess Layer.

Data Access Application Block Design

The Data Access layer provides data services to the Business Rules layer. All database transaction is done in this layer. Data Access layer directly interacts with database.

In this Layer we used Enterprise Library 4.1 Data Access Application Block.

The business layer have to just call these methods and not concern itself with any of the database related activities.

Any exception occurring in the layer is caught and propagated back to the previous layer.

Note:Enterprise Library 4.1 References for each layer.

DataAccess Layer required Rererences 7 dlls. Those are 1. Microsoft.Practices.EnterpriseLibrary.Common;2. Microsoft.Practices.ObjectBuilder;3. Microsoft.Practices.EnterpriseLibrary.Data;4, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling;5. Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging;6. Microsoft.Practices.EnterpriseLibrary.Logging;

In each file of the DataAccess Layer

using Microsoft.Practices.EnterpriseLibrary.Data.Sql

SqlDatabase db = null;

db = new SqlDatabase(DataAccessHelper.GetConnectionString(trustId));

5. Deployment Process

Reference Urls

Reference Architectures

Best Practices for .Net Enterprise Architecture.

Duwamish 7.0 Architecture.

http://msdn2.microsoft.com/en-us/library/aa288541(VS.71).aspx

Microsoft .NET Pet Shop 4.0 Architecture.

http://msdn2.microsoft.com/en-us/library/aa479071.aspx

Gang of Four Design Patterns - Enterprise Application Architecture.

http://www.dofactory.com/Framework/Framework.aspxReference Building Blocks

Microsoft Patterns & Practices Enterprise 4.1 - October 2008.

DAAB – Data Access Application Block.

EMAB – Exception Management Application Block.

LAB – Logging Application Block.

http://msdn2.microsoft.com/hi-in/library/aa480453.aspx

Deployment Practices

Deploying .NET Applications using VS.NET 2005.

http://msdn2.microsoft.com/en-us/library/aa479568.aspx