Михаил Великих,
ведущий специалист в области SOA,
ООО «Топ-Книга»

Опыт построения интеграционной платформы с использованием продуктов Oracle

Источник: статья подготовлена по презентации автора на Oracle TechForum2008, ноябрь 2008,
http://www.oracleclub.ru/techforum/program.html, секция "Oracle Fusion Middleware".

Введение

19 апреля 2007 года в компании «Топ-Книга» стартовал проект трансформации процессов прогнозирования и пополнения запасов на базе решения Oracle Retail. Консультантом на проекте выступала компания «Делойт», при участии которой ранее были осуществлены внедрения информационных систем Oracle JD Edwards Enterprise One и Oracle Enterprise Budgeting and Planning.

В процессе выбора розничной системы рассматривались предложения основных международных поставщиков в данной области: i2, Oracle, SAP. Предпочтение было отдано Oracle Retail (Retek), как решению, наиболее полно отвечающему стратегическим планам дальнейшего развития компании. Проект предусматривал создание системы для управления товарным запасом компании на базе Oracle Retail Merchandising System (RMS), построение систем прогнозирования спроса и аналитической отчетности с помощью модулей Oracle Retail Demand Forecasting (RDF) и Oracle Retail Data Warehouse (RDW). Данная статья рассказывает о том, каким образом была реализована интеграционная схема проекта и какие ключевые решения принимались в ходе внедрения.

О компании «Топ-Книга»

• Основана в 1995 году
• Численность сотрудников – более 6000 человек
• Годовой оборот за 2007 год составил 328 млн. $
• Присутствие почти в 300 городах России
• Доля на российском книжном рынке – 12%
• Всего 556 разноформатных магазинов в России, из них: «Книгомир» – 386, «Лас-Книгас» – 15, «Литера» – 26, «Пиши-Читай» – 44, «Городская Сорока» – 16, «Книгомир-Эконом» – 8, «Медиа-магазин» – 1 (по данным за 1 квартал 2008 года)
• Партнеры – 60

Информационная среда компании до внедрения Oracle Retail

До внедрения Oracle Retail в компании использовались следующие информационные системы (основные):

1. Oracle JD Edwards Enterprise One (складская логистика, финансовая отчетность)
2. Oracle Enterprise Budgeting and Planning (бюджетирование)
3. Собственные разработки:
• CIS (ценообразование, RDBMS Server: MSSQL 2005)
• Магазинное ПО (Phoenix, Phoenix 2, Top Shtrih)
• Интернет-магазин
4. 1С: Зарплата и кадры (расчет заработной платы)

Системы обменивались данными, но отсутствовал общий подход при реализации интеграционных проектов, и, как следствие, не было единого информационного пространства. Это стало естественным ограничением при внедрении новых информационных систем. Проект SCM предусматривал разработку подобной интеграционной архитектуры.

Функциональная карта информационного пространства после внедрения Oracle Retail

На рисунке 1 представлена текущая функциональная карта информационного пространства компании.

Рис. 1. Функциональная карта (заштрихованы те области, для которых требуется усовершенствование или замена)

На рисунке видно, что внедрение модулей Oracle Retail затронуло все основные ИС компании. С внедрением нового подхода к управлению ассортиментом также изменились многие ключевые бизнес-процессы, организационная структура и появились технологии, на основе которых более эффективно осуществляется пополнение товарных запасов компании на складах и в магазинах.

Кроме того, в рамках стратегии развития компании планируется замена существующих и внедрение новых продуктов, например:

1. Oracle Hyperion взамен Oracle Enterprise Budgeting and Planning (EPB);
2. WMS (система управления складскими запасами);
3. CRM (система управления взаимоотношениями с клиентами)

На данный момент интеграционная архитектура достаточно гибка, чтобы не быть ограничением при последующих внедрениях.

Проектная команда группы интеграции и интеграционная архитектура

Проектная группа интеграции включала специалистов компаний «Делойт», «Топ-Книга», «TopS BI». Функциональный дизайн, бизнес-анализ и подготовка данных осуществлялись преимущественно консультантами «Делойт» при участии специалистов «ТОП-КНИГИ». Первоначальная интеграционная архитектура была создана силами «Делойт» и «TopS BI». Разработка велась программистами компании «Топ-Книга» при участии разработчиков «TopS BI» и «Делойт». Интеграционное решение потребовало разработки более 100 интерфейсов между ИС компании. Сквозные бизнес-процессы обеспечили единое информационное пространство. Зачастую интерфейсы между системами требовали сложных преобразований (например, в условиях существующего гетерогенного окружения необходимо было наладить взаимодействие между ИС, использующими разные СУБД: Oracle Server, MSSQL Server).

Схема интеграции и точки принятия решений

На рисунке 2 представлена итоговая высокоуровневая схема интеграции. На начало внедрения системы содержали большой объем данных (БД JDE, например, ~4Тб). В то же время ИС JDE являлась основным поставщиком изменений и транзакций в компании, что приводило к ее избыточной загруженности. Необходимо было отслеживать некоторые изменения, происходящие в JDE, чтобы транслировать их на остальные ИС (например, изменение остатков на торговых объектах) при этом обеспечивая минимальную нагрузку на JDE. Решение было найдено – Oracle Downstream Capture.

Так появилась база данных (БД) IDB (Oracle 10g, IDB на рисунке 2). Изменения захватывались и передавались в интерфейсные таблицы на стороне IDB, где затем можно было производить их дальнейшую обработку.

Для интеграции остальных информационных систем (ценообразование – Cost System, магазинные системы – Store System, RMS, RDW и т.д.) был выбран пакет Oracle SOA Suite, входящий в состав Oracle Fusion Middleware.

Основные особенности схемы интеграции, которые приходилось принимать во внимание:

• количество сообщений ~10000000 (за сутки 10 миллионов новых строк в IDB, которые предстоит обработать)
• допустимое максимальное время синхронизации между системами – 15 минут
• гетерогенная среда (Oracle, MSSQL)

Рис. 2. Схема интеграции

Oracle ESB – ключевое звено всей схемы интеграции, предоставляет единую шину данных, связывает различные ИС компании (Oracle ESB – центральный компонент Oracle SOA Suite, для задач интеграции можно также использовать BPEL PM).

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

Таблица 1. Точки принятия решений

Выбор	Определяющий фактор	Комментарий
Streams vs. SOA Suite	Производительность	Производительность обоих продуктов удовлетворяет потребностям бизнеса
	Поддержка гетерогенных сред	Выбор был сделан в пользу SOA Suite, как имеющего адаптеры доступа к БД, системам очередей сообщений, файловой системе, в т.ч. доступной по FTP, позволяющего вызывать Web-сервисы.
	Масштабируемость	Оба продукта (под SOA Suite в данном случае подразумевается Oracle ESB) достаточно хорошо масштабируются вертикально. Oracle ESB также масштабируется в кластерных конфигурациях.
	Сопровождение	Сопровождение и развитие решения, основанного на Oracle SOA Suite, значительно легче, чем аналогичное решение с использованием Oracle Streams. Oracle JDeveloper, как основной инструмент разработки под Oracle ESB, предоставляет возможность визуального проектирования ESB-проектов и интуитивно понятной трансформации сообщений (XSL Mapper).
BPEL vs. ESB	Реализация сложной бизнес-логики	И BPEL и ESB достаточно для решения наших задач. BPEL будет использоваться тогда, когда не хватит возможностей ESB, как инструмент более подходящий для реализации сложной бизнес-логики или интеграции с Human Workflow.
	Производительность	ESB в 2-4 раза производительнее BPEL в общем случае (Oracle SOA Suite Best Practices Guide 10g Release 3 (10.1.3.3.0), Part No. E10971-01, page 2-17, How Fast is Oracle ESB).
	Обработка исключений	BPEL появился раньше ESB и, соответственно, более развит, обработка исключений в нем реализована лучше. В случае ESB мы разработали свою подсистему обработки исключений, которая используется службой поддержки.
Synchronous vs. Asynchronous Execution (ESB)	Отказоустойчивость	Асинхронные RSRR обеспечивают большую отказоустойчивость, т.к. сообщение сначала помещается в очередь (Oracle Streams AQ), а затем обрабатывается. Примечание: RSRR – Routing Service’s Routing Rules
	Масштабируемость	Наилучшую масштабируемость обеспечивают асинхронные RSRR.
	Производительность	Синхронные RSRR обеспечивают большую производительность, т.к. нет взаимодействия с AQ.
Local vs. Downstream Capture	Снятие дополнительной нагрузки с Source DB (JDE)	Было нецелесообразно создавать дополнительную нагрузку на БД-источнике (JDE), поэтому были использованы Downstream Capture-процессы.
	Платформо-зависимость	В случае Downstream Capture: ОС на Source и Downstream БД должна быть одинаковая (релиз может отличаться) Аппаратные платформы на Source и Downstream БД должны быть одинаковыми
	Упрощение администрирования	Local Capture немного проще в администрировании, нет необходимости настройки дополнительных компонентов, присутсвующих в Downstream Capture. С другой стороны, Downstream Capture позволяет на одной БД иметь архивные журналы с нескольких различных БД.

Особенности реализации

Данный абзац содержит некоторые технические детали реализации проектного решения (предполагает знакомство читателя с Oracle ESB или Oracle Streams).

Основные особенности реализации интеграционного решения для Oracle ESB выглядят следующим образом:

1. Разработка процедуры переноса ESB-проектов между средами (разработка/тест/продуктив)
2. Процедура добавления узла к ESB-кластеру
3. Процедура первичного развертывания дистрибутива ESB-проектов на сервере (ant, ESB Metadata Migration)

1. В Oracle Streams, в случае, если Apply-процесс применяет изменения медленнее, чем Capture-процесс перемещает их в очередь Apply-процесса (без Propagation), Capture-процесс при достижении порогового количества сообщений в очереди Apply-процесса переходит в статус «PAUSED FOR FLOW CONTROL» и перестает передавать LCR. Для Oracle ESB аналогов на данный момент не существует и нам пришлось разработать процедуру мониторинга асинхронных AQ-очередей, используемых ESB, чтобы избежать «переполнения» очередей, ведущего к деградации производительности.

Основные особенности реализации для Oracle Streams:

• Передаются все изменения по транзакционным данным в таблицу на стороне интеграционной БД (IDB). Это не текущий снимок данных, т.е. любое изменение строки в БД-источнике (JDE) вызывает вставку новой строки в БД-приемнике (IDB) с соответсвующим типом операции (DELETE, INSERT, UPDATE)
• Capture-процесс: позитивные наборы правил (positive rule sets) с простыми правилами (simple rules)
• Apply-процесс
1. Правила фильтрации не используются
2. Установлены рекомендованные параметры: параллелизм, размер буфера (streams_pool_size), spill threshold, commit serialization
3. Если требуются трансформации, то DML-handlers на каждую таблицу и нужную операцию (DELETE, INSERT, UPDATE)
• Процедура трансформации не выболняет операций lcr-transform и execute, информация извлекается из LCR и выполняется INSERT вместо этого.

Итоги проекта

Модули RDF и RDW были запущены в промышленную эксплуатацию в феврале и апреле 2008 года соответственно.

19 сентября 2008 года в пилотную эксплуатацию была запущена система RMS. В настоящий момент система рассчитывает заказы на пополнение 17 пилотных магазинов дивизиона «Юг». Некоторое время пополнение магазинов контролировалось силами проектной команды, затем процесс был передан специалистам бизнес-подразделения «Управление Категорий». Дальнейшие планы по развитию на ближайшие полгода предусматривают подключение остальных торговых объектов (более 500 магазинов) и всех групп товаров ко всем внедренным модулям Oracle Retail.

Об авторе

Михаил Великих принимал участие в проекте трансформации процессов прогнозирования и пополнения запасов на базе решения Oracle Retail с декабря 2007 года в качестве разработчика интерфейсов между информационными системами с использованием Oracle ESB. В настоящий момент является основным идеологом Oracle ESB в компании «Топ-Книга», принимает ключевые архитектурные решения по данному и сопутствующим направлениям. С момента запуска систем в продуктивной среде занимается администрированием кластера ESB-серверов (Oracle Application Server 10g), БД репозиториев ESB (Oracle 10g/11g), разработческих и тестовых сред ESB,а также ряда продуктивных, тестовых и разработческих БД (Oracle 10g/11g).

Список используемой литературы

1. Metalink Note: 274456.1 Subject: Downstream Capture
2. Metalink Note: 603471.1 Subject: How to Download ESB Management Client API
3. Oracle Application Integration Architecture Foundation 2.0: Concepts and Technologies Guide, Release 2.0, Part No. E10918-01, November 2007
4. Oracle Application Integration Architecture Foundation 2.0: Integration Developer's Guide, Release 2.0, Part No. E10924-01, November 2007
5. Oracle Application Integration Architecture Foundation 2.0: Core Components Guide, Release 2.0, Part No. E10925-01
6. Oracle Enterprise Service Bus Developer’s Guide 10g(10.1.3.4.0), Part No. E12638-01, July 2008
7. Oracle SOA Suite Best Practices Guide 10g Release 3 (10.1.3.3.0), Part No. E10971-01