Knowledge Base	Заглавная страница | Описание | Справка | ЧаВО | Спецстраницы | Представиться системе
	Версия для печати | Отказ от ответственности | Политика конфиденциальности | Текущая версия

Просмотр

Страница «Интеграционное решение на основе системы Equation»

У вас нет разрешения на действие «исправление этой страницы» по следующим причинам:

• Запрошенное действие могут выполнять только участники из группы Участники.
• Эта страница закрыта для редактирования.

Вы можете просмотреть и скопировать исходный текст этой страницы:

=Интеграционное решение на основе системы Equation= ==(миграция данных и взаимодействие с внешними системами)== В настоящем документе приведен анализ возможных вариантов построения интеграционного решения на основе системы Equation для автоматизации банковской деятельности, а также приведено описание решения, использованного в рамках проекта внедрения Equation в АК БАРС банке. Интерфейсные функции системы Equation используются на следующих этапах внедрения системы : 1. Миграция данных 2. Взаимодействие систем в процессе эксплуатации интеграционного решения ==Миграция данных== Существует два подхода к миграции данных: 1. Заполнение таблиц с данными для последующей обработки в Equation (структура таблиц должна совпадать со структурой журнальных файлов) 2. Экспорт информации из эксплуатируемой системы и ее последующая обработка специально созданным программным обеспечением '''Подход 1.''' Заполнение журнальных файлов выполняется, как правило, силами программистов банка. Почему: - экспорт информации в таблицы не составляет большого труда; - на презентациях демонстрируется легкость использования данного подхода: «просто заполните файлы»; - можно сэкономить средства, выполнив часть работ самостоятельно, без привлечения внешних ресурсов; - исполнитель работ разделяет риски с заказчиком и имеет возможность переложить проблемы миграции данных на заказчика (называя этот процесс «подготовкой корректных исходных данных»). ''Риски:'' Основная проблема состоит в ''правильном'' заполнении файлов. В структуре таблиц кроме бизнес-параметров операций присутствует много дополнительной информации. Часть ее появляется вследствие особенностей обработки информации в системе. Назначение этих параметров и логика их обработки не всегда подробно описана. Кроме того, существует большое количество проверок информации, которые зависят от конкретного набора параметров операций. Решают эту проблему следующим образом: в системе вводят операцию, анализируют заполнение строки файла и принимают решение о правилах заполнения полей. Однако этот подход содержит большие риски: небольшое изменение в операции – и обработка информации в системе завершится с ошибкой. Есть еще одна проблема, которую необходимо решить, чтобы подготовить правильные данные для миграции: различия в идеологии систем. Пример из интеграции Equation и Диасофт. В системе Equation основные параметры обработки объектов настраиваются на уровне «типов объектов». Основные объекты в Equation: клиент, счет, проводка, сделка. Т.е. для открытия счета необходимо указать тип счета. В системе Диасофт такого параметра нет. И нет набора признаков, по которому можно автоматически подобрать нужный счет. Описанные выше проблемы на практике приводят к тому, что сроки проекта переносятся (по вине банка, если он имел неосторожность взяться за эту работу), затраты по проекту растут, а процесс миграции выполняется в полуавтоматическом режиме с существенным объемом ручного ввода информации в систему. '''Подход 2.''' Создание специального программного обеспечения потребует дополнительных затрат. Рассмотрим на примере внедрения Equation в АК БАРС банке, что может дать подобный подход: 1. Банк выгружает ту информацию, которая содержится у него в системе, без ее предварительной обработки. 2. Формируется список ошибок в реквизитах клиентов, счетов и документов, а также перечень несоответствий между информацией в двух системах, которые требуют использования дополнительных признаков для классификации объектов и их успешной миграции. 3. Процесс автоматизирован и может выполняться неограниченное количество раз до тех пор, пока не будут исправлены все ошибки. 4. Данные для миграции могут поддерживаться в актуальном состоянии 5. Миграция данных может быть выполнена в любой момент в автоматическом режиме 6. Тестирования системы, опытные эксплуатации могут выполняться на реальных данных банка, на полном объеме информации, с возможностью полной эмуляции работы банка. 7. Миграция полного объема данных с использованием стандартных функций ввода информации позволяет также проверить корректность выполненных настроек системы, и выполнить полнофункциональное тестирование функций ввода информации в систему, которые используются в том числе для построения интерфейсов с внешними системами. 8. Возможность использования ПО для проверки правильности базы клиентов и счетов филиалов банка (соответствие открытых клиентов, счетов, реквизитов документов нормативным требованиям ЦБ РФ). Результаты: {| border=1 | width=40%|Кол-во миграций – 21 | width=20%|Первая миграция | width=40%| Итоговая миграция при вводе в промышленную эксплуатацию |- |Количество не загруженных объектов | *~ 4000 клиентов *~ 50000 счетов | *0 клиентов *3 счета |- | Время миграции (с регламентными процедурами сохранения информации, обмена ключевой информацией и т.д.) |3 дня |4 часа, в том числе, собственно на миграцию: *Клиентов – 40 минут *Счетов – 2 часа *Остатки и документы картотеки – 10 минут |} Естественно, что объем работ зависит от перечня функционала, который предполагается перенести в новую систему. В описанном выше случае мигрировались клиенты, счета, остатки и документы картотеки. Для этих объектов программное обеспечение создано. Миграция сделок потребует дополнительного функционала. Внесение изменений может потребоваться и в случае миграции данных из других источников (отличных от Диасофта). Однако результаты, которые удалось получить, свидетельствуют о том, что миграцию информации надо выполнять не через журнальные файлы, перекладывая проблемы на банк, с помощью специального программного обеспечения ==Взаимодействие с внешними системами== Стандартный подход, который предлагается для организации взаимодействия с внешними системами – использование API Equation. Проблемы в следующем: *API Equation «расположены» на сервере iSeries. Т.е. вызов этих функций требует определенных навыков и знаний по системе Equation и iSeries *Банковская операция это набор отдельных транзакций (открытие счетов, формирование проводок, регистрация дополнительной информации и т.д.). Надо уметь объединять вызовы отдельных API в целостные банковские операции *Для успешной обработки информации в системе Equation необходимо знать особенности этой системы (см. пример по типу счета из раздела по миграции данных). Описанные выше проблемы затрудняют использование функций системы до такой степени, что разработчики других систем после некоторого числа «попыток» делают выводы о сложности или даже невозможности интеграции своих приложений с Equation или о необходимости использования файлового обмена информацией. При внедрении системы в АК БАРС банке для организации межсистемного взаимодействия создан коммуникационный модуль “EQUATION Gate & Interfaces”. Он состоит из трех частей: 1. Собственно сервер, обеспечивающий многопоточную обработку информации, поступающей из внешних систем 2. Библиотеку функций прикладного программного интерфейса для Windows платформы, реализующую на текущий момент набор из 50 операций (идентификация клиента, открытие счета, ввод документов определенных типов и т.д.). Библиотека содержит в своем составе специальные функции, позволяющие управлять количеством процессов по обработке информации, запускаемых на iSeries. Библиотека обеспечивает корректное с точки зрения системы Equation выполнение работ (установка соединения, проверка доступности системы, создание рабочей среды, идентификация пользователя и т.д.).

Возврат к странице Интеграционное решение на основе системы Equation.

Заглавная страница | Описание Knowledge Base | Поиск: