Sap ale что это
Записки о модуле Human Resources системы SAP® ERP. ALE
SAP HCM. Вид сбоку
Поцелуев Виталий Игоревич
Для настройки и понимания ALE нужно запомнить два ключевых понятия:
ALE – Application Link Enabling – технология передачи данных;
IDOC – Intermediate Document – объект, который передается по ALE.
Что такое ALE и для чего оно нужно?
Для настройки и понимания ALE нужно запомнить два ключевых понятия:
Что такое ALE и для чего оно нужно? Механизм ALE в продуктах SAP используется для передачи данных между системами. Причем данные могут передаваться как между SAP-системами, так и между внешними системами. Для этого компания представила универсальный формат документа, которым обмениваются системы между собой. В документе есть служебная информация (от кого, кому) и сами данные. ALE в быту используют для передачи МВЗ, данных по персоналу, проводок, кредиторов и дебиторов, планов проектов и многих других объектов. Механизм позволяет реализовывать удаленные вызовы функциональных модулей с помощью технологии RFC. Например, проверка кредитора из HR при проводке осуществляется удаленно в FI-системе. Поэтому в HR можно не хранить кредиторов. А HR-данные, которые необходимы для того же FI для печати кассовых ордеров, пойдут через модель распределения в виде документа, который называется IDOC.
Все очень упрощенно. Есть бумажка (IDOC), ее нужно передать. На бумажке пишут письмо с информацией (заголовок, содержимое), указывают куда отправить. Почтальон копирует письмо (если несколько получателей) и отправляет. Отправители и получатели – это партнеры в терминах системы. Письмо – IDOC. IDOC во всех системах имеет одинаковую структуру. Она очень большая и избыточная, но отправитель записывает только те поля, которые у него есть (или он считает, что только они нужны). Система-отправитель с помощью фильтров отсеивает лишнюю информацию, а остальное отправляет на почту.
Почтальон – это модель распределения (тр. BD64), которая знает, куда отправить информацию. В модели распределения структура простая: отправитель – получатель. Может быть несколько отправителей, несколько получателей. Модель получается таковой, что отправитель всегда знает, кто есть получатель. Я точно знаю, кто он – получатель (партнер, логическая система). То есть я могу отправить Ване, а Ваня может переслать Феде. Или я могу сразу отправить Феде. Как хочу, как разрешает схема сети.
Рис. 14.1
Для HR основной бумажкой (IDOC) является формат HRMD_A. Для каждой версии системы идет свой базовый тип, на основании которого строится этот самый HRMD_A. Это можно посмотреть в транзакции WE82. Найдите тип сообщения HRMD_A. Структуру IDOC можно посмотреть в транзакции WE30. Выбираете там тип документа для своей системы (у меня это HRMD_A07). Внутри будет структура сегментов, которая, если приглядеться, повторяет номера инфотипов. Это и есть та самая избыточность. При отправке данных заполняются только нужные сегменты (инфотипы). Остальное просто не включается в IDOC. Поэтому данные оргменеджмента и кадров будут в одном IDOC, если их не отфильтровать.
Изучив структуру IDOC, нужно понять, как же его отправить. Для этого надо определить отправителей и получателей. Здесь следующая иерархия (SAP любит каждый шажок запихивать в иерархические последовательности, видимо для гибкости):
Рис. 14.2
Рис. 14.3
Осталось связать отправителей и получателей. Заходим в BD64. Это модели распределения. Создаем новую модель от отправителя к получателю. Нажимаем «Добавить вид сообщения» и заполняем поля. Вид сообщения – HRMD_A. Банально, но это почти все. Теперь нам следует сказать получателю, что мы ему хотим что-то отдавать. Для этого нажимаем в меню редактирования «Модель – Распределить».
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
Эффективная настройка SAP ALE
Мы уже много раз говорили про настройку ALE. Вроде бы, что там еще можно настраивать? Но все то, что мы с вами изучали ранее, это игра в песочек, для начинающих. Настоящие САПеры берут лопаты, миноискатели и идут в бой, повышать эффективность систем, сокращать ошибки. Сегодня в номере эффективная настройка SAP ALE. Эффективность заключается в тонких приемах, о которых большинство не знает, а они помогают существенно сократить количество ошибок при передаче данных.
Знаете две проблемы с транзакцией PFAL? Первая заключается в том, что PFAL не умеет отправлять уже уволенных физлиц, так как работает на логической базе PCH (есть нота с решением). Вторая, что при попытке отправить всю оргструктуру по пути анализа O-S-P бараны перемешаются с апельсинами и в принимающей системе будет каша. Для этого делают всякие изощрения вроде того, что нужно сначала переслать только объекты организационного менеджмента, затем соединения между ними, а потом уже табельные номера слать. Тогда система получатель корректно примет данные и создаст последовательно. При этом фоновые задания для отправки данных планируются в такой же последовательности, когда нам нужно ежедневно передавать изменения между системами. Сегодня мы научимся эффективно решать эти вопросы с помощью простых настроек SAP ALE.
Вы знаете, что структура IDOC с кодом HRMD_A включает в себя все интернациональные инфотипы для оргменеджмента, администрирования персоналом и рекрутинга. Там нет российских инфотипов, нет пользовательских. Это все можно включить в IDOC с помощью расширений, о которых я писал чуть ранее. Зачастую там много лишнего, что нам не нужно. Плюс у нас есть задача как-то научить систему различать штатку и кадры. Для этого вендор придумал механизм сокращения IDOC-ов. Идея банальна — все что нам не нужно в IDOC, мы можем выкинуть. Система создает своего рода сокращенное представление IDOC, наполняет только его и передает, соответственно, тоже только это сокращенное представление.
Как сократить HRMD_A
Мы разделим наш один IDOC на два. ZORG и ZPA соответственно для организационной структуры и данных администрирования персонала. В транзакции BD53 создаем поочередно два сокращенных IDOC с базовым типом HRMD_A. При создании мы указываем с помощью кнопочки Select, какие сегменты нам нужны. Рекомендуется включить системные сегменты и все те инфотипы, которые мы реально собираемся передавать. Давайте посмотрим на мой пример.
Сокращение HRMD_A IDOC ZPA
Сокращение IDOC ZORG
Дальше мы прописываем вместо HRMD_A новые два IDOC (транзакция BD64)
Модель распределения для сокращенных IDOC
Через меню перегенерируем парнтеров, чтобы прописать новый IDOC в исходящих/входящих параметрах. Не забудьте, что в целевую систему нужно перенести настройки по сокращенным IDOC. Для этого в транзакции BD63 можно создать транспортные запросы с настройками, а потом их перенести.
Не забываем подписываться, лайкать, репостить и всячески поддерживать отечественного производителя контента!
Теперь у нас в транзакции PFAL появятся два новых IDOC для отправки. Можно смело делать вариант для ZORG и для ZPA. Данные не будут пересекаться.
Оптимизируем работу с указателями изменений для эффективной интеграции
Далее у нас повляется интересная задачка. Мы разово передали структуру, табельные номера. Все хорошо. Пользователи начали колбасить данные, создаются указатели изменений, обрабатываются, все улетает. А в целевой системе получается каша. Как так? Когда мы создаем указатели изменений, а затем формируем IDOC из них, то система не учитывает что за чем должно идти. Все данные формируются в большие пакеты и отправляются по конвейру. Для того, чтобы нам гарантировать последовательность обработки данных в нужном нам порядке, существует механизм сериализации документов.
Посмотрим, с чем его волки едят.
В транзакции BD44 создаем группу сериализации. Это набор и последовательность IDOC, которые должны обрабатываться в одной последовательности. В нашем случае, это ZORG обрабатывается первый, а ZPA второй.
Создание группы сериализации IDOC
Половина настройки ALE готова 😉
Добавляем в модель распределения и партнеров специальный IDOC SERDAT с фильтром по нашей группе сериализации.
Модель распредления SAP ALE
В принимающей системе устанавливаем параметры обработки входящей группы сериализации в ракурсе TBD41.
Настройка обработки входящей группы сериализации для настройки SAP ALE
Попробуем проверить. В ракурсе V_TBDA2 указываем активацию указателей изменений для наших двух IDOC. Изменяем данные в OM и в PA. В табличке BDCP2 мы можем увидеть, что система создала указатели изменений для наших изменений.
Просмотр указателей изменений SAP ALE
Для создания IDOC с учетом сериализации нужно запустить программу RBDSER01 с указанием нашей группы. Система создала два IDOC: один с данными ZORG, второй с данными ZPA. При это указатели изменений помечены как обработанные.
Далее мы запускаем программу RBDSER02, которая отправит в систему получатель срочную депешу SERDAT со словами, что вот вам два IDOC, не вздумай без меня их открывать.
Отправка SERDAT IDOC
В то время, во входящей системе у нас в очереди будут висеть два наших IDOC. Нам осталось обработать их в правильной последовательности с помощью программы RBDSER04.
Входящая обработка группы сериализации IDOC
Как видите, все красиво ии по-полочкам обработалось. Никто никого не блокирует, все по уму.
В следующий раз я расскажу про настройку производительности IDOC, чтобы было вжух!
Не забываем подписываться, лайкать, репостить и всячески поддерживать отечественного производителя контента!
Подробно про 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 для функционального модуля определяет, можно ли запускать эту функцию удаленно или нет.
Допустим мы определили что вызывать: программу или функциональный модуль. Теперь нужно решить как ее вызывать: транзакционно, синхронно, асинхронно, в очереди.
Зачем я все это вам пишу? Чтобы 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:
Нужно не забыть наполнить этот сегмент данными. Это можно сделать с помощью 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
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
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
Business Add-In for Original System Mechanism
BAdI: Outbound Processing HR Master Data
Business Add-In in output processing for HR Master Data (used in the function module RH_MASTER_IDOC_DISTRIBUTE_HRMD).
SAP ALE инструкция по настройке
Скажу сразу — не люблю писать подробные инструкции. Они расслабляют мозг и формируют класс ленивых консультантов. Профи должен «взять нюх» и найти решение. Поэтому эта небольшая инструкция будет направляющей, а не разжевывающей. Постараюсь дать ссылки и так далее. Хочу сказать спасибо всем, кто откликнулся и помог с материалами или советами. Отдельное спасибо Юрию Сычеву за помощь. Писать я буду со своей колокольни, так как не считаю себя ALE специалистом. Комментарии и правки только приветствуются. Поехали.
Всегда изучение чего-то нового в SAP начинайте с SAP Library, затем IMG, а потом можно и форумы посмотреть (рекомендую SDN). Не первый раз обращаю внимание, что многие часы я тратил зря, когда нужно было внимательно прочитать вышеуказанные материалы. Курсы по сапу я давно уже не открывал, просто отпала необходимость.
Основные понятия в SAP ALE
Для настройки и понимания ALE нужно запомнить два ключевых понятия:
ALE — Application Link Enabling. Технология передачи данных.
IDOC — Intermediate Document. Объект, который передается по ALE.
Все очень упрощенно. Есть бумажка (IDOC), ее нужно передать. На бумажке пишут письмо с информацией (заголовок, содержимое), указывают куда отправить. Почтальон копирует письмо (если несколько получателей) и отправляет. Отправители и получатели это партнеры в терминах системы. Письмо — IDOC. IDOC во всех системах имеет одинаковую структуру. Она очень большая и избыточная, но отправитель записывает только те поля, которые у него есть (или он считает, что только они нужны). Система отправитель с помощью фильтров отсеивает лишнюю информацию, а остальное отправляет на почту.
Почтальон, это модель распределения (тр. BD64), который знает куда отправить информацию. В модели распределения структура простая: отправитель — получатель. Может быть несколько отправителей, несколько получателей. Модель получается таковой, что отправитель всегда знает кто есть получатель. Я точно знаю кто ты — получатель (партнер, логическая система). То есть, я могу отправить Ване, а Ваня может переслать Феде. Или я могу сразу отправить Феде. Как хочу, как разрешает топология сети.
Для HR основной бумажкой (IDOC) является формат HRMD_A. Для каждой версии системы идет свой базовый тип, на основании которого строится этот самый HRMD_A. Это можно посмотреть в транзакции WE82. Найдите тип сообщения HRMD_A. Структуру IDOC можно посмотреть в транзакции WE30. Выбираете там тип документа для своей системы (у меня это HRMD_A07). Внутри будет структура сегментов, которая, если приглядеться, повторяет номера инфотипов. Это и есть та самая избыточность. При отправке данных заполняются только нужные сегменты (инфотипы). Остальное просто не включается в IDOC. Поэтому данные оргменеджмента и кадров будут в одном IDOC, если их не отфильтровать.
Изучив структуру, IDOC нужно понять, как же его отправить. Для этого надо определить отправителей и получателей. Здесь следующая иерархия (САП любит каждый чих запихивать в иерархические последовательности):
RFC путь. Транзакция SM59 поможет создать логические соединения до систем (по сути адрес сервера и манданта, с которым надо будет соединиться).
WE21 порт. Создаем надстройку над RFC в виде дополнительного логического объекта — порт. Все что нужно, это указать RFC соединение. Порт выбираем Transactional RFC.
WE20 партнер (логическая система). По сути это и есть наш отправитель/получатель. Здесь важно отметить следующее. Это первый фильтр высокого уровня. При создании партнера нужно определить какие виды IDOC могут через него проходить. Во входящих и исходящих параметрах нужно добавить все виды IDOC согласно направлениям, какие вы планируете настроить. Например, для HR системы отправителя нужно указать в исходящих вид документа HRMD_A07 (наш базовый вид) и указать порт (куда отправлять). Все это делается для логической системы (тип LS).
Осталось связать отправителей и получателей. Заходим в BD64. Это модели распределения. Создаем новую модель от отправителя к получателю. Нажимаем добавить вид сообщения и заполняем поля. Вид сообщения — HRMD_A. Банально, но это почти все. Теперь нам нужно получателю сказать, что мы ему хотим что-то отдавать. Для этого нажимаем в меню редактирования — модель — распределить. И указываем в какую систему отправить эту настройку. Система передаст информацию в ту систему. Теперь модель распределения в обоих системах будет одинакова. Не забудьте в системе получателе настроить порты, логические системы.
Чтобы нам не отправлять все, вся и всем, есть понятие фильтров. Два раза щелкнув на строке с фильров (под видом сообщения в модели распределения), можно открыть окно фильтров. Здесь мы указываем какие именно сегменты можно отдавать в эту систему получатель. Для каждого вида документа (IDOC) будет свой набор фильтров. Посмотрите, там все просто.
SAP ALE особенности для модуля HR
С точки зрения HR фильтров есть маленькие хитрости. Юрий Сычев подсказывает, что можно указать OM соединения сверху вниз, чтобы система сама сгенерировала обратные (снизу вверх). Таким образом будет меньше ошибок при формировании оргструктуры, когда система получатель получит дочерний объект, а старшего пока нет (не доехал еще) и начнет ругаться, что не может создать соединение. Поэтому фильтры делаем так:
Отдельно данные OM (инфотипы 1000-1999), отдельно данные PA (0000-0999) + (2000-9999).
Отдельно передаем связи сверху вниз.
Все это можно разграничить фильтрами.
Если вам нужно отдать информацию по табельникам в другие системы, то минимальный минимум это 0000, 0001, 0002, 0003 инфотипы. Плюс 0009, 0290, если нужно в FI для формирования кассовых ордеров.
Запуск интеграции через SAP ALE
Вроде все настроили, осталось проверить и отдать первый кусок данных. Сначала отдаем штатку, потом людей. Отправка HR данных делается одной транзакцией: PFAL. Указываете корневую О-шку, путь анализа, систему получателя и отправить. Система сформирует пачку IDOC и поставит их в очередь для отправки в логические системы. Если в настройках порта вы поставили галочку отправлять немедленно, то обработка начнется сразу же.
За ходом обработки можно смотреть в наглядной форме в транзакции BD87. Система покажет сколько и чего отправлено, принято, какие статусы. Там же можно встать на группу IDOC и нажать кнопку Обработать. Это протолкнет обработку зависших документов. Документы могут зависнуть из-за того, что в системе кто-то что-то блокирует из основных данных.
В системе получатели также можно запустить BD87 и посмотреть, что приехало. Если появились ошибки, то разверните ошибочный узел и увидите причины. Там же можно перезапустить обработку. Если два раза щелкнуть на строку состояния документов, то провалитесь в транзакцию WE05, где можно посмотреть содержимое IDOC и статус обработки каждого сегмента высокого уровня. Это поможет быстро найти причину ошибок (не хватает объектов, заблокированные записи и так далее).
Для автоматизации передачи данных есть механизм указателей (Change Pointer). Суть проста — как только что-то изменили в инфотипе, то изменение упаковывается в IDOC и отправляется всем получателям по модели распределения. Активировать это можно в транзакции BD61. В ракурсе V_TBDA2 отмечаем виды IDOC, для которых нужно генерировать указатели изменений. Указатели изменений будут формироваться в табличке BDCP/BDCPV. Чтобы из них сварганить IDOC нужно запланировать программу RBDMIDOC. Старые указатели (тестовые, например), можно удалить транзакцией BD22.
Литература и подсказки по SAP ALE
Область меню в SAP:
BALM — распределение основных данных (отправить основные данные принудительно)
BALA — распределение данных для приложений (отправить какие-нить документы принудительно)