Подробно про SAP ALE

SAP ALE — Application Link Enabling — технология обмена данными, разработанная компанией SAP AG. Технология, потому что это набор инструментов, протоколов, форматов, которые позволяют обмениваться данными в режиме реального времени или оффлайн режиме между САП и не-САП системами. Это огромный пласт настроек, функциональности и возможностей, которыми мы редко пользуемся. Предлагаю рассмотреть технологию комплексно в виде стека.

CPIC — Common Programming Interface for Communication — низкоуровневый коммуникационный протокол. Почитать можно вот тут https://www-01.ibm.com/software/network/commserver/windows/library/cpic.htm
RFC — Remote Function Call — высокоуровневый коммуникационный протокол удаленного вызова
tRFC (tansactional RFC) / qRFC (queued RFC) / aRFC (asynchronous RFC) / sRFC (synchronous RFC) — способ доставки сообщения до получателя и подверждения факта доставки
IDOC — Intermediate DOCument / BAPI (Business Application Programming Interface) — формат сообщения, которое будет доставлено
EDI — Electronic Data Interchange — процедура обмена данными SAP-nonSAP. Международные стандарт по-совместительству.
ALE — Application Link Enabling — процедура обмена данными SAP-SAP.

Вот это и предлагаю обсудить, а спецам меня поправить.
RFC — Remote Function Call, механизм для удаленного вызова функций в системах. Идея простая и заключается в том, что, если мы знаем имя какой-то функции на удаленном сервере, то мы можем сказать: «Привет, удаленный сервер. Я знаю, что у тебя есть вот такая функция, с такими параметрами. Я хочу ее запустить _у тебя_. Вот мои полномочия, вот мои данные для этой функциий, запусти и скажи, что получилось». Удаленный сервер чешет черепушку, шуршит дисками и, удостоверившись, что это не Баба-Яга, запускает у себя, на своих данных эту функцию под логином просящего. При этом программа на том же сервере может запустить эту же самую функцию локально, как бы у себя дома. Наличие галочки в транзакции SE37 для функционального модуля определяет, можно ли запускать эту функцию удаленно или нет.

RFC сам по себе это протокол, которым пользуются компоненты и сервера SAP для общения друг с другом. У вендора есть RFC SDK, который можно скачать и использовать в своих разработках. Если присмотреться к стандартными соединениям в транзакции SM59, то можно увидеть, что многие коммуникации идут через RFC и так называемые зарегистрированные программы, например, печать документов, Adobe Lifecycle Designer, SAP GUI и другие. Идея в том, что мы на сервере можем повесить обработчик на RFC вызовы таким образом, что он будет срабатывать при обращении к системе и выполнять полезные нам функции. Я такой обработчик использовал для связи сервера по обработке временных отметок с SAP, когда SAP вызывал через ALE программу (в SM59 была зарегистрированна программа, а не адрес сервера), а программа по своему протоколу связывалась с сервером обработки отпечатков пальцев и просила его выслать данные. Так что, если у вас есть свой станок, а вы хотите прицепить его к SAP, то пишите свой драйвер, драйвер регистрируете как RFC совместимый в SAP, а потом при формировании товарной накладной через поток операций вызываете печать медальки на станке. Это и есть тот самый IoT, от которого сейчас все прутся (после биткоинов).

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

• sRFC (synchronous RFC) — синхронный вызов. Вызвал, система тут же бросается к удаленной системе. Если та недоступна, то немедленно возвращается ошибки.
• tRFC (tansactional RFC) — транзакционный вызов. Вызвал, система побежала пытаться достучаться. Если удаленная система в запое, то запрос на вызов откладывается в ящик, который называется LUW (Logical Unit of Work). Такие ящички копятся-копятся, а потом как партнер очнется, то контейнером заезжают в него. При этом нет никакой трезвой связи кто за кем должен заезжать, ибо работают как на Почте России — все в кучу. Единственное, что гарантируется, что внутри одного ящика все вызовы будут выполнены последовательно либо не выполнены вообще. Мониторинг осуществляется в транзакции SM58
• aRFC (asynchronous RFC) — улучшенный вариант Почты России, практически такой же tRFC. Появляется больше общения, так как система теперь не будет складировать вызовы в ящики, а либо сразу пошлет в лес, либо при доступном партнере отправит ему вызов. Чем это отличается от sRFC? Тем, что sRFC вызов обязательно дождется ответа удаленного сервера прежде чем перейдет на следующую строчку кода. aRFC отправит вызов и пойдет дальше. Вызов может случиться, а может не случиться.
• qRFC (queued RFC) — продвинутый вариант tRFC с тем отличием, что последовательность ящиков LUW соблюдается один в один. Таким образом гарантируется минимальная целостность и доставка сообщений до адресата. Мониторинг осуществляется в транзакциях SMQ(1,2,S,R)

Зачем я все это вам пишу? Чтобы HR консультант понимал начинку того, что он настраивает, как он и что он должен написать в спеке программисту, ибо порядок обработки данных во внешних системах это бизнес-требование.

Поехали дальше. IDOC это структура данных, которая может быть представлена в виде плоского файла, XML, CSV, JSON, котика или любого другого формата. Структура состоит из трех частей:

• Контрольная/управляющая запись.
• Сегменты данных.
• Статус документа.

Как у нас концептуально происходит процедура обмена информацией между системами? По событию или расписанию запускается программа выгрузки данных по HR (для примера). Либо по указателям изменений, либо вручную через PFAL вызывается функциональный модуль, который создает IDOC — на основании селекционного экрана, выбранных данных собирает все и заполняет все структуры IDOC.

Дальше система смотрит на модель распределения в BD64. У каждого IDOC есть свой тип сообщения, который мы указываем в модели распределения по принципу:

система отправитель — система получатель — тип сообщения — фильтры. Если все условия совпали, то IDOC помещается в очередь на отправку в указанную систему. Причем система это не всегда SAP, а виртуальный контейнер — логическая система, под которой может быть SAP, котик, Share Point или еще что угодно.

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

Если идет удаленный вызов BAPI, то система также по модели распределения ищет кому приписан такой BAPI вызов, а затем осуществляет qRFC вызов или sRFC. Так, например, работает проверка FICO параметров при проводках в заработной плате.

Это очень упрощенно. Отдохнули?

Теперь возьмем скальпель.

IDOC — сегмент — поле, такова структура IDOC. Сам IDOC определяется типом сообщения (HRMD_A, транзакция WE81). Тип сообщения в зависимости от версии системы ссылается на тип IDOC (транзакция WE82).

Тип IDOC состоит из двух частей (транзакция WE30):

• Базовый тип. Базовый тип это то, что поставил САП в своем решении. Как правило базовый тип уже содержит все необходимые поля для передачи данных. Если же вам чего-то не хватает, то можно выбрать уже существующий сегмент из другого типа IDOC, либо создать расширение
• Расширение оно и в Африке расширение. САП же интернациональный. С помощью транзакции WE31 создаем новый сегмент, а в WE30 прописываем его как расширение к базовому типу. Останется прописать это расширение к типу сообщений HRMD_A в транзакции WE82

Рекламная пауза: создаем расширение IDOC:

Нужно не забыть наполнить этот сегмент данными. Это можно сделать с помощью user-exits или BAdI (смотрите в конце заметки). Нужно не забыть, что при нормальной передачи SAP — SAP данные в сегменте как записываются исходящей системой (один кусок кода), так и обрабатываются принимающей системой (второй кусок кода). Этот код нужно написать самим, а не дать угадывать системе. Для входящих айдоков нужно в транзакции WE57 указать, что IDOC был расширен на такой-то сегмент, поэтому его нужно обрабатывать тем же функциональным модулем (который в свою очередь расширен нижеукзанными user-exits или BAdI).

Допустим мы завершили наполнение IDOC данными. Умеем его наполнять, умеем распаковывать и создавать данные. Осталось самое простое — послать его куда подальше.

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

Партнер это отправитель или получатель (WE20). Порт — средство передачи IDOC (WE21). Модель распределения — маршрут, по которому система будет искать, как доставить сообщение от отправителя к получателю (BD64). Центр управления полетами — транзакция BD87.

Открываем WE21 для настройки портов. Здесь мы видим несколько вариантов, например, tRFC (отматываем повыше, чтобы вспомнить, о чем речь), File, XML HTTP, XML File, ABAP PI. По названиям несложно догадаться о форматах передачи данных. Для SAP-SAP мы выбираем tRFC и создаем новый порт. При создании система попросит RFC соединение — адрес, куда отправлять данные. Как вы помните, tRFC работает поверх CPI-C, а это значит, что для передачи данных по нестандартным протоколам можно подключить свою библиотеку, зарегистрировать ее как RFC program в SM59, а здесь указать это соединение. В итоге получится порт с отправкой данных через вашу стороннюю библиотеку. Здесь же можно указать, что данные нужно обрабатывать по схеме qRFC с помощью галочки Queue Processing is supported.

Теперь создадим партнеров. Партнер должен быть в исходящей системе для отправки данных и в принимающей для приема. В исходящей системе создаем в транзакции WE20 партнера с типом LS — логическая система. Отправка данных HR будет происходить от имени системы. Обратите внимание на то, что партнер — система приемник, а данные мы пишем в Исходящие. Мы как бы говорим системе, что вот этому партнеру нужно отправлять данные. А для принимающей системы будет наоборот, что вот от этого партнера нужно принимать данные. Чтобы обеспечить целостность в наименовании систем были придуманы так называемые логические системы, которые должны быть уникальны во всем ландшафте ИТ систем, которые интегрируются с САП. Это обязательное требование вендора.

Также создадим партнера в принимающей системе. Только теперь указываем Inbound параметр.

Осталось указать маршрут.
Открываем транзакцию BD64 в исходящей системе и создаем вот такую схему для отправки данных из системы ER1 манданта 100 в ER1 мандант 200.

Если после сохранения и попытки распределения (Edit — Model View — Distribute) система вас отругает, то пугаться не стоит. Распределение модели это тоже передача IDOC. Нужно создать партнера для этого.

Открываем транзакцию PFAL и пробуем отправить. Вроде все проходит без ошибок. Так как мы в настройке порта указали, что отправка идет через формирование очереди (то есть не сразу отправляется, а по расписанию), то смотрим в BD87 наш IDOC. Выбираем его и нажимаем кнопку Process для отправки. Все улетело.

А вот во входящей системе в BD87 нас ждет ошибка.

Все дело в том, что я в системе приемнике в данных партнера указал код обработки APLI Inbound IDoc: Individual Processing. А этот код применим для типовых IDOC, но не работает для HR. Для нас есть отдельный HRMD. Код обработки нужны для того, чтобы система могла понять, как обрабатывать входящий IDOC. На один и тот же тип IDOC может быть несколько разных кодов с разной логикой обработки. Например, одни сегменты обрабатывать в единичном случае так, а при пакетном вводе иначе. Меняем в партнере код обработки на HRMD и заново запускаем обработку IDOC уже в системе получателе. Заново отправлять данные не нужно!!!

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

Описание статусов IDOC можно посмотреть в таблице TEDS1.

В следующие разы мы поговорим о сериализации, фильтрации, конвертации IDOC. Что-то я уже рассказывал, поэтому обобщим и сведем воеидино.

Репост, лайки, шары, решары, донаты и печеньки очень приветствуются. Вам не сложно, а мне приятно 😉

P.S. Принимаются заявки на новые темы 😉

Полезные user-exits и BAdI

•EXIT_SAPLRHA0_001: HR-CA: ALE Outbound Processing With Receiver Enhancement
•EXIT_SAPLRHA0_002: HR-CA: Export Parameters for ALE Inbound Processing IDOC_INPUT_HRMD
•EXIT_SAPLRHA0_003: HR-CA: Import Parameters for ALE Inbound Processing IDOC_INPUT_HRMD
•EXIT_SAPLRHA0_004: HR-CA: ALE Outbound Processing: Control Record
•EXIT_SAPLRHA0_005: HR-CA: ALE Inbound Processing: Check Object
•EXIT_SAPLRHA0_006: HR-CA: ALE Outbound Processing: Check Object
•EXIT_SAPLRHAL_001: HR-CA: ALE Outbound Processing: Change IDoc
•EXIT_SAPLRHAL_002: HR-CA: ALE Inbound Processing: Change Infotype Data
•EXIT_SAPLRHAL_003: HR-CA: ALE Outbound Processing: Convert Infotype / Segment
•EXIT_SAPLRHAL_004: HR-CA: ALE Inbound Processing: Convert Segment / Infotype

BAdI: Inbound Processing for HR Master Data

HRALE00INBOUND_IDOC

Business Add-In in inbound processing for HR master data (used in the function module IDOC_INPUT_HRMD).

BAdI: Check/Additional Processing of Object in Inbound Proce

The CHECK_OBJECT method of this Business Add-In enables checks to be performed for an HR object in the RH_IDOC_OBJECTS_SAVE inbound function module. The method is accessed after customer exit SAPLRHA0_005.

BAdI: Customer-Defined Inbound Processing

HRALE00SPLIT_INBOUND

SAP-internal inbound processing for HR master data:

The system determines which HR objects should be removed from standard processing because no data structures exist for them in the receiving system. Irrespective of the type of receiving system, you can further process these HR objects.

BAdI: Fine Tuning of Original System Mechanism

HRALE00ORIGSYSTEM

Business Add-In for Original System Mechanism

BAdI: Outbound Processing HR Master Data

HRALE00OUTBOUND_IDOC

Business Add-In in output processing for HR Master Data (used in the function module RH_MASTER_IDOC_DISTRIBUTE_HRMD).