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.

Purpose
To 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.

Scope
This 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 Diagram
The 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 Dlls

AJAX 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 Dlls
Telerik 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 Support

We have write Javascript in the presentation layer such that it supports multiple browsers.

• Using LINQ to improve performance

To 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 follows

Psuedo Code

context.Cache[PresentationConstants.LISTITEM_DATA] = objListItems;

For retrieval we use

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

Localization & Globalization

Creation of local resource files
The 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 pages
To 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()
{
if (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 architecture

This 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 caller
3 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.aspx
Reference 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