Адаптация пользовательского ABAP-кода для перехода

на S/4HANA (S4D440)

Василий Ковальский
Прочитать позже
871

Содержание
Проблематика. Зачем это нужно

1. Необходимость адаптации кода при переходе на S/4HANA

1.1. Влияние базы данных SAP HANA на пользовательскую разработку

1.2. Упрощения. Влияние S/4HANA на пользовательскую разработку

2. Процесс перехода

3. Инструменты для анализа пользовательского кода

4. Примеры адаптации

5. Заключение

Проблематика. Зачем это нужно

Нормализация отношений в базе данных позволяет избежать дублирования данных и тем
самым уменьшает их объем, кроме того она помогает избежать многих логических
ошибок. Но обеспечение соединения хранящихся в разных таблицах нормализованных
данных требует дополнительного времени, а это при большом объеме весьма
разнообразных данных, и при большом числе запросов приводит к снижению
производительности. Поэтому база данных SAP R/3 в значительной степени
денормализована. Денормализацию унаследовала от нее и SAP ERP. Развитие техники
привело к революционному увеличению быстродействия памяти и процессоров,
уменьшению размеров и снижению стоимости как хранения информации в оперативной
памяти, так и процессорных операций. Это позволило создать высокопроизводительную
базу данных SAP HANA, в которой «горячая» информация хранится в оперативной
памяти и потому быстро доступна. Можно использовать SAP HANA в качестве базы
данных для SAP ERP (и других составляющих SAP Business Suite), при этом при
правильном программировании можно рассчитывать на повышении производительности.
Но следует помнить, что данные в SAP ERP существенно денормализованы.

SAP S/4HANA специально разработана для совместной работы с базой данных

SAP HANA. Данные в SAP S/4HANA подверглись существенным упрощениям
(симплификациям): значительно изменен состав и устройство таблиц, в частности были
удалены таблицы, содержавшие дублирующие данные. SAP изменил свои ABAP-
программы, так чтобы они эффективно работали с новой структурой данных.
Соответственно сделанным упрощениям должны быть изменены и программы,
написанные пользователями.

Двухдневный семинар S4D440. Custom Code Migration from SAP ERP to

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

1. Необходимость адаптации кода при

переходе на S/4HANA
SAP S/4HANA специально разработана для работы с базой данных SAP HANA, но
SAP HANA может использоваться и для SAP ERP. Следует различать влияние
особенностей базы данных SAP HANA и влияние особенностей SAP S/4HANA на
пользовательскую разработку.

1.1. Влияние базы данных SAP HANA на

пользовательскую разработку
В большинстве таблиц базы данных SAP HANA данные хранятся не построчно, а
поколоночно. Поколоночное хранение упрощает вычисление агрегатных функций и
подведение итогов. В SAP HANA в настоящий момент 22 агрегатные функции, а не 5, как
это предусмотрено в стандарте ISO/IEC 9075:1992, Database Language SQL:
<set function type> ::= AVG | MAX | MIN | SUM | COUNT.

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

большие) можно разделить на несколько партиций, и обработку по каждой колонке для
каждой партиции тоже можно распараллелить. Все это позволят увеличить
производительность.

В SAP HANA нет кластерных таблиц и таблиц пула. Таблицы, раннее входившие в

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

Язык SQL для базы данных SAP HANA обладает синтаксическими особенностями.

Поэтому все ранее написанные обращения на нативном SQL – будь то внутри
операторных скобок EXEC SQL… ENDEXEC или с помощью классов ADBC – должны
быть адаптированы к синтаксическим правилам языка SQL базы данных SAP HANA.

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

А потому ABAP программы, написанные для использования совместно с базой данных

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

1.2. Упрощения. Влияние S/4HANA на

пользовательскую разработку
Выше уже отмечалось, что нормализация позволяет исключить дублирование данных и
избежать многих логических ошибок, но при большой нагрузке может привести к
снижению производительности. Технический прогресс в микроэлектронике сделал
возможным высокопроизводительные базы данных, в частности SAP HANA. Высокая
производительность позволила нормализировать базу данных, используемую в
SAP S/4HANA. Сделаны многие упрощения (simplifications). Таблицы, содержавшие
дублирующую информацию удалены. Часто информация, содержавшаяся в таких
таблицах может быть получена из специально определенных ракурсов (представлений,
view), в ряде случаев «лишние» таблицы были удалены и замена им не была создано.
Удалены некоторые транзакции, нужда в которых отпала. В некоторые таблицы были
добавлены поля из потерявших актуальность и удаленных таблиц. В ряде случаев была
изменена длина полей таблиц. Стандартное программное обеспечение SAP S/4HANA
было переписано с учетом произведенных упрощений. При переходе на SAP S/4HANA
пользовательское программное обеспечение должно быть адаптировано к сделанным
упрощениям: невозможно обратиться к отсутствующему источнику данных.

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

адаптации пользовательских программ в соответствии со сделанными упрощениями.
Перечень упрощений храниться в базе данных упрощений. Его можно исследовать с
помощью новой транзакции SYCM. Для SAP S/4HANA релиза 1809 база упрощений
затрагивает изменения 214622 объектов репозитория, и описано это в 289 нотах.

Например, в SAP ERP, была прозрачная таблица закрытых позиции дебиторов BSAD. В

SAP S/4HANA этой таблицы нет, вместо нее можно использовать SQL view BSAD. Это
описано в двух нотах.
2. Процесс перехода
Процесс перехода на SAP S/4HANA состоит из нескольких шагов.

Сначала определяются системные требования. С какой системы на какую предполагается

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

Сам по себе переход это последовательное применение ряда нот. В каждой ноте описаны
ее пререквизиты, что должно быть сделано прежде, чем эту ноту применять. В принципе
все это можно выяснить просто при внимательном чтении нот. На SAP портале есть
отдельный инструмент Maintenance planner, который поможет сделать эту работу. На
выходе определяется требуемая последовательность необходимых обновлений. И для
этого разработчик не нужен.

Перед тем, как приступать к обновлениям, нужно сделать ряд предварительных проверок,
в результате которых выясняется, готова ли система к переходу. Эти проверки
поставляются в виде нот. Если эти проверки показывают неготовность, нужно применить
ряд нот, которые исправят это положение. После чего проверки нужно повторить… И так
далее, пока все проверки не пройдут успешно. На выходе получаем систему, готовую к
переходу во всем, кроме пользовательских разработок. Для этого этапа разработчик тоже
не нужен.

Как правило пользовательские системы содержат оригинальные разработки. Нужно их

подготовить к переходу: удалить неиспользуемые разработки, переписать оставшееся по-
хорошему, а не так, как их написали годы назад начинающие разработчики. Если
исходная система использует в качестве основной базы не SAP HANA, старые разработки
следует переписать так, чтобы SAP HANA работала эффективно. Как это делать можно
узнать на семинаре HA400. Программирование для SAP HANA на ABAP. Необходимо
проверить все пользовательские разработки на готовность работать с упрощениями, а если
они не готовы, то нужно внести соответствующие исправления и опять проверить. На
выходе получаем систему, вполне готовую к переходу. Этот этап требует большой работы
разработчиков.

На следующем этапе производится сам переход исходной SAP ERP системы в

SAP S/4HANA с помощью Software Update Manager. На этом этапе происходит
приведение данных к новой структуре и замена программ. В результате получаем
работоспособную обновленную систему. Разработчик на этом этапе не нужен.

Последующая работа связана с разработкой и переработкой прикладных программных

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

Уфффф!

3. Инструменты для анализа

пользовательского кода
Зачастую значительная часть пользовательских разработок вообще не используется. Раз
так, то нет причин тратить усилия на адаптацию ненужных разработок к SAP S/4HANA.
Существуют инструменты, позволяющие определить использованные ABAP-программы.
Монитор ABAP Call Monitor (транзакция SCMON) позволяет трассировать вызовы ABAP-
программ и их процессинговых блоков. У этого монитора есть существенное ограничение:
не более двух миллиардов записей (точнее не более 2 ^ 31 – 1 = 2147483647). Можно
просмотреть накопленные данные. Транзакция SUSG агрегирует информацию по
вызовам. Она не предъявляет результатов агрегации, но эти результаты можно увидеть в
соответствующих CDS views. В результате получаем перечень использованного
программного обеспечения. Все остальные пользовательские разработки не были
использованы. Разумеется трассирование нужно вести достаточно долго, например,
несколько месяцев.

Те же пользовательские программы, которые действительно используются, следует

проверить. Можно воспользоваться встроенными средствами Расширенная проверка
(Extended Program Check), Анализатор (инспектор) кода (Code Inspector), ATC (ABAP Test
Cockpit). Можно также воспользоваться отдельными транзакциями SLIN, SCI, SCII, ATC.
Среди прочих удобств транзакция ATC предоставляет возможность проверить программы
в удаленной системе.

В транзакции SCI при определении варианта проверок можно указать проверки на

готовность к переходу на SAP S/4HANA.

Варианты проверок, созданные в Инспекторе кода, можно использовать в ATC. После

того, как выявлены проблемы в пользовательских разработках, пользовательские
разработки должны быть адаптированы так, чтобы проблем не оставалось.
4. Примеры адаптации
Во многих случаях увеличены размеры полей. При прямом присвоении передавать данные
из меньшего поля в большее можно без проблем, а вот передача из большего в меньшее
может привести к потере данных. Кроме того, если происходит передача данных не по
полям, а целиком структурами, может произойти смещение, и данные попадут «не в свои»
поля. Кроме того могут возникнуть синтаксические ошибки при использовании
соответствующих типов данных в определении интерфейсных параметров. Во всех таких
случаях нужно так изменить описание типов в пользовательских программах, чтобы
ошибок не происходило. Особый случай представляет изменение полей, типы которых
используются в интерфейсных параметрах прикладных программных интерфейсов,
которые должны по-прежнему работать и в тех системах, которые еще не перешли на
типы данных, определенные для SAP S/4HANA.

Серьезно изменен состав таблиц и ракурсов (представлений, views). Удалены многие

таблицы и ракурсы. Все обращения к несуществующим объектам будут приводить к
синтаксическим ошибкам. Пользовательские программы, обращавшиеся к ним нужно
переписать так, чтобы исключить обращение к несуществующим объектам репозитория. В
ряде случаев таблицы заменены на одноименные им ракурсы, в таком случае чтение по-
прежнему возможно, а вот изменение – нет. Для некоторых таблиц введены прокси-
объекты, такие, что выборка из такой таблицы будет автоматически заменена на выборку
из прокси объекта. Чтение из таких таблиц, стало быть, возможно. Запись синтаксически
возможна, но данные при чтении будут браться из прокси объекта, значит, то что
положено в саму таблицу, будет потеряно. Также случается, что одна таблица заменена
другой. Во всех этих случаях нужно надлежащим образом адаптировать пользовательские
программы. Во многих случаях результат проверки на готовность к переходу на
SAP S/4HANA Инспектор кода укажет номер ноты, где этот случай описан. Например,
если пользовательская программа в системе SAP ERP читает данные из таблицы KONV,
Инспектор кода выдаст сообщение:

DB Operation Select found (KONV, see Note(s):0002220005

А в ноте 2220005 написано, что соответствующее описание дано в приложении.

Выгружаем файл приложения Coockbook_Pricing_ConditionTechnique_20160725.pdf,
внимательно читаем и в нем видим такой текст: «A new database table called
PRCD_ELEMENTS has been introduced to replace the KONV table’s function of storing
document condition».

Если пользовательские разработки содержат ракурсы, то эти ракурсы тоже нужно

проверить на готовность к переходу и при необходимости адаптировать. Если ракурс базы
данных (Database view) содержит устаревшую не удаленную таблицу, то он будет
выдавать пустоту, поскольку устаревшая таблица не содержит данных, а ракурс базы
данных логически эквивалентен внутреннему соединению таблиц. По сообщению
проверки Инспектора кода SCI или непосредственно в транзакции SCYM находим
соответствующие ноты, и поступаем так, как это указано в ноте или приложенной
документации. Делаем, как там написано.

Ракурс базы данных (Database view) может содержать устаревшую таблицу, замененную
на ракурс. Написать в ABAP SELECT к такой таблице можно, а вот использовать в
описании Database view нельзя, раз такой таблицы нет. Придется переписывать Database
view каким-то иным способом. Например, если пользовательское Database view
использует в SAP ERP таблицу BSIK, замененную в SAP S/4HANA на Database view BSIK
придется переписать пользовательский ракурс так, чтобы в нем использовались таблицы
базы данных BSEG и BKPF, которые участвуют в ракурсе BSIK в системе SAP S/4HANA.

Другим способом решения может быть создание не Database view а CDS view, поскольку
DDL описания CDS могут использовать в качестве источника данных не только таблицы,
но и CDS view. Аналогично можно поступить и в случае, если пользовательский ракурс
базы данных использует устаревшую таблицу, замененную прокси объектом.

Особо стоит отметить случай, когда в пользовательских разработках были расширены

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

5. Заключение
Мы кратко рассмотрели содержание семинара S4D440. Custom Code Migration from
SAP ERP to SAP S/4HANAP. Семинар продолжается 2 дня, включает 8 упражнений

Семинар необходим ABAP-разработчикам, консультантам в области разработки на ABAP,

участвующим в переходе на SAP S/4HANA, нужен руководителям разработок и может
быть полезен специалистам по поддержке и консультантам приложений.

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

был толк, непременно необходимо обладать знаниями, излагаемыми на семинаре ABAP
CDS. Определение ракурсов и профилей в репозитарии. (S4D430). Не для этого
семинара, но для эффективного программирования на ABAP HANA нужно владеть
знаниями, даваемыми на семинаре ABAP для HANA (HA400),а чтобы вообще писать
производительные ABAP-программы еще и Настройка производительности ABAP
программ.

Василий Ковальский,

ABAP-инструктор с 1998 года.

SAP Education CIS.