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

«Ко­рре­кти­ро­вка таблиц базы данных с помощью ABAP»
Олег Точенюк:
Андрей а вам никто никогда не говорил, что обновлять таблицы базы данных SAP категорически запрещено, независимо от того чем обусловлены такие желания. Свои Z-таблицы, да сколько угодно, но......
«Тра­нза­кция SM02: сообщения в SAP системе»
Олег Башкатов:
С помощью ФМ TH_POPUP можно отправить сообщение конкретному пользователю :-)
«Практика освоения ABAP CDS для не­про­гра­мми­сто­в. Часть 1»
Михаил Вронский:
Большое спасибо за статью. Написана хорошим языком, даны правильные формулировки - с полнотой и логической последовательностью.

База знаний

Адаптация пользовательского ABAP-кода для перехода на S/4HANA (S4D440)

1006

Содержание

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

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

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

Как правило пользовательские системы

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

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


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