Что такое интеграционный сценарий

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

На решение этих задач направлен комплекс инструментов системы T­FLEX DOCs, который реализует новые технологии и стандарты, позволяя строить комплексные, межсистемные процессы для взаимодействия T­FLEX DOCs и сторонних бизнес­приложений, причем как внутри предприятия, так и с участием систем бизнес­партнеров.

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

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

Все это заставляет прогрессивных руководителей организаций искать новый подход для интеграции своих процессов. Подобные компании движутся от разнородных взаимосвязанных решений к широкой коммуникационной инфраструктуре в едином информационном пространстве. Это основа, которая позволяет решать поставленные задачи и способна развиваться в будущем. Такой основой является технологическая платформа Т­FLEX DOCs Line и построенная на ее основе система Т­FLEX DOCs.

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

Преодолеваем барьеры
на пути к интеграции

В дополнение к интеграции неоднородных систем компании хотят сохранить накопленный функционал унаследованных приложений, поскольку мгновенно воссоздать функциональность таких систем в T­FLEX DOCs невозможно. Воссоздание функциональности на базе единой платформы — это планомерный процесс. Поэтому требуется связывание разнородных систем через единый интерфейс их запуска. Также многие организации ищут решение, основанное на стандартах и перспективной сервисно­ориентированной архитектуре, поскольку долгосрочное устойчивое решение требует следования стандартам и правилам работы в распределенной бизнес­среде.

С точки зрения компании разнообразие ее программных средств пользователям не должно быть заметно. Бизнес­процессы должны поддерживаться технической связью различных приложений и систем. «Т­FLEX DOCs Приложения» позволяет регистрировать унаследованные и сторонние системы и встраивать команды запуска данных приложений в интерфейс Т­FLEX DOCs. Благодаря этому компании могут интегрировать разные версии систем, основанных на различных технологиях, и обеспечить реализацию межсистемных процессов, которые требуются компании.

«Т­FLEX DOCs Разработчик» предоставляет сервисы и средства, которые являются необходимыми в неоднородном и сложном системном ландшафте, например: инфраструктура обмена сообщениями, средства конфигурирования для управления процессами и потоком сообщений, средства преобразования формата сообщений между отправителем и получателем (мэппинг), графические средства построения бизнес­процедур. В то же время, «Разработчик» предоставляет единый, централизованный репозитарий для создания интерфейсов конечных пользователей (АРМ), создания и хранения макрокоманд, создания произвольных справочников (в том числе справочников­аналогов); поддерживает управление межсистемными бизнес­процессами; содержит интегрированный набор средств, помогающий компаниям самостоятельно создавать нужные им интерфейсы, отображения и правила маршрутизации сообщений.

Рис. 1. Специализированные справочники Т-FLEX DOCs для управления синхронизацией данных со сторонними системами (А2А)

Основными задачами для «Т­FLEX DOCs Синхронизация» являются маршрутизация и преобразование сообщений, преобразование объектов одной системы в объекты другой системы с сохранением эквивалентности связей и параметров объектов, а также перевод формата данных систем­отправителей в форматы, понимаемые системами­получателями. Наиболее востребована интеграция между PDM/PLM­системами и ERP­системами. Поэтому в данной статье речь в основном будет идти об опыте интеграции этих систем. «Синхронизация» — это набор специализированных справочников, который содержит предопределенный интеграционный контент для ERP­приложений (рис. 1). Это решение эффективно для интеграции процессов предприятия, реализованных в распространенных бизнес­приложениях ERP, например «1С». Этот предопределенный контент сокращает время интеграционных проектов, поскольку предоставляет правила преобразования форматов данных и правила маршрутизации для определенных типовых взаимодействий между системами.

Одной из трудных задач интеграции является организационная задача. Как правило, это обусловлено следующими причинами:

• у PLM­ и ERP­систем разные «хозяева» (подразделения и специалисты);
• парадигмы этих систем различны, то есть структура данных и алгоритмы работы этих систем опираются на разные стандарты;
• в PLM­системе рождается основная часть данных, которые являются исходными для работы ERP­системы, но их представление различно.

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

Рис. 2. Схема интеграционного каталога и службы преобразования

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

После извлечения информации с правилами трансформации (отображения сообщений) из интеграционного каталога (справочника аналога), служба запускает на выполнение преобразование или C#­программу­макрос над бизнес­содержимым исходного сообщения.

Справочники интеграционного каталога содержат данные в исходном формате без преобразования. При этом они дополнительно хранят связь на эквивалентный объект обоих систем, что позволяет службе отрабатывать события в фоновом режиме (рис. 3).

Рис. 3. Интеграционный каталог и справочники службы преобразований

Типовые интеграционные сценарии

С помощью «Т­FLEX DOCs Разработчик» компании могут автоматизировать свои бизнес­процессы и при этом задействовать различные приложения и сетевые технологии. Назовем некоторые из типовых интеграционных сценариев:

• Интеграция приложений (Application­to­Application, A2A);
• Интеграция бизнес­сценариев (Business­to­Business, B2B);
• Применение архитектуры SOA.

Интеграция A2A

Один из наиболее часто используемых сценариев интеграции различных бизнес­приложений — основная функция еще с развития корпоративных сетей. Например, пересылка записей о сотрудниках из системы управления персоналом (HR) в бухгалтерскую систему, передача информации о пользователях домена в PDM­систему и т.п.

В Т­FLEX DOCs такие задачи решаются с помощью либо пакетной обработки, либо унификации всех корпоративных данных и хранении их в единой базе данных (MDM), доступной нескольким приложениям. Данные можно синхронизировать, то есть сделать их ассоциативными, а можно передать без синхронизации (рис. 4).

Рис. 4. Выбор пакета данных для синхронизации с «1С»

Рис. 5. Настройка метода и правил синхронизации

Настройка правил передачи данных производится в Синхронизаторе справочников. На рис. 5 показан фрагмент настройки правил преобразования данных между T­FLEX DOCs и «1С». Для справочников DOCs со сложной иерархией, характерной, например, для структур изделий, есть возможность задать эквивалентную связь между объектами такого справочника.

Подобный сценарий интеграции (А2А) с системой «1С» успешно внедряет ООО «Инфо­Сервис» (г.Пенза), но добавляет собственные сервисы, которые позволяют «заточить» интеграцию под задачи клиента.

Интеграция B2B

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

При использовании пакетного режима (А2А) для обеспечения непрерывного потока данных приходится прибегать к следующей схеме: приложение­инициатор генерирует документ для передачи партнеру, в то время как специализированная коммуникационная система, например подcистема электронного обмена документами (EDI), получает документ, преобразует его в необходимый партнеру формат и помещает в «почтовый ящик» получателя. Описанный процесс оказывается очень затратным и допускает сбои, поскольку в процессе участвует несколько систем и зачастую требуется ручной перенос данных, то есть полностью исключить человеческий фактор в этом случае не удается.

Преодолеть указанные проблемы помогает применение API T­FLEX DOCs, с помощью которого администратор настраивает в бизнес­процедуре действие интеграционного брокера. В отличие от традиционных методов трансформаций, интеграционный брокер использует исполняемую программу­преобразователь, что оказывается быстрее и требует меньше вычислительных ресурсов. Каждый объект передается при наступлении соответствующего перехода бизнес­процедуры, то есть в нужное время в нужной степени проработки.

Подобный сценарий интеграции (B2B) с системой «ЭЛЮДИЯ» успешно внедряет ООО «Фастек» (г.Чебоксары). Для транспортировки данных используется XML­формат.

Применение архитектуры SOA

Компании все чаще начинают применять сервисно­ориентированные архитектуры для реализации универсального и основанного на открытых стандартах доступа к существующим приложениям — зачастую и для синхронных действий, в которых пользователи ожидают немедленного отклика от системы. Данный подход подразумевает использование промежуточного программного обеспечения (middleware) для представления различных приложений единообразным способом, в виде веб­сервисов.
Эти новые сервисы должны быть явно доступны разработчикам приложений, допускать поиск, извлечение и помещение сервисов в центральный репозитарий для повторного использования, а также применимыми для построения композитных приложений (с которыми, в результате, и работает конечный пользователь).

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

Использовалось несколько стандартов веб­сервисов SOAP, WSDL, XML.

Подобный сценарий интеграции с системой «SAP» успешно внедряет ООО «ASAP Consulting» (г.Москва), в качестве сервисной шины применяя SAP NetWeaver PI.

В заключение

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

В системе T­FLEX DOCs имеется набор средств, предназначенных для следующих процедур:

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

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

САПР и графика 2`2016

• .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

Всем спасибо за прочтение и обратную связь!

Интеграционное тестирование

Что такое интеграционное тестирование

Будет ли новая большая система работать так же хорошо как и её части?

Есть ли смысл тестировать систему целиком в данный момент?

Взаимодействуют ли части между собой правильно?

Ответить на эти вопросы можно только после интеграционного тестирования (Integration Testing).

Лирическое отступление

Определение

ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ определяется как тип тестирования,
при котором программные модули интегрируются логически и тестируются как группа.

Зачем делать интеграционное тестирование

Хотя каждый программный модуль проходит модульное тестирование (Unit Testing),
дефекты все еще существуют по разным причинам, таким как:

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

Пример интеграционного тест кейса

Test Case ID — это номер теста. Test Case Objective — цель. Test Case Description — описание. Expected Result — ожидаемый результат.

Переход на новую страницу осуществлён, но я по-прежнему на том же сайте.

Нужно нажать кнопку «Найти отели»

Переход осуществлён, на сайте букинга есть упоминание Авиаcейлз. Интеграция
Aviasales — Booking работает.

Проверим интеграцию Booking — Google Maps. Нажимаем кнопку «На карте»

Отели видны на карте. Интеграция Booking — Google Maps работает.

Интересно почему у Aviasales интеграция с Booking, когда у них есть
свой агрегатор отелей —
Hotellook

Подходы, стратегии, методологии интеграционного тестирования

Подход Большой Взрыв

Преимущества

Если всё работает, то таким спобом можно сэкономить много времени.

Недостатки

Инкрементальный подход

• Снизу Вверх

• Сверху Вниз

Заглушки и драйверы

Как делать заглушки?

Конечно, всё зависит от того, для чего Вы делаете заглушку. Кругому люку нужна круглая крышка.

Подход Снизу Вверх

Преимущества

Недостатки

Метод Сверху Вниз

Преимущества

Недостатки

Смешанный подход — сэндвич

Преимущества

Недостатки

Нужно дополнительно время на координацию и вовлечение потенциально большего числа участинков тестировани.

Как организовать интеграционное тестирование

1. Подготовка Плана интеграционных тестов
2. Разработайте Тестовые сценарии, Кейсы и Сценарии.
3. Выполнение тестовых случаев с последующим сообщением о дефектах.
4. Отслеживание и повторное тестирование дефектов.
5. Шаги 3 и 4 повторяются до тех пор, пока интеграция не завершится успешно.

Краткое описание интеграционных тест планов

Включает в себя следующие атрибуты:

• Методы/подходы к тестированию (как обсуждалось выше).
• Области применения и вне областей применения Элементов интеграционного тестирования.
• Роли и обязанности.
• Предпосылки для интеграционного тестирования.
• Среда тестирования.
• Планы снижения рисков.

Входные и выходные критерии интеграционного тестирования

Критерии входа и выхода на этап интеграционного тестирования в
любой модели разработки программного обеспечения

Входные критерии :

• Модульное Тестирование Компонентов/Модулей
• Все ошибки с высоким приоритетом исправлены и закрыты
• Все модули должны быть успешно завершены и интегрированы.
• План интеграционных тестов, тестовый случай, сценарии, которые должны быть подписаны и задокументированы.
• Необходимая тестовая среда для настройки интеграционного тестирования

Выходные критерии:

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

Руководства и советы

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