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

Интеграция как преимущество

Исторически подобные задачи в «Национальной логистической компании» решали всегда, но делалось это на базе собственной разработки. Система, написанная на Delphi, обладала всеми очевидными недостатками самописного ПО систем — например, возникали трудности с дальнейшей поддержкой, систему нельзя было отдавать на аутсорсинговую доработку и т. д. И «Национальная логистическая компания» всегда упиралась в ограничения внутренних ресурсов. Размещение нового клиента на складе — довольно сложный процесс, требующий оперативности, и в периоды пиковых нагрузок этих ресурсов просто не хватало.

В компании поняли, что выгодно иметь интеграционную платформу, позволяющую привлекать внешних подрядчиков. «Промышленная интеграционная платформа включает в себя ряд преимуществ, уже обеспеченных другими разработчиками, таких как дополнительная функциональность, стабильность, масштабируемость, которых не было в нашей внутренней разработке. Чтобы достигнуть подобного уровня, нам пришлось бы ее дорабатывать еще лет пять, — объясняет Максим Штенцов, заместитель директора по развитию ИТ “Национальной логистической компании”. — Чем был интересен подход SOA? Наши клиенты на 80 % одинаковы, но всегда есть и различия: кому-то нужна таможенная очистка, кто-то желает получать уведомления по почте... Такие факторы часто комбинируются, поэтому нам нужна архитектура, которая, условно говоря, позволяла бы из “кубиков” выстроить цельную картину взаимодействия».

Естественно, идею развертывания SOA-платформы пришлось защищать перед руководством, но при этом в компании оперировали скорее качественными характеристиками, нежели точными расчетами. «Мы говорили о том, что это общепринятая практика, которая позволит нам следовать международным стандартам обмена, — рассказали специалисты “Национальной логистической компании”. — Эта платформа может быть интегрирована, и мы получаем гибкие возможности по привлечению подрядчиков, у нас появляется дополнительное преимущество в сравнении с другими логистическими операторами». Вообще говоря, к тому моменту и без интеграции внутренних приложений дальнейшая деятельность компании была слишком затруднена, росли затраты, обусловленные двойным вводом информации. Поэтому в отдельный подпроект было выделено создание НСИ, в результате чего компания будет иметь единую точку доступа к эталонной информации, а с помощью интеграционной платформы этой информацией смогут пользоваться все работающие системы.

Узкий выбор

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

Но по словам Максима Штенцова выбор решений в любом случае оказался не слишком широк. «Из продуктов на российском рынке в качестве реальных претендентов были только IBM WebSphere, Oracle Fusion Middleware и Microsoft Biztalk Server, — говорит Максим Штенцов. — Ещё рассматривалась Informatica, но это продукт из другой ниши, и нам он не подходил по функциональному покрытию. От IBM WebSphere мы отказались из-за того, что довольно сложно найти знающих его специалистов, которые к тому же дорого стоят, да и цена самого продукта превысила наши ожидания. Так что выбор фактически был между предложениями Oracle и Microsoft. Решающими стали несколько факторов, в частности, в нашем штате уже были специалисты, хорошо знакомые с технологиями Oracle. У нас на тот момент уже использовалась база данных этого производителя, и конечно же во всех отношениях лучше использовать уже имеющиеся технологии. И ещё один субъективный элемент: мы считаем продукты Microsoft пока не столь промышленными, как продукты Oracle». Заметим, что последнее — важный момент: не первый раз ИТ-директора говорят нам о недостаточной зрелости интеграционных решений Microsoft.

Так в июне 2007 года выбор платформы был сделан в пользу Oracle Fusion Middleware. По итогам тендера на реализацию этого проекта в качестве подрядчика была выбрана компания ЛАНИТ.

Умеют ли готовить

«Процессы внедрения SOA отличаются от внедрения коробочного продукта, потому что здесь больше времени уходит на то, чтобы спроектировать необходимую нам архитектуру, разложить функционал по полочкам, — рассуждает Максим Штенцов. — Само программирование занимает намного меньше времени». Для реализации проекта со стороны «Национальной логистической компании» были задействованы руководитель проекта, системный архитектор, один аналитик и несколько программистов, которые обеспечивают интеграцию с внутренними системами. Описание процессов и сервисов на языках BPEL и XML целиком выполнила компания-подрядчик. А команда со стороны заказчика определяла более концептуальные моменты — уровни, по которым система будет разбита на сервисы, способы мониторинга, используемые компоненты интеграционной платформы, — естественно, консультируясь при этом с подрядчиком и вендором. Нередко специалистам приходилось прокладывать свой собственный путь. В компании отмечают, что в России несмотря на явную моду на аббревиатуру SOA, все еще мало компетенции по соответствующим продуктам и ИТ-проектам; информацию приходится собирать по крупицам. В качестве ядра всей интеграционной схемы было использовано каноническое описание бизнес-сущностей, с опорой на международный открытый стандарт OAGIS (Open Applications Group Integration Specification).

Внедрение SOA — сложный процесс, и здесь велика вероятность попасть в сильную зависимость от его конкретного исполнителя, но в «Национальной логистической компании» этот риск стараются держать под контролем. Все компоненты — каждый BPEL-процесс — фиксируются как отдельные проекты в среде разработки, и с момента его сдачи в эксплуатацию компания поддерживает версионность собственными средствами. Если возникает необходимость переделать компонент, то на доработку отдается только он.

О сервисах

Как известно, большое значение при внедрении SOA играет умение правильно выделить сервисы. В проекте степень их грануляции определялась в соответствии с информационными потоками, такими, например, как заказ на приход и подтверждение заказа, заказ на отгрузку и подтверждение отгрузки. Ярким примером является сервис, используемый, когда клиенту необходимо произвести таможенную очистку с помощью логистической компании. Изначально товар приходит в страну через таможенного брокера. Получив от клиента уведомление о том, что на склад поступит товар, компания тут же информирует и брокера, отсылая ему копию. Документу, прошедшему процедуру таможенного оформления, присваивается номер таможенной декларации, который автоматически обогащает сведения о приходе. И только затем информация попадает в WMS. То есть в данном случае используется асинхронный режим ожидания: сообщение пришло, но прием на складе возможен лишь после того, как будет получена информация из таможенной системы.

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

На сервисы все процессы делились и в вертикальной плоскости — исходя из уровней. Первым из них является трансляция формата клиента в канонический формат — мепинг. Затем следует уровень непосредственного исполнения канонического формата, где выполняются валидация и оркестровка. Третий слой привязан к системе получателя. В данном случае этой системой является WMS, но архитектура позволяет так же легко подключать и другие системы — например, для управления транспортом. Весной 2008 года в «Национальной логистической компании» надеются закончить внедрение информационной системы управления транспортом на базе Microsoft Dynamix NAV, после чего она сразу будет присоединена к интеграционной платформе.

Сложности SOA-проекта

Хотя представители «Национальной логистической компании» не ощутили каких-либо серьезных проблем в ходе проекта, Егор Савочкин, системный архитектор со стороны подрядчика, отмечает, что с точки зрения разработчика использование SOA существенно усложняет организацию проекта и процедуры развертывания, — ведь в этом случае работа идет уже не с единым приложением, а с множеством компонентов, которые могут быть реализованы посредством разных технологий: BPEL, Java, ESB и прочих. Кроме того, он предостерегает, что хотя BPEL и воспринимается часто как язык самого высокого уровня, на котором можно и нужно реализовывать все задачи, однако практика показывает, что нужно четко понимать его назначение, сильные и слабые стороны и каждый раз тщательно обдумывать, на чем разрабатывать тот или иной сервис — на BPEL или, например, на Java. По его мнению, BPEL применим для реализации либо сервисов высокого уровня абстракции (таких, как бизнес-процесс), либо там, где нужно реализовать сценарий, включающий в себя асинхронные взаимодействия (взаимодействие с человеком, вызов асинхронного сервиса и т. д.).

Промежуточные итоги и перспективы

Закончившийся сейчас этап проекта был пилотным и проходил лишь в рамках интеграции WMS логистической компании с ERP-системой одного клиента. Мечта любого оператора логистических услуг — возможность непосредственного взаимодействия с ERP-системой партнера — пока не реализована. Внешний обмен информацией реализован лишь на уровне файлов, а не на уровне взаимодействия с системой клиента, представленной в виде сервисов. Как следствие все исключительные ситуации требуют вмешательства человека, платформа лишь генерирует оповещение об их возникновении. Однако определенная бизнес-логика в решении уже присутствует, и платформа позволяет ее наращивать.

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

Инструментарий тоже пока используется далеко не на все сто процентов — в некоторой мере задействованы лишь BPEL и Enterprise Service Bus (ESB). Так как предназначение сервисной шины — использовать многопоточную передачу сообщений, когда несколько систем ожидают одной и той же информации, то ESB пока не реализовала всех своих преимуществ.

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

«Внедрение SOA напоминает ремонт, — подытоживает Максим Штенцов, — который нельзя закончить, а можно лишь приостановить. Это долгий путь, и вехами на нём являются подключение новых систем, новых сервисов. Мы для себя отказались от проведения каких-либо финансовых расчетов эффективности внедрения, но качественные улучшения нам уже очевидны».