Какой цели служит этап проверки файлов рабочей среды миграции в sap business bydesign

Обновлено: 09.01.2025

SAP Business ByDesign — on-demand бизнес-приложение, предназначенное для быстрорастущих компаний среднего сегмента рынка. Выпущено в сентябре 2007 года. В пакет решения SAP Business ByDesign входят сервисы и техническая поддержка. У решения есть демо-версия и основная версия программы.

Решение SAP Business ByDesign дополняет уже существующие решения SAP Business One, SAP Business All-in-One и SAP Business Suite.

Business ByDesign 2.5

В августе 2010 года выпущена версия системы Business ByDesign 2.5. Продукт предлагает полностью обновленный аналитический механизм, поддерживает новые мобильные устройства и расширенный механизм управления жизненным циклом приложений. Продукт разработан для компаний малого и среднего бизнеса, не обладающих значительными ресурсами для полномасштабного внедрения ERP-системы на собственных мощностях.

Стартовый пакет включает в себя финансовый модуль, модуль учета и бизнес аналитику. Среди основных возможностей Business ByDesign – двусторонняя интеграция с Microsoft Excel, поддержка новых мобильных устройств, поддержка в интерфейсе технологии Microsoft Silverlight, новые коннекторы для MS Office. Помимо этого, в новой версии появились новые варианты технической поддержки со стороны SAP.

SAP Business ByDesign 2.6

В поставку новой версии SaaS-пакета Business ByDesign компании SAP входит давно ожидавшийся набор средств разработчика. С его помощью можно создавать различные дополнения и расширения базовой системы. В компании рассчитывают, что наличие SDK стимулирует развитие партнерской экосистемы. Такого же мнения придерживаются и обозреватели, хотя некоторые из них указывают, что наличие качественных инструментов разработки является необходимым, но еще не достаточным условием роста экосистемы. К счастью для SAP, предварительные отзывы партнеров говорят о том, что с новыми средствами работать значительно проще, чем с NetWeaver — основной платформой разработки SAP. Впрочем, знание технологий SAP все равно необходимо.

Новая версия Business ByDesign ориентирована, в отличие от предыдущей, на использование в дочерних предприятиях крупных компаний. Вначале в SAP рассчитывали, что ByDesign будут массово пользоваться предприятия малого и среднего бизнеса, однако к настоящему времени пакет приобрело лишь около 250 клиентов. К концу 2011 года в SAP надеются довести эту цифру до 1000.

Feature Pack 2.0

По заявлению разработчика, Feature Pack 2.0 для SAP Business ByDesign расширяет функционал ERP-системы и обеспечивает большую ценность для клиентов, предлагая бизнес-поддержку 35 сквозных сценариев.

Новый функционал, по заявлению разработчика, совершенствует процесс принятия решений благодаря интеграции с такими системами как Crystal Reports и панелью Xcelsius, за счет чего руководители компаний СМБ могут воспользоваться расширенными аналитическими функциями (BI). Панели содержат ключевые показатели деятельности, в том числе объем наличности, управление ликвидностью, прогноз продаж. Кроме того, с помощью настраиваемых ключевых показателей руководители могут контролировать ход основных бизнес-процессов.

Feature Pack 2.0 включает также функционал по управлению взаимоотношениями с клиентами (CRM), автоматизации биллинга, управлению ресурсами и рентабельностью проекта, управлению закупками, обслуживанием и ремонтами.

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

Расширенные возможности ERP-системы облегчают возможности взаимодействия компании со своими клиентами, поставщиками и партнерами благодаря интеграции с Microsoft Outlook и Microsoft Office. Как сообщается, компаниисмогут добиться повышения производительности за счет использования функций персонализации, а также ряда сторонних веб-сервисов, которые сейчас доступны в Feature Pack 2.0.

История

В мае 2008 года SAP объявила об изменениях в планах по продвижению своей новой системы Business ByDesign, которая должна стать ключевым элементом стратегии «завоевания» сегмента среднего и малого бизнеса.

Система была выпущена в сентябре 2007 года, и с тех пор была опробована рядом партнеров и клиентов компании, пожелавших участвовать в раннем тестировании решения. Разработчик постарался учесть высказанные ему замечания и пожелания, и в результате в компании пришли к выводу о необходимости немного отложить процесс полномасштабного вывода системы на рынок.

Так, по уточненным планам компании, в 2008 году система будет доступна лишь в шести странах, участвовавших в ее бета-тестировании. В остальные страны система должна прийти в 2009 году. И если ранее компания планировала выйти на «рубеж» в 10 000 клиентов Business ByDesign и 1 млрд. долларов доходов от системы уже в 2010 году, то теперь эта цель отложена примерно на 12-18 месяцев. Однако, как сообщается, компания намерена использовать инновации и технологии Business ByDesign для развития существующих решений.

Также SAP признала, что в 2008 году клиентская база нового приложения составит значительно меньше запланированной изначально 1 000 компаний. В связи с этим, инвестиции в развитие Business ByDesign в 2008 году сократятся до 100 млн. евро, а в 2009 году дополнительных инвестиций в развитие нового продукта не будет, а затраты на его разработку будут выделяться в рамках общего бюджета SAP. Однако в SAP по-прежнему сохраняют уверенность в успехе своего нового продукта и избранной бизнес-модели.

В июле 2009 г. SAP объявила о выпуске модификации ERP-системы "по требованию" для СМБ – Feature Pack 2.0 для SAP Business ByDesign. Продукт был широко анонсирован в 2007 году, однако, в связи с задержкой широкого распространения системы, в это время компания имела только 80 клиентов в шести странах, где была доступна данная ERP-система. Решение было доступно в Китае, Франции, Германии, Индии, Великобритании, США.

По словам Райнера Зиноу (Rainer Zinow), вице-президента по инновациям SAP Business ByDesign, все проблемы, связанные с выпуском данной ERP, должны быть решены к 2010, когда решение будет готово для всех клиентов, которые хотят купить его. Лео Апотекер (Leo Apotheker), co-CEO SAP, заявил, что в 2009 году клиентская программа для Business ByDesign будет ускорена.

Осенью 2013 года SAP объявила о свертывании дальнейшей работы над облачным решением ByDesign. И хотя немецкая компания уверила, что продолжит поддерживать и активно продвигать решение в полном объеме, все-таки это означает, что никаких значимых обновлений решения в будущем не предвидится.

По словам представителя SAP Вишала Сикка (Vishal Sikka), критические обновления Business ByDesign все-таки продолжат выпускаться, а команда продукта останется работать для оказания технической поддержке пользователям текущей версии. На октябрь 2013 года число клиентов ByDesign составляло 1,1 тыс. При запуске решения SAP намеревалась подключить 10 тыс. клиентов уже к 2010 году.

Миграция данных является одним из ключевых и самых сложных аспектов внедрения SAP: непродуманная стратегия может поставить под угрозу весь проект. Несмотря на то, что миграция данных является частью плана по внедрению (Cutover Plan), её важность очень часто недооценивают и весь процесс рассматривается как простая административная задача по переносу данных из одного места хранения в другое. Команда сосредотачивается на дизайне и демонстрации системы (Workshop), а также конфигурации, оставляя планирование миграции на потом. В результате на активности по миграции закладывается недостаточно времени и ресурсов, что может привести к срывам сроков при запуске. Грамотно спланированные миграционные активности помогут избежать «кранча» в период подготовки, а также снизят риски после запуска проекта.

Типовой процесс миграции данных

Если целью внедрения SAP ERP является замена старой (Legacy) системы, то миграция позволит перенести релевантные бизнес-данные из Legacy в соответствующие SAP-модули. Процесс миграции включает в себя следующие этапы [1]:

экстракция данных из Legacy системы;
валидация полученных данных;
трансформация данных в формат, подходящий к загрузке в SAP;
валидация трансформированных данных;
загрузка данных в SAP;
проверка загруженных данных.

Первым шагом миграции данных является идентификация объектов, которые необходимо перенести в новую систему, а также их владельцев. Объектами можно назвать, например, Бизнес-Партнеров, Контракты, Запасы и т.д. Далее должны быть определены ETL-инструменты (Extraction, Transform, Load или выгрузка, трансформация и загрузка). Способы экстракции и трансформации данных зависят от источника, однако обычно для загрузки используются решения, разработанные на базе LSMW (Direct Input, BAPI, IDoc и Batch Input). Далее решаются следующие задачи (рис. 1):

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

Стратегия миграции данных

В зависимости от стратегии, выбранной в начале проекта, миграция данных может включать в себя как несколько тестовых циклов, так и всего один. В свою очередь фаза Go-Live (продуктивный запуск) может также проводиться как в сжатые сроки (Big-Bang), так и итеративно. Выбор подхода определяется такими факторами как объем данных, продолжительность загрузки, допустимое время простоя системы и др.

Во время проведения тестового цикла миграции важно помнить о том, что не приближенный к реальному объему набор основных и транзакционных данных приведёт к искаженным результатам, что в свою очередь может повлечь неправильное распределение времени как на активности продуктивной миграции, так и заморозки систем. Это же касается и перечня объектов миграции в целом. В проведение тестовых циклов миграции должны быть вовлечены все участники для того, чтобы убедиться в достаточной компетентности и понимании назначенных ролей сотрудникам. Не готовые на 100% правила трансформации не должна быть причиной для полного отказа от тестирования миграции, так как в процессе трансформации и очистки даже части данных объектов могут быть выявлены новые требования, зафиксированы новые ошибки и обозначены новые критерии успешно проведённой загрузки (рис. 2).

Одним из распространенных подходов к миграции является привязка тестовых циклов к видам тестирования (функциональное, интеграционное, приемочное). Также в подготовке к продуктивной миграции может помочь так называемая репетиция запуска (Dry Rehearsal), когда к процессам сбора информации, трансформации, загрузки и валидации, будут привлекаться все запланированные участники, а не сокращенный состав команды [2].

Функционально-матричная организационная структура команды миграции

Продолжая тему тесного сотрудничества в процессе подготовки к миграции, нельзя не упомянуть функционально-матричный подход к организации команды миграции (рис. 3). Преимуществами данной структуры являются быстрый обмен информацией между сотрудниками, вовлеченность всей проектной команды в миграционные активности, а также сниженный риск того, что отдельные объекты/правила трансформации/инструменты будут недостаточно проработаны. Недостатками данной организации команды может стать сложность балансирования нагрузки сотрудников, а также трудности во взаимодействии с представителями клиента. Такой подход будет хорошо работать в случае, если командой управляют опытные менеджеры, а на стороне клиента имеет место хорошо проработанное вертикальное взаимодействие, при котором заинтересованное руководство может повлиять на непосредственных исполнителей задач.

Рис. 3. Виды организационных структур: функциональная; матричная; гибридная Рис. 3. Виды организационных структур: функциональная; матричная; гибридная

Несмотря на разные подходы и индивидуальную специфику каждого из проектов по миграции данных, золотыми правилами всегда будут:

четкое определение масштабов проекта;
понимание текущих бизнес-задач и технических проблем;
оперативная оценка существующего уровня качества данных, выявление пробелов;
привлечение соответствующих заинтересованных сторон с самого начала проекта.

Планирование миграции данных

Планируя активности по миграции данных, необходимо помнить не только о технических аспектах процесса, таких как:

экстракция, загрузка и контроль данных;
техническая валидация;
очистка массивов данных;
трансформация и проверка на соответствие правилам ведения,

но и о следующих функциях, которые должны быть закреплены за сотрудниками или командами:

корректная и своевременная идентификация владельцев бизнес-данных;
сопровождение очищенных массивов информации и координация валидации в случаях, когда объект миграции кросс-функционален и будет использоваться разными бизнес-направлениями;
непрерывное взаимодействие с экспертами со стороны клиента, которое позволит сформулировать четкие правила трансформации, а также избежать пропуск объектов миграции.

Тесное сотрудничество с клиентом и управление его ожиданиями является частью фундамента, на котором строится успешный проект по миграции данных. Уже на ранних стадиях проекта руководители направления должны убедиться в том, что бизнес понимает свою роль в проекте миграции, заданы критерии оценивания успешной миграции данных и разработаны схемы работы на период заморозки систем (Freeze Period).

Недостаточная вовлечённость ответственных сотрудников напрямую влияет на качество полученных в результате трансформации данных. У данной проблемы может быть несколько причин, например:

некорректно определённы владельцы данных;
общая перегруженность ответственных другими проектными задачами;
плохая информированность сотрудников о разработанном подходе к миграции,

возможными решениями в таких ситуациях могут быть:

проведение дополнительных сессий, в рамках которых будут выявлены как лица, несущие ответственность за чистоту данных, так и сотрудники, непосредственно использующие эти данные и обладающие достаточной экспертизой для обеспечения поддержки процессов миграции;
приоритизация распределяемых задач и привлечение дополнительной рабочей силы;
разработка мотивационной системы для вовлечённых в проект сотрудников, а также обеспечение и сопровождение канала связи между ответственными и исполнителями.

Выводы

Миграция данных по праву считается одной из самых критичных задач в проекте внедрения корпоративной информационной системы: как бы качественно не было разработано и протестировано приложение его работа невозможна без своевременно подготовленной и загруженной бизнес-информации. Вне зависимости от выбранной стратегии миграции, а также организационной структуры команды по миграции выгрузка, трансформация, перенос и валидация данных являются критической составляющей общего Cutover-плана по переходу к использованию внедряемого SAP-решения.

Или можно? Конечно, миграция SAP-систем — это сложный и кропотливый процесс, для успеха которого важна слаженная работа всех участников. А если миграция проводится в сжатые сроки — задача многократно усложняется. Не все решаются на это. Причин может быть несколько. Например, процесс сам по себе длителен и организационно сложен. Плюс есть риск незапланированных простоев систем. Или клиенты не уверены, что, пережив такую операцию, получат бенефиты, соразмерные потраченным усилиям. Однако бывают и исключения.

Под катом расскажем о трудностях, с которыми сталкиваются заказчики в процессе миграции и сопровождения SAP-систем, обсудим, почему стереотипы не всегда соответствуют реальности, и поделимся кейсом, как нам удалось мигрировать системы заказчика в новую инфраструктуру всего за три с небольшим месяца.

Хостинг SAP-систем

Еще каких-то пять лет назад сложно было представить, что клиенты массово начнут использовать хостинговые ресурсы для SAP-приложений. В большинстве случаев их внедряли on-premise. Однако с развитием моделей аутсорсинга и рынка облачных услуг мировоззрение заказчиков начало меняться. Каковы аргументы, влияющие на выбор в пользу облака для SAP?

Для новичков, которые только запланировали внедрение SAP, облачная инфраструктура это практически стандартный выбор – масштабируемость ресурсов под текущую потребность системы и нежелание отвлекать ресурсы на развитие непрофильных компетенций.
В компаниях с большим системным ландшафтом с помощью хостинга SAP-систем CIO выходят на качественно иной уровень управления рисками, т.к. за SLA отвечает партнер.
Третий из наиболее часто встречаемых аргументов – высокая стоимость построения инфраструктуры для реализации сценариев высокой доступности и DR.
Фактор 2027 – анонсированное вендором прекращение поддержки устаревших систем в 2027 году. Это означает перевод БД на HANA, что влечет за собой расходы на модернизацию и закупку новых вычислительных мощностей.

В чем заключаются сложности смены SAP-хостинга?

Хостинги бывают разные. Несоответствие заявленному уровню сервиса, множество «но» и звездочек с оговорками мелким текстом, ограниченность ресурсов и возможностей хостинг-провайдера, отсутствие гибкости в вопросах коммуникации с клиентом, бюрократия, технические ограничения, низкая компетентность специалистов технической поддержки, а также многие другие нюансы — это лишь малая часть подводных камней, с которыми могут столкнуться клиенты в процессе эксплуатации их бизнес-систем в аутсорсинговых инфраструктурах. Зачастую для клиента все это остается в тени, в дебрях многостраничного контракта, и всплывает уже в процессе пользования услугами.

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

Почему тянут до последнего? Причина проста — процесс переноса систем для клиентов не всегда прозрачен и понятен. Клиенту сложно оценить действительные риски, связанные с процессом миграции. Можно сказать, что миграция для клиентов — это своеобразный черный ящик: непонятно, цена, время простоя систем, риски и как их нивелировать, да и вообще темно и страшно. Тут ведь как, если не получится, то головы полетят и у топов, и у исполнителей.

SAP — это системы корпоративного уровня, сложные и мягко говоря не дешевые. На их внедрение, доработку, сопровождение тратятся приличные бюджеты и от их доступности и корректной работы зависит жизнедеятельность предприятия. А теперь представьте последствия остановки какого-нибудь крупного производства. Это финансовые потери, которые могут исчисляться цифрами с большим количеством нулей, а также репутационные и другие, не менее значимые риски.

Разберем сложности, которые могут возникнуть на каждом из этапов на кейсе миграции SAP-систем одного из наших заказчиков.

Подготовка и проектирование

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

Нам необходимо было погрузиться в существующую реализацию систем, их архитектуру. В целевой инфраструктуре мы где-то повторили существующие решения, в каких-то моментах дополнили и улучшили, где-то переделали, продумали и выбрали решения по обеспечению отказоустойчивости и доступности, а также максимально консолидировали все ресурсы.

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

Что у нас в результате получилось — индивидуально спроектированная инфраструктура частного облака на базе нашего ЦОД:

выделенные физические серверы для SAP HANA;
платформа виртуализации VMware для серверов приложений и инфраструктурных сервисов;
дублированные каналы связи между ЦОД для L2 VPN;
две основных СХД для разделения продуктива и «всего остального»;
СРК на базе Veritas Netbackup с отдельным сервером, дисковой полкой и ленточной библиотекой.

А вот как реализовали все это с технической точки зрения.

Для эффективного использования хранилищ под продуктивные HANA использовали общие диски без системной репликации БД средствами SAP. Все это завернули в Active-Standby кластер SUSE HAE на базе Pacemaker. Да, время восстановления немного дольше, чем с репликацией, зато получаем экономию пространства СХД в два раза и как следствие экономию бюджета заказчика.
В препродуктивных средах от кластеров HANA отказались, но технически повторили конфигурацию продуктива.
Тестовые среды и среды разработки разнесли еще на несколько серверов без кластеров в конфигурации MCOS.
Все серверы приложений виртуализировали и разместили в VMware.

Физически разделили контуры сетей управления и продуктивных сетей стеками коммутаторов, завернув продуктивные в сторону ЦОД заказчика.
Заложили достаточное количество сетевых интерфейсов, чтобы не смешивать большие потоки трафика.
Для передачи данных с СХД сделали классические FC SAN фабрики.

Продуктивную и препродуктивную нагрузку SAP оставили на all-flash массиве.
Тестовые среды разработчиков и инфраструктурные сервисы поместили на отдельный гибридный массив.

Сделали на базе Veritas Netbackup.
Немного дописали встроенные скрипты, чтобы бекапить MCOS-конфигурации.
Оперативные копии положили на дисковую полку, чтобы быстро восстановиться, а для долгосрочного хранения используем ленты.

Мониторинг

Все железо, ОС и SAP завели под Zabbix.
Собрали множество полезных дашбордов в Grafana.
При возникновении алерта Zabbix умеет заводить заявку в системе управления инцидентами, у нас она реализована на Jira. Также информация дублируется в Telegram-канал.

Общее состояние HANA

Состояние сервера приложений SAP:

Инфраструктурные сервисы

Для обслуживания внутренних пространств имен подняли кластер DNS-серверов, который синхронизируется с серверами заказчика.
Сделали отдельный файловый сервер для обмена данными.
Чтобы хранить различные конфигурации, добавили Gitlab.
Для различной Sensitive-информации взяли HashiCorp Vault.

Процесс миграции

В общем случае процесс миграции состоит из следующих этапов:

подготовка всей необходимой проектной документации;
переговоры с текущим провайдером — решение организационных вопросов;
закупка, доставка и установка нового оборудования под проект;
тестовая миграция и отладка процесса;
перенос систем, боевая миграция.

На что нужно обратить внимание в первую очередь — сроки поставки оборудования. В среднем поставка сертифицированного железа под SAP NAHA, соответствующего требованиям производителя ПО к аппаратным платформам, занимает 10-12 недель. А с учетом сезонности (реализация проекта выпадала аккурат на новый год) — этот срок мог увеличиться еще на месяц. Соответственно, требовалось максимально ускорить процесс: работали с дистрибьютором-поставщиком, договаривались об ускоренной доставке самолетами (вместо сухопутных и морских путей).

Ноябрь и декабрь ушли на то, чтобы выполнить подготовку к миграции и получить часть оборудования. Подготовку мы провели на тестовом стенде в нашем публичном облаке, где отработали все основные шаги и отловили возможные сложности и проблемы:

подготовили детальный план взаимодействия участников проектных команд с поминутными таймингами;
построили тестовый стенд для БД и серверов приложений примерно так же, как в целевой инфраструктуре;
настроили необходимые каналы связи и инфраструктурные сервисы, чтобы проверить работу интеграций;
отработали cutover-сценарии;
облако также помогло нам сформировать преднастроенные шаблоны виртуальных машин, которые впоследствии мы просто импортировали и развернули в целевом ландшафте.

Общий порядок миграции выглядел так: в первую очередь — наименее критичные системы (ландшафт разработки, ландшафт тестирования), затем — продуктивные системы. Финальный этап миграции проходил в конце января-начале февраля.

Процесс миграции был расписан с точностью до минуты. Это cutover-план со списком всех задач, временем выполнения и ответственными лицами. Все шаги уже были отработаны на тестовой миграции, поэтому в боевой миграции необходимо было просто следовать плану и координировать процесс.

Миграция проводилась посистемно в несколько этапов. В каждом этапе по две системы.

Итогом трехмесячного спринта стала система, полностью функционирующая в ЦОД КРОК. В целом, положительный результат получен благодаря совместной работе, вклад и самоотдача всех участников процесса была максимальной.

Роль заказчика в проекте

Коммуницировать с провайдером, которого покидал наш клиент, было непросто. Оно и понятно, они были последние в списке лиц заинтересованных в успешном завершении проекта. Заказчик взял на себя задачи по эскалации и педалированию всех коммуникационных вопросов и справился с этим на 100500%. За это ему отдельное спасибо. Без такого посильного участия в процессе результат проекта мог бы быть совсем иным.

В силу формализованности процессов на стороне «бывшего» провайдера сопровождением инфраструктуры занимались специалисты, в прямом смысле далекие от проблем, на тот момент еще их заказчика. Например, процесс экспорта одной и той же БД мог занимать от часа до пяти. Тогда казалось, что это какая-то магия, секрет который так нам и не открылся. Наверное инженеры техподдержки между делом предавались медитации, забывая о том, что где-то там в далекой России дедлайны, инженеры без новогодних салатов, плачет и страдает заказчик…

Итоги проекта

Финальным аккордом миграции была передача систем на сопровождение.

Сейчас мы предоставляем сервис единого окна для обращений заказчика и закрываем весь объем задач по сопровождению компонент инфраструктуры и SAP basis вместе с партнером — itelligence. Клиент живет в частном облаке уже полгода. Вот статистика по сервисным случаям за это время:

Дана методика создания объектов миграции в 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:

В качестве примера рассмотрим загрузку данных в пользовательскую таблицу ZSD_HISTCOND «История цен», поля которой приведены в Таблице 1.

Таблица 1 Поля таблицы БД ZSD_HISTCOND

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

В транзакции 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.

Читайте также: