Меню

Миграция пользовательских объектов в 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

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

Не скажу как в 1909, но в 1709 пришлось устать с этим кокпитом, сырой зараза и скорость работы, короче не реально с этой штукой что-то серьезное мигрировать. 5000 объектов за сеанс?! Ребята вы серьезно систему рассчитали на ЧП палатка номер 5 с базара? Да еще и 12 часов эти 5000 ОС грузятся?! Короче надеялся что к 1909 исправили, но реализация прямой миграции, говорит что похоже как обычно, у сапа новая игрушка, и этот кокпит так и будет сырым по жизни. Хотя к какой-то 2510 наверное до ума доведут.

Комментарий от  

Даньшин Алексей

  |  18 мая 2020, 12:46

Не скажу как в 1909, но в 1709 пришлось устать с этим кокпитом, сырой зараза и скорость работы, короче не реально с этой штукой что-то серьезное мигрировать. 5000 объектов за сеанс?! Ребята вы серьезно систему рассчитали на ЧП палатка номер 5 с базара? Да еще и 12 часов эти 5000 ОС грузятся?! Короче надеялся что к 1909 исправили, но реализация прямой миграции, говорит что похоже как обычно, у сапа новая игрушка, и этот кокпит так и будет сырым по жизни. Хотя к какой-то 2510 наверное до ума доведут.

Есть опыт создания примерно 250 000 материалов через Staging Tables. Система 1809. В стандартном объекте отключили маппинг значений кодов материалов. В остальном по скорости примерно так же как с LSMW. В плоскую таблицу по методу из статьи мигрировано около 200 000 записей. Из неудобств можно отметить необходимость разбить пакет на 4 файла. В целом примерно то же, что и в старом инструменте. Из достоинств - прямо из коробки 100 готовых объектов, которые реально работают. Если потратить пару недель на изучение и потренироваться, то вполне себе удобный инструмент.

Комментарий от  

Даньшин Алексей

  |  18 мая 2020, 12:54

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

Учитывая, что не должно быть COMMIT WORK внутри кода ФМ и управление COMMIT выполнит Migration Cockpit логично предположить, что нет принципиальной разницы сколько таблиц изменяется в коде ФМ. Можно взять в качестве примера любой BAPI, используемый в стандартных объектах, и на его примере разобрать особенности обновления нескольких таблиц. Прямая миграция, на мой взгляд, отличается от миграции из файлов или из таблиц фактически только источником данных.

Комментарий от  

Олег Точенюк

  |  29 мая 2020, 07:34

Есть опыт создания примерно 250 000 материалов через Staging Tables. Система 1809. В стандартном объекте отключили маппинг значений кодов материалов. В остальном по скорости примерно так же как с LSMW. В плоскую таблицу по методу из статьи мигрировано около 200 000 записей. Из неудобств можно отметить необходимость разбить пакет на 4 файла. В целом примерно то же, что и в старом инструменте. Из достоинств - прямо из коробки 100 готовых объектов, которые реально работают. Если потратить пару недель на изучение и потренироваться, то вполне себе удобный инструмент.

Ну вот у меня из коробки в 1709, для ОС не вышло, кстати после переписки с SAP, таки пришлось руками это заливать, через бапи. Возможно в 1810 стало значительно лучше с этим. Ну сделаем миграцию на 1819, проверю.