Portfolio

CMA is an application designed for easy contracts management, mostly for large enterprise companies with the wide net of various business units and departments in different countries.

The application allows an easy access and various workflows setup using roles-based approach. As soon as organization structure, workflow and access are all configured, the system allows to:

• register already existing contracts;
• register incoming contracts;
• create new outgoing contracts;
• define standard corporate templates for different languages and business units;
• automatically generate new contracts based on templates and user-friendly fill-in forms.

• documents workflow control;
• notification to all of the interested persons in case of any changes in document or any events in process of contracts approval;
• electronic signing of the contracts;
• external online access for review by other party company employees;
• documents export to MS Word and PDF;
• documents archiving;
• search across the whole contracts database.

So, the application functionality implements all of the steps of the contracts approval workflow, including electronic signing of the documents.

The application is developed using service-oriented approach, so the solution consists of several separated services. Each of the components of the solution is separately scalable and distributable. It allows to support vertical and horizontal scalability. Azure is used in the back-end as a cloud platform with the powerful automatic scalability and SLA. Therefore, the described approach provides the best possible level of the whole scalability and stability.

Most of the application components are implemented as WCF-services. At the same time there are several front-end components (HTTP based interface) and common services required in order to support different sign-on systems. To provide the best quality for the Enterprise companies, ADFS are integrated as a standard SSO for most-widely used corporate AD structures.

From high-level point of view, the application is separated into 3 layers:

1. Front-end;
2. Business Logic;
3. Database.

Each of the layers is a separate solution and may be represented as a single instance or a farm of the instances. It is possible to scale each layer separately.

Deployment

From deployment point of view, it was suggested to use Azure components as the layers supporting automatic deployment and provisioning:

1. Front-end web role - a web role that is configured as a part of the cloud service that represents not a single VM, but a scalable cloud service beneath. This web role is used for the front-ends of the application;
2. BL web role - the same as the role above, but in that case the role is used for the WCF API's hosting.
3. Azure SQL - a standard Azure database with built-in scalability feature.

Front-end

Front-end is implemented as a standard ASP.Net MVC 5 application using the following technologies and libraries:

• ASP.Net MVC
• Kendo MVC
• AngularJS

Business layer

Basic concepts

Business layer is implemented as a separate solution that provides the functionality via WCF API:

• WCF is selected against Web API because of easier and automatic client code generation;
• Autofac is used as a dependency injection library that allows to implement the inversion of control;
• All BL objects that are created remain alive only while the request is processed. In other words, BL implementation is stateless. It receives a request, creates the required objects and clears out when the response is provided.

Security

The authentication is implemented based on tokens. Front-end provides security tokens on each request. The token is used to authenticate and to authorize a user in the BL. At the same time, the connection from front-end to API itself is not secured and is protected by restricting the access to the API from the Internet. API modules are parts of the internal virtual network, from which only the front-end services are exposed to the end users.

Entity Framework/DTO

Entity Framework with the code-first approach is used as an ORM. DTO (Data Transfer Objects) are implemented for data transfer from API to front-end. DTO classes do not contain any behavior and are purposed for the isolation of the required data from the unneeded behavior.

Data Context

Considering the multi-tenancy requirements it was suggested to separate data in the database based on DB schemas. Each customer has his own set of tables included into his own schema. While DataContext is being created from the DataAccess layer, the application determines and sets the certain tenant's DB schema, therefor any further processing does not take multi-tenancy into account .