Содержание

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

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, который поможет сделать эту работу. На выходе определяется требуемая последовательность необходимых обновлений. И для этого разработчик не нужен.

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

Как