Проект модернизации ИТ-системы в ЛИКАРДе

Помимо интеграции CRM с нетривиальными сервисами процессинга требовалась интеграция данных от CRM и процессинга с личным кабинетом (ЛК) и с другими системами. Возлагать логику вызовов «точка–точка» на всех потребителей несправедливо, тем более если есть возможность построить слой доступа к данным и операциям на существующих сервисах бизнес-систем с помощью средств, специально для этого предназначенных.

Совместная реализация интеграционного слоя на Oracle Service Bus позволила команде ЛИКАРДа сократить расходы на интеграцию и ускорить процесс внедрения за счет разделения труда специалистов, отвечающих за CRM, процессинг, пользовательские приложения, причем каждый занимался своей работой, в то время как команда шины организовывала их взаимодействие.

Интеграционная шина: гнемся, но не ломаемся

Siebel по праву главного взял на себя реализацию бизнес-процессов, а интеграционная шина – взаимодействие с внешними системами. Но ей был уготован не только безликий транспорт. Например, для личного кабинета B2C потребовался функционал, не входящий в задачи CRM, поэтому шина связала ЛК с отдельным менеджером клиентских сессий, отправителем СМС, процессингом с наибольшим удобством для ЛК. Было принято совместное решение строить сервисы на принципах возможности повторного использования. Когда у ЛИКАРДа появилось мобильное приложение «АЗС-Локатор», его интеграция с CRM и процессингом прошла так бесшовно, что обе системы об этом даже «не узнали».

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

Шина Oracle Service Bus позволяет даже динамически менять код сервисов в онлайн-интерфейсе, прозрачно для потребителей, однако в ЛИКАРДе из-за строгости релизной политики данная возможность на текущий момент не используется.

Мы говорим на вашем языке

Специалисты ЛИКАРДа предложили в рамках внедрения CRM-системы часть несвойственных процессингу функций, в основном связанных с вводом исходных данных, вынести в CRM. Исходя из предоставленных требований выяснилось, что разработка API со стороны процессинга оказалась на критическом пути проекта внедрения. Для оптимизации времени и затрат на разработку интеграции было принято решение использовать «родной» формат низкоуровневого обмена сообщениями с процессингом. Такой подход позволил перераспределить интеграционные усилия команд внедрения в сторону шины/CRM, сняв нагрузку со стороны разработчиков конечной системы. Однако при использовании свойственного процессингу интерфейса xml over http мы столкнулись с рядом особенностей, которые пришлось учитывать по ходу проекта.

1) XSD-схемы

Наличие xsd-схем было приятным сюрпризом. Из схем стал понятен принцип построения сообщений, порядок следования полей. Обращение к описанию собственных стандартизированных типов регулярно помогало ориентироваться на длины и форматы полей, а также на значения справочных атрибутов. Однако варианты формата сообщения могли отличаться в зависимости от типа сообщения (создание/изменение объекта). В процессе совместной работы эта информация постоянно уточнялась.

2) Генерация уникальных идентификаторов

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

3) Поля, не приведенные к первой нормальной форме

Одной из возможностей расширения стандартной функциональности в процессинге является создание так называемых тегированных полей, когда значением поля является комбинация пар: «наименование_атрибута = значение_атрибута», разделенных точкой с запятой. Использование таких полей разработчиком конечной системы утяжеляет обработку и формирование интеграционных сообщений, так как привносит дополнительные операции по обработке текста.

4) Особенности объектной модели данных конечной системы

Для интеграции по ряду бизнес-сущностей требуется отправлять сразу несколько сообщений – в силу того, что эти атрибуты относятся к различным объектам в конечной системе. Подобная декомпозиция не вызывает удивлений, а вот когда один и тот же атрибут в зависимости от типа совершаемой операции (создание или изменение) транслируется в разные объекты – это уже нетипичное поведение конечной системы.

5) Ограниченные возможности по доработке нативного интерфейса

В некоторых случаях от конечной системы по ряду причин рациональнее получить готовый функционал с определенными требованиями, а не реализовывать его в интеграционном процессе. Это может быть продиктовано требованием к производительности компонентов или нецелесообразностью дублировать в интеграции процесс, уже реализованный в конечной системе. На практике возможности по кастомизации нативного API оказались сильно ограничены в силу его жесткой связи с функциями ядра системы. Поэтому важно знать и рассматривать альтернативные возможности конечных систем по предоставлению высокоуровневого интерфейса.

Итог проекта

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

В качестве плюсов можно отметить:

• готовый или минимально дорабатываемый набор функциональности на стороне конечной системы;
• хорошо отлаженный механизм.

К минусам стоит отнести:

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

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

А что дальше?

Oracle Service Bus: интеграция людей

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

Именно с задачей объединения людей, движимых разными целями, справляется команда внедрения шины. На них ложится задача объединения систем, чтобы те работали сообща. Команда шины не скажет: «Это не входит в мою систему, я делать не буду». Команда шины заставит унифицировать объем передаваемых данных так, чтобы их было достаточно для процессов, а еще хватило на будущее, позволяя системам обмениваться данными в том формате, в котором им удобно. Такая специализация позволяет экспертам конечных систем сэкономить на трудозатратах, требуемых на интеграцию, поскольку аналитикам приложений не нужно тратить массу времени на взаимодействие с командой, внедряющей другую систему, погружаться в детали незнакомого приложения и торговаться с партнерами, кто будет уступать другому в формате. Разработчикам не придется реализовывать нестандартные средства интеграции, которые не только занимают массу времени, но и потенциально могут содержать ошибки, вызванные «костылизацией».

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

Oracle Service Bus: интеграция процессов

Проект внедрения продукта чаще всего формулируется под эгидой «давайте выбросим старую пожухшую систему А, а на ее место поставим новую блестящую систему Б». И требования, и бизнес-процессы, реализованные в системе А, без изменений перекочевывают в систему Б, сбивая с нее глянец «костылями», требуемыми для поддержания старых, не оптимально построенных бизнес-процессов.

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

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

Делай больше, делай лучше!

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

Однако в процессе реализации проектных задач образуется огромное количество рабочего материала, который будет использован в будущем. Схемы данных, служебные процедуры, функции доступа к справочникам, библиотеки логирования, модули работы с бинарными файлами (word, excel), адаптеры к прикладным системам (Siebel, SAP), механизмы развертывания функционального и нагрузочного тестирования – весь этот набор ускоряет реализацию новых проектов, а модернизируясь и развиваясь, он составляет базу наработок, которая становится конкурентным преимуществом перед лицом новых задач.