Миграция пользовательских объектов в S4/HANA Migration Cockpit
Дана методика создания объектов миграции в SAP S/4HANA Migration Cockpit на основе пользовательского функционального модуля. Приведены подробные шаги по разработке функционального модуля для добавления записей в z таблицу и показаноего использования для миграции данных.
Оглавление
Требования к функциональному модулю
Создание функционального модуля
Создать класс реализации бизнес логики
Построение функционального модуля
Создание объекта Migration Cockpit
Аннотация
Дана методика создания объектов миграции в SAP S/4HANA Migration Cockpit на основе пользовательского функционального модуля. Приведены подробные шаги по разработке функционального модуля для добавления записей в z таблицу и показаноего использования для миграции данных.
Целевая аудитория
Архитекторы бизнес-процессов, консультанты по миграции данных, ABAP разработчики, участвующие во внедрении SAP S/4HANA.
Общие положения
Migration Cockpit – новый инструмент для миграции данных в систему S/4HANA, пришедший на смену Legacy System Migration Workbench LSMW. Поставляется вместе с системой S/4HANA, содержит порядка 100 предварительно настроенных объектов миграции готовых к использованию без какого-либо программирования. Составной частью Migration Cockpit является Разработчик объектов миграции, транзакция LTMOM. С его помощью можно адаптировать стандартные объекты для требований проекта или создать новый объект для миграции сущностей, отсутствующих в стандартной поставке. Если требуется мигрировать данные в Z объекты необходимо разработать соответствующий функциональный модуль, отвечающий требованиям Migration Cockpit. Приведенный ниже пример загрузки данных в пользовательскую таблицу исторических данных ценовых условий реализован в системе SAP S/4HANA 1909.
Требования к функциональному модулю
Нота 2590165 - SAP S/4HANA Migration Cockpit - Creating Your own Function Modules содержит основные рекомендации по созданию программы для объекта миграции и может служить хорошим стартом для построения решения. Соблюдены основные требования к функциональному модулю для использования в качестве API:
- Не допускается вызов COMMIT WROK внутри кода модуля. Управление COMMIT выполнит Migration Cockpit
- Сообщения об ошибках, предупреждения сообщения должны возвращаться через структуру ABAP словаря BAPIRET2
- Модуль должен иметь входной параметр «Тестовый прогон» для симуляции миграции без записи в базу данных.
Параметры объекта миграции
В качестве примера рассмотрим загрузку данных в пользовательскую таблицу ZSD_HISTCOND «История цен», поля которой приведены в Таблице 1.
Таблица 1 Поля таблицы БД ZSD_HISTCOND
Создание функционального модуля
Архитектура модуля предусматривает определение интерфейсов ввода и вывода, соответствующих требованиям Migration Cockpit. Бизнес логика, валидация входных данных, сбор предупреждений и сообщений об ошибках реализованы в классе.
Создать тип данных
В транзакции SE11 выбрать опцию Тип Данных. Ввести наименование ZSD_HISTCOND_TT. Создать Тип Таблицы. Тип строки ZSD_HISTCOND - целевая таблица БД. Результат приведен на Рис. 1.
Рис. 1 Создание Типа таблицы ZSD_HISTCOND_TT
Создать класс реализации бизнес логики
В транзакции SE80 Навигатор по объектам создать класс как показано на Рис. 2
Рис. 2 Создание класса
Определить методы класса по данным из Таблицы 2.
Таблица 2 Методы класса ZCL_SD_HISTZPR_GEN
Настроить параметры методов по данным из Таблицы 3 и текстовые элементы по Таблице 4.
Таблица 3 Параметры методов класса ZCL_SD_HISTZPR_GEN
Таблица 4 Текстовые элементы класса
Скопировать и вставить код, приведенный в Листинге 1. Сохранить введенный код и активировать.
METHOD create.
DATA: ls_hist TYPE zsd_histcond,
lt_hist TYPE TABLE OF zsd_histcond,
ls_messages TYPE bapiret2.
LOOP AT it_zsdhistcond ASSIGNING FIELD-SYMBOL(<ls_zsdhistcond>).
IF <ls_zsdhistcond>-matnr IS INITIAL OR
<ls_zsdhistcond>-datbi IS INITIAL OR
<ls_zsdhistcond>-datab IS INITIAL.
set_return_message(
EXPORTING
iv_type = 'E'
iv_id = 'SD024'
iv_number = 000
iv_message_v1 = TEXT-001
iv_message_v2 = space
iv_message_v3 = space
iv_message_v4 = space
IMPORTING
et_messages = et_messages ).
RETURN.
ENDIF.
ls_hist-matnr = <ls_zsdhistcond>-matnr.
ls_hist-datbi = <ls_zsdhistcond>-datbi.
ls_hist-datab = <ls_zsdhistcond>-datab.
ls_hist-kbetr = <ls_zsdhistcond>-kbetr.
APPEND ls_hist TO lt_hist.
ENDLOOP.
MODIFY zsd_histcond FROM TABLE lt_hist.
set_return_message(
EXPORTING
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения 5
Комментарий от
Дмитрий Тарасов
| 17 мая 2020, 12:22
Интересно было бы посмотреть, что если есть зависимости между несколькими таблицами, и нужно сохранить консистенцию данных при миграции.
Также интересно сравнить данный метод с прямой миграцией, которая доступна с версии 1909.
Комментарий от
Олег Точенюк
| 18 мая 2020, 09:13
Дмитрий Тарасов 17 мая 2020, 12:22
Хорошая, качественная статья. Я бы смог применить эти шаги на практике.
Интересно было бы посмотреть, что если есть зависимости между несколькими таблицами, и нужно сохранить консистенцию данных при миграции.
Также интересно сравнить данный метод с прямой миграцией, которая доступна с версии 1909.
Комментарий от
Даньшин Алексей
| 18 мая 2020, 12:46
Олег Точенюк 18 мая 2020, 09:13
Не скажу как в 1909, но в 1709 пришлось устать с этим кокпитом, сырой зараза и скорость работы, короче не реально с этой штукой что-то серьезное мигрировать. 5000 объектов за сеанс?! Ребята вы серьезно систему рассчитали на ЧП палатка номер 5 с базара? Да еще и 12 часов эти 5000 ОС грузятся?! Короче надеялся что к 1909 исправили, но реализация прямой миграции, говорит что похоже как обычно, у сапа новая игрушка, и этот кокпит так и будет сырым по жизни. Хотя к какой-то 2510 наверное до ума доведут.
Комментарий от
Даньшин Алексей
| 18 мая 2020, 12:54
Дмитрий Тарасов 17 мая 2020, 12:22
Хорошая, качественная статья. Я бы смог применить эти шаги на практике.
Интересно было бы посмотреть, что если есть зависимости между несколькими таблицами, и нужно сохранить консистенцию данных при миграции.
Также интересно сравнить данный метод с прямой миграцией, которая доступна с версии 1909.
Комментарий от
Олег Точенюк
| 29 мая 2020, 07:34
Даньшин Алексей 18 мая 2020, 12:46
Есть опыт создания примерно 250 000 материалов через Staging Tables. Система 1809. В стандартном объекте отключили маппинг значений кодов материалов. В остальном по скорости примерно так же как с LSMW. В плоскую таблицу по методу из статьи мигрировано около 200 000 записей. Из неудобств можно отметить необходимость разбить пакет на 4 файла. В целом примерно то же, что и в старом инструменте. Из достоинств - прямо из коробки 100 готовых объектов, которые реально работают. Если потратить пару недель на изучение и потренироваться, то вполне себе удобный инструмент.