Предыдущие части:
Часть 1. SAP PI – Создаем асинхронный интерфейс.
Часть 2: Подготовка к разработке в ESR. Активация объектов.
Теперь все подготовительные работы выполнены, переходим непосредственно к разработке интерфейса.
Для начала – несколько общих слов о методологии. Нетерпеливые могут пропустить следующий пункт :).
1. Разработка интерфейсов – методология.
Существует два подхода в разработке интеграционных решений в SAP PI, назовем их “изнутри-наружу” (inside-out) и “снаружи-внутрь” (outside-in).
Для первого подхода характерно то, что все интерфейсные объекты разрабатываются внутри интеграционной платформы, затем для внешних систем формируются так называемые “прокси” (proxy) – заглушки, наполнением которых занимаются программисты, ответственные за внешние системы. Прокси могут быть выгружены для систем, основанных на SAP WebAS ABAP и J2EE-систем. Возможна также выгрузка схем данных интерфейса (например, XSD-схема или WSDL-файл) для последующей реализации интерфейса во внешней системе.
Второй подход характерен получением информации об интерфейсах снаружи (от внешних систем) в виде импорта (например, RFC-модули, XSD-схемы) и затем использование этих данных для создания интерфейса внутри SAP PI.
Рис. 1: принципы построения интерфейсного решения в SAP PI
При способе “изнутри-наружу” владельцем всего интеграционного решения является группа интеграции SAP PI. Разработчики PI создают интеграционный ландшафт самостоятельно; принимают решения о создании, изменении, замене интерфейсов, согласуя их с отделами разработки и/или поддержки остальных бизнес-систем.
В варианте “снаружи-внутрь” интеграционная команда вынуждена создавать общее интеграционное решение на основе уже существующих, либо разрабатываемых другими командами интерфейсных решений.
В SAP PI также возможно два варианта ведения разработки в ESR – “сверху-вниз” и “снизу-вверх”.
В первом случае, вся разработка начинается с моделирования интерфейса в SAP PI: мы определяем, какие компоненты участвуют в обмене, создаем модель – схему обмена данными, затем постепенно “спускаемся” до технических деталей – сначала до структуры данных, правил преобразования между структурами и так до самых “мелких” подробностей интерфейса.
Во втором случае, мы начинаем разработку с технического описания интерфейсов (структура, тип данных и т.п.), постепенно “поднимаясь” до более сложных объектов. В этом варианте разработка необязательно дойдет до модели – можно остановиться, создав все необходимые интерфейсные объекты.
Каждый из вышеперечисленных подходов к разработке имеет свои плюсы и минусы. Какой подход выбрать – зависит от конкретной ситуации; принятой на проекте внедрения методологии; интеграционной задачи.
2. Из чего состоит интерфейс.
Еще немного теории, потерпите, пожалуйста.
Любой интерфейс в SAP Process Integration разрабатывается при помощи набора стандартных интерфейсных объектов. На схеме ниже отображены все объекты и связи между ними.
Рис.2: Интерфейсные объекты в ESR и их связь
Давайте разберем, кто из них за что отвечает и в чем их взаимосвязь:
Service interface – этот объект описывает набор функций, которые приложение может предоставить, либо использует при работе через этот интерфейс. Содержит одну или несколько операций (operation). Каждая операция ссылается на один или несколько типов сообщений (message type).
Message Type – определяет корневой элемент сообщения и ссылается на тип данных (data type).
Data Type – определяет структуру данных сообщения.
Imported Object – полное описание внешнего интерфейса системы SAP (структура IDoc или функциональный модуль RFC).
Fault Message Type – по структуре и функциям аналогичен message type. Используется для сообщений об ошибках операций.
Data Type Enhancement – возможность пользовательского расширения типов данных без модификации стандарта SAP.
External Definition – объект одного уровня с Data Type, также определяет структуру данных, но основан на импортированных в ESR данных.
Context Object – объект, присваивающий уникальное короткое имя определенному полю в структуре сообщения. Используется в дальнейшем как заменитель длинного пути XPath для доступа к данным в объектах конфигурации интерфейсов.
Каждый из интерфейсных объектов в ESR обозначен своей пиктограммой:
Рис. 3: пиктограммы интерфейсных объектов в ESR.
Давайте попробуем создать в ESR наш асинхронный интерфейс с внешней системой.
3. Создание асинхронного интерфейса для внешней non-SAP системы в ESR.
Будем применять подход “изнутри-наружу” и “снизу-вверх”, то есть разрабатывать интерфейс в SAP PI и работать только с необходимыми объектами (без моделирования).
Начиная с версии 7.1 моделирование в SAP PI стало отдельной большой темой. Я не буду раскрывать ее в рамках описания базовых принципов, пусть это будет поводом для отдельного обстоятельного разговора.
Начнем с описания структуры данных. Предположим, что поговорив со специалистами, отвечающими за внешнюю систему, мы получили следующее описание входных данных:
Информация о клиенте:
- Имя клиента (строка символов)
- Код клиента (числовая строка, 8 знаков)
- Класс клиента (фикс. значения, VIP/Normal)
- Адрес (подструктура):
Индекс (числовая строка, 6 знаков)
Страна (строка символов, 50 знаков)
Город (строка символов, 50 знаков)
Улица (строка символов, 255 знаков) - E-mail (строка символов, 50 знаков)
- Телефон (строка символов, 20 знаков)
- Факс (строка символов, 20 знаков)
- Менеджер клиента (строка символов)
- Дата регистрации (дата, ДДММГГГГ)
Создадим такую структуру данных в ESR. Выберем меню Object -> New (Ctrl + N) и тип объекта – Data Type.
Зададим версию программного компонента и пространство имен (их мы создали на этапе подготовки к разработке), техническое имя и описание.
Класс структуры определим как Free-style Data Type.
Рис.4: Создание Data Type
Как я уже упоминал – важно выработать определенную систему наименования объектов и придерживаться ее во всех своих разработках. Это сильно помогает в комплексных разработках, а также при поддержке и доработке уже существующих интеграционных решений.
В данном случае я использую префикс – сокращение от типа интерфейсного объекта, затем указываю бизнес-объект, которым оперирует интерфейс.
После нажатия на кнопку Create открывается окно редактирования типов данных. В верхней части расположены технические данные, в нижней – редактируется структура. Корневой узел имеет то же имя, что и вся структура (DT_Customer).
Установим курсор на корневом элементе, нажмем кнопку добавления новой строки и добавим под-элемент :
Рис. 5: редактирование Data Type
Зададим имя элемента – Name. Как следует из описания структуры данных – это должна быть строка символов. Выбираем тип данных – “XSD Types..” -> xsd:string.
Рис.6: задание типа элемента структуры данных.
Таким же образом задаем следующий элемент – Client_code. Его тип также обозначаем как xsd:string.
По описанию структуры данных мы видим, что на поле наложены ограничения – это должно быть ровно 8 цифр.
Код клиента (числовая строка, 8 знаков)
В столбце Details соответствующей строки раскрываем поле (клик в правой части на значок “раскрыть”) и получаем экран редактора ограничений элемента.
Указываем минимальную и максимальную длину – 8 символов, а также задаем pattern – /d*.
Здесь /d – цифра, * – повтор неопределенное количество раз.
Рис.7: Редактор ограничений поля данных.
Подобным образом задаем все остальные поля структуры, обращая внимание на вложенность элементов (все элементы адреса должны быть под-элементами Address).
Рис.8: готовая структура данных.
Сохраняем наш объект и переходим к созданию вышестоящего интерфейсного объекта – Message Type.
Message Type – это объект, задающий имя корневого элемента будущего сообщения.
То есть это некоторая “обертка” для типа данных. Введена для того, чтобы тип данных можно было использовать в нескольких независимых интерфейсах.
Создаем объект (для автоматического задания пространства имен и программного компонента можно использовать правый клик мышкой на пространстве имен и выборе “New” из контекстного меню).
Рис.9: создание Message Type
Задаем имя и описание, нажимаем “Create”.
Открывается редактор типов сообщения, где нам нужно задать только тип данных и его пространство имен.
Можно это сделать вручную, можно использовать опцию выбора для каждого из полей; можно также использовать опцию Drag-n-Drop, “перебросив” мышкой созданный нами тип данных в символ открытой ладони справа от поля задания пространства имен.
При успешном задании типа данных в нижней части окна редактора отобразится структура будущего сообщения.
Рис.10: задание типа данных в редакторе типа сообщений.
Сохраняем Message Type, переходим к созданию следующего объекта.
Создаем новый объект типа Service Interface.
Рис.11: Создание Service Interface
В редакторе объекта обращаем внимание на поле Category – там должно быть Outbound.
Напомню, что категории inbound (входящий) и outbound (исходящий) для интерфейсов указываются относительно внешней системы. То есть “исходящий из внешней системы” – это outbound, “входящий во внешнюю систему” – inbound.
Оставляем все остальные значения по умолчанию, а в разделе Operations указываем созданный нами на предыдущем шаге Message Type.
Рис.12: редактирование Service Interface
Рис.14: задание Message Type для операции интерфейса.
Обратите внимание на атрибут операции “Mode” – он должен быть установлен в Asyncronous, так как наш интерфейс – асинхронный.
Сохраняем наши изменения, переходим на вкладку листов изменений (Change Lists), активируем все созданные нами объекты.
Рис.14: активация объектов интерфейса
Один интерфейс готов, переходим к определению ответной части – интерфейса с SAP ERP.
4. Создание асинхронного интерфейса для SAP системы в ESR.
Теперь нужно выбрать, на какой из существующих интерфейсов SAP ERP мы должны передать данные нового клиента.
Здесь можно поискать самому (если вы хорошо разбираетесь в функционале ERP), либо спросить коллег, отвечающих за нужный функционал.
Предположим, мы спросили коллег и выяснили, что за внесение нового клиента в систему отвечает функциональный модуль BAPI_CUSTOMER_CREATEFROMDATA1. Для того, чтобы мы могли его использовать, необходимо импортировать его описание.
Открываем контекстное меню на “Imported Objects” (правая клавиша мышки) под нашей версией программного компонента, выбираем “Import of SAP objects”.
Рис.15: импорт интерфейсов из SAP-систем
Основные параметры (SID, мандант, сервер сообщений) системы, из которой будет осуществлен импорт, задаются на уровне версии программного компонента. Дополнительно, перед импортом, можно указать конкретный сервер приложений, с которым будет осуществлено соединение. Задаем также пользователя и пароль.
Рис.16: параметры системы для импорта SAP-интерфейсов
После успешного соединения с SAP-системой мы получаем возможность выбрать нужные нам объекты (RFC-модули, IDoc) и импортировать их в ESR.
Рис.17: выбор импортируемых объектов
После завершения импорта в ESR появится описание структуры данных функционального модуля BAPI_CUSTOMER_CREATEFROMDATA1 (входные данные – request, выходные данные – response, сообщения об ошибках – exceptions).
Рис.18: импортированный в ESR RFC-модуль.
Активируем объекты.
Рис.19: активация объектов импортированного RFC-модуля.
Вот и все, у нас в ESR теперь есть и конечный интерфейс – получатель информации о клиенте.
Рис.20: интерфейсные объекты исходящего и целевого интерфейсов.
О том, как получить из исходного интерфейса целевой, я расскажу в следующей статье.
Спасибо! С нетерпением жду продолжения и статью про моделирование.
Распишите пожалуйста, что означает параметр occurence: 1, 0…1, 1…unbounded
Спасибо.
Сергей, добрый день!
Occurence – это количественное вхождение элемента в документ, то есть сколько раз может встречаться то или иное поле в данных.
= 1 – обязательно один раз
= 0..1 – необязательный элемент, один раз
= 0.. unbounded – необязательный элемент, может быть много
= 1.. unbounded – обязательный элемент, может быть много
Пример – некий абстрактный заказ:
<ORDER> – occurence 1
<COMMENT>blablabla</COMMENT> – occurence 0..1 – необязательный комментарий
<ITEMS>
<ITEM> – occurence 0..unbounded
<ITEM>
…..
</ITEMS>
</ORDER>
@pitroff спасибо за ответ!
Только почему 1…unbounded – необязательный элемент? Разве это не ‘обязательно 1 раз или больше’?
Ошибся, извините.
Исправил, добавил еще один возможный вариант.
Ошибка на рис.1 – в описании походов на обеих картинках присутствует “outside-in”.
Информация в статье расходиться с документацией SAP в понятиях Outside-In и Inside-Out
По SAP процесс Outside-In начинается в ESR
Development begins in the Enterprise Services Repository with the design of service interfaces which can be called directly as a WSDL document.,
а в данной статье, с импорта описания из существующих внешних систем, что более соответстует названию подхода. Где правильно? Часто ли приходится сталкиваться с ошибками в официальной документации SAP?
Да, спасибо, исправил.
По Outside-In – извечная история с тем, что считать за главное – внешнюю систему или интеграционную шину.
В моей статье за центр принята шина, то есть разработка либо “внутри” шины и экспорт proxy “наружу”; либо готовый интерфейс “снаружи” и импорт его “вовнутрь”.
В документации – наоборот, за “центр вселенной” принята внешняя система.
Подход и там, и там описан одинаковый, разница только в терминах.
По документации – ошибки бывают. Сильно критичных не находил, но по мелочи – было.
По сути – описание подхода одинаковое
Здравствуйте! А как быть с Fault message? Как получать ошибки при получении внешней системы наших сообщений? Сейчас мы ничего не получаем (асинхрон.обмен).
Здравствуйте!
У нас асинхронный обмен: SAP ERP – PI – внешние системы (WMS, Сайт, etc).
Можете ли что-нибудь посоветовать по следующим вопросам:
1) Мы не видим responses, которые нам шлёт WMS (речь о технических ответах о получении от WMS to SAP PI). Когда они шлют status (response), то наш PI воспринимает это как статус Ок и в ERP, и в PI показывает статус сообщения как Ок. Не зависимо от того, что на самом деле было в том ответе (error code 0 or ne 0). Если WMS вместо response шлет нам эксепшен, то сообщения встают в статус Waiting/ Hold и блокируют свою очередь (как этого избежать?). Эксепшен можно обнаружить только на уровне Джава-монитора.. В SXMB_MONI его не видно.. 🙁 У нас есть отдельное сообщение SYSSTAT для ответа с ошибками данных. Но это уже этап обработки полученного сообщения. А если внеш.система его не смогла получить..как мы об этом узнаем..?
ВОПРОС: Как сделать адекватную обработку ошибок, чтобы их можно было оперативно обнаруживать, если у нас асинхронный обмен (который вроде как не подразумевает ответов..).??
2) В нашем асинхронном обмене периодически зависают очереди.. Иногда это обнаруживается очень поздно, когда весь обмен встает колом. Тогда выясняется что неделю назад в какой-то очереди завис пакет который заблокировал все остальные пакеты.. У нас одновременно идет обмен с несколькими системами.. В каждой очереди могут быть пакеты из разных систем. и если один по какой-то причине встал, то он тормозит всю очередь..
ВОПРОС: Есть ли какой-то способ оптимизировать обмен для достижения наилучшей проходимости и наименьшим риском в случае проблем по одному из обменов..?