Август 2015

Система Сопровождения Контрактов (ССК)

Система Сопровождения Контрактов (ССК)

ССК – это приложение, предназначенное для сопровождения контрактов и обеспечивающее их проверку, согласование, электронную подписку и утверждение.

Бизнес-логика

Приложение, в основном, актуально для крупных компаний с большим количеством подразделений и департаментов в различных странах.

ССК дает возможность с легкостью выстраивать различные бизнес-процессы с привлечением разных сотрудников, используя разграничение доступа на основе ролей. После первоначальной конфигурации системы под конкретного заказчика (внесения данных об организационной структуре, настройки рабочих процессов и прав доступа), появляется возможность:

  1. регистрировать уже существующие контракты;
  2. регистрировать контракты, инициированные контрагентом;
  3. создавать новые контракты, инициированные самой компанией;
  4. создавать шаблоны стандартных корпоративных контрактов на разных языках, для различных подразделений компании;
  5. автоматически создавать новые контракты, основываясь на шаблонах и заполняемых пользователями автоматических форм.

Система позволяет осуществлять полноценный документооборот для любого документа, зарегистрированного или созданного в приложении:

  1. Контроль потока документов (отчеты, выборки, обзор состояния контрактов);
  2. Уведомления всем пользователям, задействованным или ответственным за сопровождение контракта;
  3. Электронная подпись контрактов;
  4. Организация защищенного внешнего доступа к контрактам для сотрудников компании-контрагента;
  5. Экспорт документов в форматы Word и PDF;
  6. Архивирование документов;
  7. Поиск по всей базе данных контрактов.

Таким образом, приложение охватывает все этапы сопровождения контрактов, включая электронную подпись документов.

Архитектура

Архитектура Системы Сопровождения Контрактов (ССК)

Приложение разработано с применением сервисно-ориентированного подхода, поэтому решение состоит из нескольких отдельных сервисов. Все компоненты масштабируемы и отделены друг от друга. Azure, в качестве хостинга платформы, по-умолчанию предоставляет мощные инструменты для автоматической масштабируемости, а также обеспечивает высокий уровень SLA (Service Level Agreement) на базе облачных технологий. Таким образом, выбранная архитектура, технологии и подход обеспечивают высочайший уровень надежности и масштабируемости сервиса.

Большая часть компонентов приложения разработана на базе WCF-сервисов. В то же самое время в приложении есть некоторые публичные компоненты (HTTP-интерфейс) и общие сервисы, необходимые для поддержки различных систем-входа. Для обеспечения удобства настройки доступа реализована интеграция с ADFS (Active Directory Federation Services), как со стандартной реализацией SSO (Single Sign-On) в крупных компаниях.

В ближайшем рассмотрении, архитектура приложения, состоит из трёх уровней:

  1. Публичная часть;
  2. Бизнес-логика;
  3. База данных.

Ввод в эксплуатацию/Развёртывание

С точки зрения организации рабочего окружения было целесообразно использовать компоненты Azure в качестве слоев, поддерживающих автоматическое развертывание и инициализацию программных компонентов:

  1. Веб роль для публичной части – веб роль, которая конфигурируется как часть облачного хостинга, представляющая собой не одну виртуальную машину, а масштабируемый облачный сервис. Эта веб-роль используется для публичной части приложения;
  2. Веб роль для бизнес-логики – во многом похожа на роль, описанную в 1 пункте, лишь за тем исключением, что используется для хостинга WCF API.
  3. Azure SQL – стандартная база данных Azure обладающая встроенными механизмами масштабирования.

Публичная часть

Публичная часть представляет собой стандартное веб-приложение, реализованное на платформе ASP.Net MVC 5 с использованием:

  1. ASP.Net MVC
  2. Kendo MVC
  3. AngularJS

Слой бизнес-логики


Основные понятия

Слой бизнес-логики выделен в отдельный сервис, который предоставляет функциональность посредством WCF API:

  1. В качестве интерфейса был выбран WCF, а не Web API, благодаря более простой автоматической генерацией клиентского кода;
  2. В качестве библиотеки, обеспечивающей инверсию управления, используется Autofac;
  3. Жизненный цикл всех объектов бизнес-логики ограничивается временем обработки запроса. Иными словами, слой бизнес-логики не хранит и не отслеживает состояние (stateless).

Безопасность

Аутентификация в приложении строится на основе токенов. Публичная часть передает токены безопасности при каждом запросе. Токены используются для аутентификации и авторизации пользователя на уровне бизнес-логики. В то же самое время, соединение между публичной частью и API не требует защиты, т.к. доступ к API из сети интернет попросту закрыт. Модули API являются частью внутренней виртуальной сети, к которой допускают только сервисы публичной части, являющиеся частью программного решения.


ORM (Object-Relational Mapping) и DTO (Data Transfer Objects)

В качестве ORM используется Microsoft Entity Framework 7. Передача данных между слоями системы осуществляется посредством передачи DTO, классы которых реализованы без поведения, т.е. содержат только необходимую информацию и никакой логики.


Контекст данных

Поскольку система реализована как сервис, предоставляемый различным заказчикам, мы разделили данные в БД, используя схемы. Каждый клиент системы обладает собственным изолированным набором таблиц, включенным исключительно в его собственную схему.

Контекст данных (Data Context) создается на уровне доступа к данным, с учетом текущего пользователя (и его компании), и определяет конкретную схему данных (и таблицы) с которой в дальнейшем и идет работа.