Все ли корректировки пользовательского кода являются частью фазы SPAU в локальной миграции SAP ERP на S / 4 HANA? - PullRequest
Новая
       128

Все ли корректировки пользовательского кода являются частью фазы SPAU в локальной миграции SAP ERP на S / 4 HANA?

3 голосов
/ 10 июля 2020

Я планирую действия, которые нужно выполнить во время миграции на S / 4 HANA локально с точки зрения настраиваемого кода. Пока что Central AT C настроен для проверки текущего кода SAP E CC, где мы уже можем реализовать большинство исправлений в коде ABAP перед миграцией.

Следующим шагом является команда Basis продолжить обновление системы с помощью SUM. Они говорят мне, что я должен реализовать остальные настройки и исправления в SPAU, но, насколько мне известно, SPAU используется только для настройки стандартных объектов SAP, которые были изменены с помощью «ключа доступа» и изменились во время обновления.

Я делал SPAU раньше для небольших обновлений, и это имело место, конечно, модель данных не была изменена, и стандартные объекты не были устаревшими, как в обновлении S / 4 HANA.

Затем есть SPAU_EHN для настраиваемого улучшения, на которые могут повлиять изменения в стандартных объектах во время обновления.

Но когда дело доходит до остальных объектов ABAP, скажем, полностью независимая пользовательская программа, функциональный модуль Z, пользовательские классы и т. д. c. Являются ли корректировки этих объектов частью SPAU или, как я думаю, они уже являются частью ручных действий, выполняемых после завершения обновления?

Мое представление о порядке корректировки настраиваемые объекты следующие:

  1. Настройте все возможное в текущем E CC с помощью AT C проверки
  2. [BASIS] Обновите систему с помощью SUM
  3. При необходимости отрегулируйте измененные стандартные объекты в SPAU
  4. Отрегулируйте улучшения в SPAU_ENH, если необходимо
  5. ПОЛНЫЙ ПРОЦЕСС ОБНОВЛЕНИЯ
  6. Отрегулируйте остальные настраиваемые объекты репозитория с помощью приложения Fiori Migration App, Quick Fixes и так далее, пока список не уменьшится до нуля.

Следуя этому порядку, я бы использовал 1 транспортный запрос для шагов 3 и 4, а затем столько, сколько необходимо для шага 6.

1 Ответ

1 голос
/ 10 июля 2020

Вы правы. Обычный способ выполнить миграцию S / 4 - сначала выполнить обновление, а затем выполнить миграцию пользовательского кода.

Сначала вы используете SUM для обновления системы, затем вы используете SPDD, SPAU и SPAU_ENH, чтобы исправить любые конфликты между стандартными модификациями и апгрейдом. Но эти транзакции касаются только стандартного кода SAP, который был изменен вами, а затем снова изменен SAP во время этого обновления. Они игнорируют модификации объектов, которые не были затронуты во время обновления, и, конечно же, им все равно ни о чем в пространстве имен Z * и Y *.

Итак, после завершения технического обновления у вас есть S / 4, полная кода клиента, который сломан и содержит ошибки, потому что он не совместим с S / 4.

Теперь вы используете AT C и его интеграцию с ABAP Development Tools для Eclipse, чтобы найти все эти сломанные разделы в свой собственный код и исправьте их. В зависимости от того, сколько пользовательского кода у вас есть в системе, насколько хорошо он написан и задокументирован и насколько тесно взаимодействует с измененной функциональностью, это усилие, которое занимает от нескольких дней до нескольких месяцев. Это ничего, что вы делаете спонтанно и с небольшим планированием, как вы обычно делаете с согласованием SPAU.

Более подробную информацию о процедуре можно найти в официальном руководстве SAP .

...