Всем привет!
В этот раз мы решили вернуться к теме ERP-систем. В линейке продуктов SAP есть разные продукты для компаний самых разных размеров — от мультинациональных корпораций до среднего и малого бизнеса. Существуют и комбинации — когда в компаниях используют сразу несколько типов ERP, для штаб-квартир и для филиалов. Такие случаи и называют двухуровневыми ERP, и SAP Business One отлично подходит в качестве «облегченной» системы. В этой статье мы расскажем о подробностях и деталях интеграции.
Но для начала ответим на вопрос — что такое двухуровневая ERP?
Термин «двухуровневая ERP» уже стал привычным для многих. Концепт двухуровневой ERP-системы применяется в корпорациях, которым нужен единый стандарт отчетности и бизнес-приложений в своих дочерних структурах или филиалах. В маленьких бизнес-единицах по многим причинам просто нецелесообразно использовать большие ERP: другие бизнес-процессы, сложность адаптации сотрудников и медленная скорость развертывания, которое может занять месяцы. А если вы добавите сюда ещё время на обучение персонала, затраты на сопровождение системы и при всём этом вам необходимо внедрить «большое» решение сразу в 40 филиалах — на это уйдёт много времени (часто даже месяцы) и потребуются значительные затраты. Для сравнения — «маленькие» решения могут быть внедрены за несколько недель.
Двухуровневая ERP сегодня применима не только для больших корпораций, с их отношениями «штаб-квартира => филиал». Эта стратегия жизнеспособна при работе с поставщиками, дистрибьюторами, дилерами и обслуживающими организациями.
Пример нашего европейского клиента — компании Heineken Spain. У них появилась задача — как наладить обмен данными между 600 дистрибьюторами и Heineken Spain по заказам, движению товара и счетам на оплату и затем автоматизировать все процессы. В результате в компании решили разработать решение на базе SAP Business One.
В Heinekein Spain придумали сценарий с использованием интернета вещей — они собирают данные с более чем 300 тысяч датчиков, которые встроены в пивные краны. Компания получает информацию о потреблении пива с единую информационную систему. В результате в Heineken поняли, как лучше управлять каналом продаж, оптимизировать цепочку продаж и улучшить показатели. Также они стали получать данные о потреблении пива в режиме реального времени, можно сказать, «из каждого крана».
С двухуровневыми ERP-системами не всё бывает идеально. Давайте посмотрим, какие проблемы могут возникнуть при интеграции разных систем.
Зачем вообще внедрять ERP-системы в филиалах или дочерних компаниях? В крупных холдингах или больших компаниях, безусловно, хотят получать прозрачную аналитику или отчетность о бизнес-ппроцессах. При это часто случается такая проблема — в каждом филиале ставят своё решение, удобное местным специалистам, и в итоге в компании появляется «зоопарк» систем и сервисов. И конечно же, они могут быть не совместимы с «головной» ERP по самым разным причинам — например, из-за использования решений с закрытыми API. В этом случае нельзя надеяться ни на единую отчётность, ни на какую-то автоматизацию бизнес-процессов.
Что есть у SAP? У нас есть целая линейка ERP-систем, под разные задачи и цели. Для компаний со сложными бизнес-процессами нужны «тяжеловесы» — здесь выбирают S/4HANA, ECC или R/3. Для организаций попроще или поменьше подходит SAP Business One. При этом B1 легко может быть интегрирован с большими решениями SAP — S/4HANA, Hybris, Ariba, Customer Checkout, Concur, мобильные приложения и даже государственные сервисы.
Какие возможности есть в SAP Business One для разработки интеграционных сервисов:
- .Net разработка для интеграции через SAP Business One SDK/DI-API
- .Net разработка для интеграции через Service Layer (доступно для SAP Business One версия для SAP HANA)
- Integration Framework (Интеграционная платформа)
Особенности, целевая аудитория и сфера применения приведены в таблице:
Далее статье мы в деталях расскажем о платформе Integration Framework.
Integration Framework
Платформа SAP Business One Integration Framework (B1iF) доступна в ERP-системе SAP Business One, начиная с версии 8.8. Её можно установить на базу данных SAP HANA или MS SQL. Основная задача B1iF — отправлять и принимать данные из внешних (SAP и неSAP) систем. Пакеты интеграционных сценариев строятся внутри Integration Framework. Логика сценариев основана на бизнес-процессах: управление ошибками, конфликтами, транзакциями (и их порядком выполнения), гарантия выполнения, мониторинг, отладка и администрирование выполняются в B1iF.
Для разработки сценария интеграции двух систем навыки программирования не требуются.
Последовательность процесса задаётся с помощью встроенного графического дизайнера в платформе. Встроенные функциональные единицы B1iF BizFlow Atoms используются для сопоставления значений, настройки вызовов (SAP Business One, SAP ERP, HTTP, SQL, файловые системы и т.д.), XSLT преобразований. Сопоставление данных осуществляется с помощью XSLT-преобразований во встроенном (или внешнем) XML редакторе. Инструменты отладки позволяют разработать индивидуальную последовательность процесса в структурированном и наглядном виде.
Интеграционные сценарии, которые выполняются в интеграционной платформе, называются пакетами сценариев. Все необходимое для целостного обмена данными между системами находится в пакете сценария.
Пакет сценария содержит в себе один или более шаг сценария. Шаг сценария — это определенный интеграционный поток, который включает в себя входящую (inbound) фазу, фазу обработки (processing) и исходящую (outbound) фазу.
На первой фазе интеграционная платформа получает входящее сообщение и переводит его в XML формат. В процессе фазы обработки происходит трансформация и обработка сообщения, определение получателя и сопоставление параметров сообщения. На этапе вывода интеграционная платформа трансформирует сообщение в формат ERP-системы получателя и отправляет сообщение.
В процессе дизайна шага сценария необходимо задать основные параметры: способ запуска шага, какие системы взаимодействуют между собой, каким образом интеграционная платформа обрабатывает сообщение, существуют ли дальнейшие шаги (например, вызов внешней системы).
Шаги сценария могут быть следующими:
1. Синхронные (запрос-ответ):
— отправитель формирует запрос, который инициирует выполнение шага
— результат обработки возвращается отправителю как ответ
2. Асинхронные (отправитель получателю):
— запускается по таймеру, событию или вызову
— данные поступают из системы-отправителя, обрабатываются, трансформируются и передаются получателю в любое время
Входящий канал описывает тип системы-отправителя и интерфейс (API), которые могут быть использованы интеграционной платформой для получения входящих данных. В качестве входящего канала могут быть использованы HTTP, файл, пустое сообщение (Void (таймер)), Web Service, SAP Business One и SAP ERP.
Исходящий канал описывает тип системы-получателя и интерфейс (API), который будет использован интеграционной платформой для передачи данных. В качестве исходящего канала могут быть выбраны HTTP, файл, пустое сообщение (Void, только для синхронных шагов), Web Service, база данных, SAP Business One и SAP ERP.
Для фазы обработки используется графический инструмент. Основным элементом дизайна являются атомы. Атомы выстраиваются в последовательность и используются для вызова внешних систем (например, база данных SQL или электронная почта). Каждый атом получает входящее сообщение, выполняет определенные задачи и передает сообщение следующему атому.
Для передачи данных между интеграционными шагами используется внутренний механизм обработки очереди. Таким образом, можно объединять интеграционные шаги в пакет сценария.
Пример разработки интеграционного сценария
Бизнесу необходим доступ к данным о своих процессах в режиме реального времени, а также автоматизация ручного труда. Автоматизация процессов может помочь компании оптимизировать загрузку персонала и уменьшить риски ошибок при передаче информации. Интеграция с системой поставщика или отдельного вида бизнеса позволит устранить эти риски.
Давайте рассмотрим простой практический пример интеграции двух систем — заказчика и поставщика. Обе компании работают в SAP Business One и хотят автоматизировать процесс оформления заказов. В данном примере «Заказ на закупку» в компании 1 передается в компанию 2, где формируется документ «Заказ на продажу». Компания 2 подтверждает формирование заказа в компанию 1.
Интеграционный сценарий можно запустить при помощи создания документа «Заказ на закупку» в компании 1. В сценарии будет 2 интеграционных шага:
- на первом шаге формируется документ «Заказ на продажу» в компании 2 с помощью атома B1 Object call
- атом Call Step используется для связывания со вторым шагом
- на втором шаге происходит информирование пользователя компании 1 о статусе созданного документа «Заказ на продажу»
Для запуска интеграционного сценария нам потребуется код основных данных компании 1. Эти данные не содержатся в «Заказе» и не передаются в интеграционную платформу. Для хранения этой информации может быть использована глобальная таблица (global table). Для задания параметров глобальной таблицы необходимо определить тип глобальной таблицы (тип 1 для отношений 1<->1; тип 2 для отношений 1 <-> N), длину и названия полей таблицы:
После создания глобальной таблицы можем внести в нее данные:
Далее для интеграционного шага 1 определим входящий канал:
- тип канала — SAP Business One
- запуск по событию B1 Event (создание документа «Заказ на закупку»)
- в качестве идентификатора используется ID объекта «Заказ на закупку» (22)
- получение данных по DI-API с типом Объект
Для исходящего канала выбираем пустое сообщение (void), т.к. у нас нет системы-получателя:
Перейдем к конфигурации процесса обработки сообщения. Нумерация атомов осуществляется в порядке добавления в процесс.
Атом преобразования (атом1) является не обязательным. Он позволяет хранить информацию об условиях запуска и системе-отправителе для последующего использования в других атомах. Значение CustomerCode для компании 1 загружается из глобальной таблицы. Значение User ID выбирается из секции T (запуск, trigger) XML преобразования входящего события B1 Event, создающего «Заказ на закупку».
<Values>
<xsl:variable name="MappingCardCode" select="document('/com.sap.b1i.vplatform.scenarios.design/vPac.xxx.B2BB1/vTbl.B1MappingCardCode.xml')"></xsl:variable>
<xsl:variable name="Vendor" select="$msg/BOM/BO/Documents/row/CardCode"></xsl:variable>
<xsl:variable name="Customer" select="$MappingCardCode/table/row[./col[2]=$Vendor]/col[1]"></xsl:variable>
<CustomerCode>
<xsl:value-of select="$Customer"></xsl:value-of>
</CustomerCode>
<B1User>
<xsl:value-of select="/vpf:Msg/vpf:Body/vpf:Payload[./@Role='T']/Event/b1e:b1events/b1e:b1event/b1e:userid"></xsl:value-of>
</B1User>
</Values>
При конфигурации атома B1 Object (атом2) будем использовать следующие параметры:
- Sysid: ID, присвоенный SAP Business One в интеграционной платформе
- B1 Login: присваивается из настроек интеграционной платформы
- Method: синхронный
- Object identifier: 17 (заказ на продажу)
- Key Name: DocEntry
- Key Value: N/A (заполняется автоматически в момент создания документа в SAP Business One)
- Payload: имя предшествующего атома преобразования
Перед атомом B1 Object мы используем предшествующий атом преобразования (атом3). В этом атоме подготавливается информация для загрузки в атом2 (B1 Object).
В разделе Documents необходимо определить значения заголовка документа «Заказ на продажу»:
- код основных данных заказчика для компании 1 (CardCode)
- дата документа (DocDate) задается вызовом функции даты и времени, встроенной в интеграционную платформу, которая возвращает текущую дату и время
- дата отгрузки (DocDueDate) вычисляется на основе DocDate
В разделе Document_Lines определяются строки документа «Заказ на продажу». Необходимая информация извлекается из секции S (сообщение из системы-отправителя, sender message) входящего документа «Заказ на закупку».
<Documents>
<row>
<xsl:variable name="date">
<xsl:call-template name="b1ilib.today"></xsl:call-template>
</xsl:variable>
<DocDate>
<xsl:value-of select="$date"></xsl:value-of>
</DocDate>
<DocDueDate>
<xsl:call-template name="b1ilib.date_plus">
<xsl:with-param name="date" select="$date"></xsl:with-param>
<xsl:with-param name="x" select="20"></xsl:with-param>
</xsl:call-template>
</DocDueDate>
<xsl:variable name="Customer"
select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom1']/Values/CustomerCode"></xsl:variable>
<CardCode>
<xsl:value-of select="$Customer"></xsl:value-of>
</CardCode>
<NumAtCard>
<xsl:value-of select="$msg/BOM/BO/Documents/row/DocNum"></xsl:value-of>
</NumAtCard>
</row>
</Documents>
<Document_Lines>
<xsl:for-each select="$msg/BOM/BO/Document_Lines/row">
<row>
<ItemCode>
<xsl:value-of select="ItemCode"></xsl:value-of>
</ItemCode>
<Quantity>
<xsl:value-of select="Quantity"></xsl:value-of>
</Quantity>
</row>
</xsl:for-each>
</Document_Lines>
<xsl:include href="../../com.sap.b1i.system.lib/xsl/datetime.xsl"></xsl:include>
Завершающий атом (атом0), как правило, преобразовывает данные для передачи в систему-получатель. В нашем сценарии в качестве типа исходящего канала выбрано пустое сообщение (void). Тем не менее, мы должны определить данный атом для создания записи в логах. В элементе будут содержаться атрибуты DIresult и DImsg. Атрибут DImsg должен содержать ключ созданного документа (в случае успешного завершения сценария) или сообщение об ошибке (в случае неуспешного выполнения).
<xsl:variable name="Status" select="$msgB1/@DIresult"></xsl:variable>
<xsl:variable name="Entry" select="$msgB1/@DImsg"></xsl:variable>
<Msg>
<xsl:value-of select="concat('Message: ',$Status, ', DocEntry:
',$Entry)"></xsl:value-of>
</Msg>
Атом4 и атом5 относятся ко второму интеграционному шагу: отправка сообщения пользователю компании 1. Атом вызова (с типом Call step) не подразумевает предшествующий атом преобразования. Тем не менее, как и в случае первого шага, для атома4 мы зададим предшествующий атом преобразования (атом5). В параметрах атома5 указываем данные, передаваемые в вызываемый атом. Эти данные в нашем случае будут содержать элемент с атрибутами DIresult (результат обработки атома B1 Object) и код пользователя SAP Business One (B1User).
<B1Result>
<Result>
<xsl:value-of
select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom2']/@DIresult"></xsl:value-of>
</Result>
<B1User>
<xsl:value-of
select="/vpf:Msg/vpf:Body/vpf:Payload[./@id='atom1']/Values/B1User"></xsl:value-of>
</B1User>
</B1Result>
Для атома вызова задаем параметры:
- тип обработки вызываемого атома (синхронный или асинхронный)
- имя вызываемого атома
- атом с входными параметрами (предшествующий атом преобразования)
Перейдем к формированию второго интеграционного шага. Мы хотим отправлять разные сообщения пользователю компании 1 в зависимости от результата процесса создания документа. Для этого будем использовать атом с типом начала разветвления (branch).
Для атомов с условиями может быть использовано несколько атомов с типом path и только один атом типа otherwise. Интеграционная платформа работает только с результатами истина при выполнении path. Поэтому, в нашем случае необходимо задать только условие для атома path:
/*[/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S']/B1Result/Result = 'success']
Атом otherwise будет работать только в том случае, если результатом выполнения атома path будет ложь. Атом unbranch завершает ветвление и содержит результаты выполнения атомов условий.
В параметрах атомов B1 Message необходимо указать тему и текст сообщения, а также информацию о пользователе
/vpf:Msg/vpf:Body/vpf:Payload[./@Role='S']/B1Result/B1User
В завершающем атоме второго интеграционного шага необходимо осуществить проверку выполнения ветвления. Для этого можно использовать шаблон XSL, хранящийся в интеграционной платформе.
Активация и проверка сценария
Интеграционная платформа проверяет целостность интеграционного сценария при открытии окна настройки сценария.
В нашем случае проверка выполнена успешно, и мы можем приступить к выполнению сценария.
Создаем «Заказ на закупку» в базе данных компании 1 у поставщика V22222.
После создания документа мы видим уведомление от пользователя B1i, что заказ создан успешно:
В компании 2 создан «Заказ на продажу» с данными из «Заказа на закупку» и указанием номера документа в компании 1:
Заключение
В качестве заключения предлагаю посмотреть ролик нашего клиента — компании DeLaval. Компания уже давно и активно использует стратегию двухуровневой ERP: в головном предприятии и в крупных филиалах — SAP ERP, а в малых дочерних структурах — SAP Business One. В этом видео Steve Woodgate, Business Integration Director в компании DeLaval, рассказывает о причинах и результатах выбора SAP Business One в качестве ERP второго уровня.
Ознакомиться с примерами внедрений SAP Business One можно на нашем сайте.
Видео с обзорами возможностей решения и не только доступно на нашем Youtube-канале.
В следующей статье мы расскажем о возможностях новой версии SAP Business One 9.3, которую сейчас активно тестирует как SAP, так и клиенты. Кстати, одним из первых «живых» клиентов в мире на SAP Business One версия 9.3 стал заказчик из России — компания «Телеком-Биржа». Видео с комментариями клиента можно посмотреть здесь: youtu.be/GTgm-nJddDI
Всем спасибо за прочтение и обратную связь!
Автор: SAP
