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

«Цикл первый. «Це­ле­со­о­бра­зно­е» внедрение ERP системы. Статья первая. «Новый подход»»
Александр Дублин:
1. Увы, Вы поняли нас неправильно. ТОС - это не "развитие тем", а теория (методология), которая даёт инструменты для анализа ситуаций (проблем бизнеса), в том числе таких: -  Почему...
«Замкнутый цикл про­и­зво­дства пустых фантиков»
Сергей Сверчков:
Пункты 0 и 1. в самую точку. П 1. на мой взгляд, является корневой причиной проблематики.  По пункту 1 хотел бы добавить:   1. Консультант должен понимать бизнес область, в...
«Чтобы снова, не вышло хреново!»
Олег Лактюшин:
Все верно, в России и странах СНГ 90% проектов это внедрение ради внедрения. Бизнес и руководство не понимают ни для чего это все делается, ни как проводить оценку внедрению и понять какой эффект...

База знаний

Миграция пользовательских объектов в S4/HANA Migration Cockpit

396
4

Оглавление

Аннотация

Целевая аудитория

Общие положения

Требования к функциональному модулю

Параметры объекта миграции

Создание функционального модуля

Создать тип данных

Создать класс реализации бизнес логики

Построение функционального модуля

Создание объекта 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

Ограниченный доступ

Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.

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

Дмитрий Тарасов (Рейтинг: 307) 12:22, 17 мая 2020

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

Олег Точенюк (Рейтинг: 11024)

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

Даньшин Алексей (Рейтинг: 391)

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

Даньшин Алексей (Рейтинг: 391)

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

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»