На примере АБС «SNOVA» ОПТИМИЗАЦИЯ СТРУКТУРЫ РОЗНИЧНОГО МОДУЛЯ АВТОМАТИЗИРОВАННОЙ БАНКОВСКОЙ СИСТЕМЫ ДЛЯ РАБОТЫ В УСЛОВИЯХ «ПЛОХИХ» КАНАЛОВ СВЯЗИ Магистерская. - презентация

1 На примере АБС «SNOVA» ОПТИМИЗАЦИЯ СТРУКТУРЫ РОЗНИЧНОГО МОДУЛЯ АВТОМАТИЗИРОВАННОЙ БАНКОВСКОЙ СИСТЕМЫ ДЛЯ РАБОТЫ В УСЛОВИЯХ «ПЛОХИХ» КАНАЛОВ СВЯЗИ Магистерская диссертация Студента МФТИ (ГУ), 518 гр. Бычкова Александра Сергеевича Научный руководитель, Кандидат технических наук Майданюк Роман Андронович

2 ОСНОВНЫЕ ЗАДАЧИ Максимальное снижение требований к каналам связи Поддержка частичного функционирования ПО при отсутствии связи с сервером приложений Увеличение скорости развёртывание и настройки рабочего места Увеличение надёжности клиентского приложения за счет минимизации сетевого обмена Снижение репутационных рисков, связанных с отказом IT подсистем банка

3 ВЫБОР СРЕДСТВ РАЗРАБОТКИ Основные факторы, повлиявшие на выбор средств разработки Минимизация затрат на разработку графического интерфейса «Дружелюбная» среда разработки Поддержка платформы со стороны разработчика Плотная интеграция с MS Office Широкий функционал библиотеки для работы с СУБД Простота разработки веб-сервисов

4 ИСПОЛЬЗУЕМЫЕ ТЕХНОЛОГИ В качестве программной платформы для разработки была выбрана технология компании Microsoft.NET Framework 4.0 Пользовательский интерфейс реализован на WPF Подсистемы сервера приложений – VB.NET и C# Взаимодействие с СУБД – собственная библиотека, использующая ADO.NET в качестве провайдера СУБД Разработка бизнес-логики - Windows Workflow Foundation (WF) СУБД – Microsoft SQL Server 2008 x64

5 ОБЩАЯ СХЕМА ВЗАИМОДЕЙСТВИЯ

6 СОСТАВ КЛИЕНТСКОГО ПРИЛОЖЕНИЯ

7 Сохранение параметров операции в локальном буфере операций Доставка параметров операции в глобальный буфер операций средствами транспортного модуля Асинхронный запуск проведения Проверка не проведённых операций Удаление из глобального буфера тех операций, которые не удалось провести за определённое количество попыток Сохранение параметров операции в глобальном буфере операций Синхронный запуск проведения Ожидания результата проведения Получение статуса проведения В случае успеха, получение данных СЕРВИС ПРОВЕДЕНИЯ ОПЕРАЦИЙ Этапы online проведени я Этапы offline проведения

8 РЕАЛИЗАЦИЯ СЕРВИСА ПРОВЕДЕНИЯ ОПЕРАЦИЙ Сервис проведения платежей реализован как набор веб-сервисов. Каждый запрос на проведения операции обрабатывается в отдельном потоке. Все сервисы описаны с помощью языка WSDL Каждый запущенный поток непрерывно протоколируется, что позволяет в реальном времени отслеживать состояние системы Поддерживаются синхронный и асинхронный режим проведения Сервис имеет набор гибких настроек, позволяющих минимизировать вмешательство разработчиков в работу системы В сервис проведения интегрирована система протоколирования

9 ОРГАНИЗАЦИЯ ТРАНСПОРТНОГО МОДУЛЯ Параметры любой операции или запроса сериализуются в XML документ. XML документ передаётся шлюзу транспортного модуля посредством HTTP - протокола метод POST, используя метод сжатия zlib. Аналогичным образом реализована передача данных, являющихся результатом выполнения операции или запроса. После получения данных происходит преобразование XML документа во внутренние объекты клиентского приложения. В результате размер отправляемого пакета не превышает 3kb, размер получаемого пакета (в среднем), не превышает 7kb.

10 ПОДДЕРЖКА ЛОКАЛЬНЫХ СПРАВОЧНИКОВ В АКТУАЛЬНОМ СОСТОЯНИИ Обновление локальных справочников происходит централизованно при помощью программного модуля, размещенного на выделенном сервере. Поддерживаются следующие режимы Синхронное разностное обновление Разностное обновление по расписанию Полное обновление справочника Разностное обновление по запросы из клиентского приложения Любая попытка обновления и результат обновления справочника протоколируется. Система оповещает о неоднократных неудачных попытках обеления справочников, что обеспечивает контроль в реальном времени

11 ПРЕДВАРИТЕЛЬНАЯ АВТОРИЗАЦИЯ ОПЕРАЦИЙ В случае отсутствия доступа к центральному серверу существует возможность получить код авторизации на конкретную операцию. В случае запроса авторизации на стороне АБС регистрируется факт запроса авторизации, после чего генерируется уникальный код. Клиентское приложение при получении корректного кода авторизации позволяет исполнить в «локальном» режиме операцию, требующую для исполнения доступа к центральному серверу. Как только связь с сервером будет установлена, операция будет доставлена в шлюз проведения автоматически.

12 Процесс авторизации операции

13 ОБЪЕМЫ И СРОКИ На проектирование архитектуры приложения ушло 2 месяца На программирование было отведено человеко-часов Было написано более строк кода на.NET и более на T-SQL Количество объектов в СУБД около штук Отладка приложения заняла 3 недели + 2 недели функционирования в «облегченном» варианте В разработке приложения участвовали 4 человека На данные момент система обрабатывает операций в сутки В результате внедрения было автоматизировано более 100 бизнес – процессов розничной сети банка Расчетная нагрузка при сохранении текущих бизнес-процессов – операций в сутки

14 РЕЗУЛЬТАТЫ После внедрения данной разработки были получены следующие результаты 1.Количество отказов, вызванных проблемами с каналами связи, сократилось на 60 процентов 2.Нагрузка на центральный сервер СУБД снизилась на 15 процентов 3.Значительно снизилась нагрузка на ЛВС банка 4.Время развертывания и настройки нового рабочего не превышает 10 минут 5.Значительно снизилась трудоёмкость интеграции различных IT подсистем в операционный день банка 6.Суточный IP трафик на одно рабочее место не превышает 10 мегабайт 7.Сократилось время, затрачиваемое на выявление ошибок, благодаря системе логирования сервиса проведения операций