68
Рисунок 19. Сценарий диалога работы системы
69
2.3.2. Характеристика базы данных
Поля основной таблицы заявок RequestForLimit и модель зависимостей базы
данных. Это основная таблица, которая описывает заявку на лимит, ключевой
объект, рассматриваемый в данной работе.
Таблица 3.
Таблица RequestForLimit
Название колонки
Тип
NULL
значение
По
умолчанию
Identity
Id
int
FALSE
TRUE
Approved
bit
FALSE
FALSE
Status
int
FALSE
FALSE
HasBezRegress
bit
FALSE
FALSE
RequestedLimit
decimal(18,2)
FALSE
FALSE
Limit
decimal(18,2)
FALSE
FALSE
RequestDate
datetime
FALSE
FALSE
CheckListRequestSnapshot
nvarchar(MAX)
TRUE
FALSE
StatusForClient
nvarchar(MAX)
TRUE
FALSE
StatusForConsultant
nvarchar(MAX)
TRUE
FALSE
ExternalGuid
uniqueidentifier
FALSE
FALSE
CreationDate
datetime
FALSE
FALSE
RowVersion
rowversion
FALSE
FALSE
BuyerId
int
TRUE
FALSE
RequesterId
int
TRUE
FALSE
SellerId
int
TRUE
FALSE
CheckListResultSnapshot
nvarchar(MAX)
TRUE
FALSE
ScoringRequestSnapshot
nvarchar(MAX)
TRUE
FALSE
ScoringResultSnapshot
nvarchar(MAX)
TRUE
FALSE
AssessmentStatus
int
FALSE
((0))
FALSE
Description
nvarchar(MAX)
TRUE
FALSE
Card62Id
int
TRUE
FALSE
ContractId
int
TRUE
FALSE
Cause
nvarchar(MAX)
TRUE
FALSE
ContactPersonsSnapshot
nvarchar(MAX)
TRUE
FALSE
Number
int
FALSE
((0))
FALSE
RedeemComment
nvarchar(MAX)
TRUE
FALSE
ApplClient
int
FALSE
((0))
FALSE
ApplDebitor
int
FALSE
((0))
FALSE
ApplLimit
int
FALSE
((0))
FALSE
SetCheckListDate
datetime
TRUE
FALSE
UpdateCompanyInformationDate
datetime
TRUE
FALSE
SignDossierDate
datetime
TRUE
FALSE
ConsultantDecisionDate
datetime
TRUE
FALSE
UnloadDate
datetime
TRUE
FALSE
ReturnDate
datetime
TRUE
FALSE
70
RejectDate
datetime
TRUE
FALSE
ConfirmDate
datetime
TRUE
FALSE
DeletedDate
datetime
TRUE
FALSE
StepInfo
nvarchar(MAX)
TRUE
FALSE
ScoringCheckDate
datetime
TRUE
FALSE
Visible
bit
FALSE
((0))
FALSE
Для определения зависимых таблиц и визуального их отображения
использовалось ПО Microsoft SQL Server Management Studio 18.
Рисунок 20. Список зависимых от RequestForLimit таблиц
Рисунок 21. Список таблиц, от которых зависит таблица RequestForLimit
71
Рисунок 22. Схема зависимых таблиц
Пользователи системы, полученные из внешних систем (сотрудники
компании), или зарегистрированные клиенты сохраняются в таблицу Users.
Авторизация, как и аутентификация пользователя построена на базе стандартной
библиотеки ASP.NET Identity. Аутентификация — это проверка учетных данных,
предоставляемых пользователем. После успешной аутентификации клиента или
пользователя, во все следующие запросы добавляется cookie-файл с ИД
пользователя, по которому он однозначно определяется сервером. По умолчанию
при регистрации первого пользователя создается следующий набор таблиц: [18]
• _MigrationHistory: используется EntityFramework для миграций БД;
• AspNetRoles: содержит определения ролей;
• AspNetUserClaims: таблица, хранящая набор клеймов (claim). Claim
представляет иную модель авторизации по сравнению с ролями. Грубо говоря, claim
содержит некоторую информацию о пользователе, например, адрес электронной
почты, логин, возраст и т.д. И эта информация позволяет идентифицировать
пользователя и наделить его соответствующими правами доступа;
• AspNetUserLogins: таблица логинов пользователя;
72
•AspNetUserRoles: таблица, устанавливающая для пользователей
определенные роли;
• AspNetUsers: собственно таблица пользователей. Если мы ее откроем, то
увидим данные зарегистрированного пользователя. Ключевыми объектами в AspNet
Identity являются пользователи и роли. Вся функциональность по созданию,
удалению пользователей, взаимодействию с хранилищем пользователей хранится в
классе UserManager. Для работы с ролями и их управлением в AspNet Identity
определен класс RoleManager. Классы UserManager и RoleManager находятся в
библиотеке Microsoft.AspNet.Identity.Core
Таблица 4.
Таблица Users
Название колонки
Тип
NULL значение
Id
int
Нет
UserGuid
uniqueidentifier
Нет
UserName
nvarchar(128)
Да
Email
nvarchar(256)
Да
PasswordHash
nvarchar(256)
Да
PhoneNumber
nvarchar(30)
Да
TwoFactorEnabled
bit
Нет
LockoutEndDateUtc
datetime
Да
LockoutEnabled
bit
Нет
AccessFailedCount
int
Нет
PhoneNumberConfirmed
bit
Нет
EmailConfirmed
bit
Нет
SecurityStamp
nvarchar(256)
Да
LastLoginTime
datetime
Да
ExternalGuid
uniqueidentifier
Нет
CreationDate
datetime
Нет
RowVersion
timestamp
Нет
DefaultCompanyId
int
Да
EmployeeId
int
Да
ShowFirstTimeLoginScreen
bit
Нет
ConsentUseDataXmbo
bit
Нет
NeedToAcceptClientCompanyInfo
bit
Нет
Blocked
bit
Нет
LastChangePasswordDateUtc
datetime
Да
SetTempPassword
bit
Нет
WayToAttract
nvarchar(128)
Да
WayToAttractId
int
Нет
73
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
Технически проект выполнен в виде MVC решения на базе ASP.NET MVC и
C#. Программные модули сделаны в виде отдельных подпроектов, что упрощает
сопровождение и доработку отдельных модулей.
Проект логически можно разделить на три области: Core, Modules, Web.MVC,
каждая область отвечает за определенные технические концепции и слои.
Слой Core отвечает за работу с данными, базовые методы, конфигурацию и
логирование. Он обеспечивает связь между другими модулями формируя контракты
для взаимодействия.
Слой Modules отвечает для все функции приложения. Содержит программные
модули в виде dll библиотек.
Слой Web.MVC отвечает за взаимодействие с пользователем и все аспекты
веб сайта. Собирает все предыдущие слои в единой приложение. Выполняется в виде
веб сайта на базе IIS.
Рисунок 23. Структурная схема пакета
74
2.3.4. Описание программных модулей
Все модули написаны на языке C#, после компиляции исходного кода модули
представляют из себя dll библиотеки. Формат DLL является динамической
библиотекой, которая отвечает за получение доступа различными программными
комплексами к общедоступному системному функционалу. Часто DLL файлы
входят в состав неотъемлемых элементов операционной системы Windows. Такой
формат файлов, как Link Library, может представлять из себя и часть прикладных
программ. [19]
Module.Client – модуль отвечает за бизнес-процессы по клиентским
сценариям.
Module.CloudFort – модуль позволяет надежно и отказоустойчиво
коммуницировать с бэк-офисной системой. Например, если возникла ошибка timeout
exception или too many request, тогда можем попытаться отправить, снова используя
Retry pattern или Circuit Breaker – он предотвращает попытки приложения выполнить
операцию, которая скорее всего завершится неудачно, что позволяет продолжить
работу дальше не тратя важные ресурсы, пока известно, что проблема не устранена.
Module.Consultant – отвечает за процессы и компоненты, используемые в
Личном Кабинете в части менеджера.
Module.CRM – технический модуль для связи с CRM. Передает полученный
от Лэндинга лид в CRM. Повторяет отправку при отрицательном или ошибочном
ответе.
Module.CryptoPro - подсистема для работы с криптографией на базе
КриптоПРО CSP.
Module.DataStorage – отвечает за хранение, чтение и удаление документов
через FileStream в базе данных MS SQL. Снимает статистику использования полосы
пропускания для крупных документов, частые запросы которых могут негативно
повлиять на сетевую стабильность.
Module.KonturFocus – модуль отвечает за сбор данных из внешних
источников.
Module.PhoneConfirm – модуль для подтверждения телефона. Генерирует
короткие коды, отправляет их по указанному номеру и проверяет что введенный
75
клиентом код верный. Следит за временем жизни кода и количеством неправильно
введенных кодов.
Module.RiskManager – модуль отвечает за определение уровня риска и оценки
контрагентов.
Module.Support – модуль для улучшения эксплуатационных характеристик
приложения. Позволяет клиентам или сотрудникам оставить заявку на обсаживание
в случае технических проблем.
2.4. Контрольный пример реализации проекта и его описание
Контрольный пример реализации содержит пошаговый пример работы над
заявкой со стороны нового клиента компании Открытие Факторинг.
Предполагается, что рабочее место клиента соответствует минимальным
требованиям Личного Кабинета: настольный компьютер или ноутбук, экран с
разрешением более 1200*768, и любой современный браузер, а также сеть интернет.
Клиентский маршрут начинается с Лэндинга и заполнения заявки.
Рисунок 24. Первый шаг заполнения заявки на лэндинге. Выбор лимита
76
Рисунок 25. Второй шаг заполнения заявки на лендинге. Выбор
отсрочки
Рисунок 26. Финальный шаг на лэндинге. Персональные данные
После заполнения предварительной заявки на лэндинге, данные передаются в
Личный Кабинет и CRM. Так как доменные имена у систем разные для защиты
77
используется CORS (Cross-Origin Resource Sharing, рус. "Совместное использование
ресурсов между разными источниками") — это система, состоящая из отправки
HTTP заголовков, которые определяют: заблокировать или выполнить запрос к
ограниченному ресурсу на веб-странице из другого домена, отличного от домена
происхождения запрашиваемого ресурса. [20]
После передачи данных Личный кабинет создает учетную запись для
клиента и клиенту предлагается заполнить недостающие поля.
Рисунок 27. Форма регистрации учетной записи и профиля клиента
После заполнения профиля клиенту предлагается заполнить заявку на лимит.
На первом шаге клиент вводит наименование дебитора и желаемую сумму лимита.
Для примера выберем компанию Леруа Мерлен Восток и сумму лимита 5 млн.
рублей.