Консоль запросов для SAP ERP. Выполнение SQL-запросов
В этой статье я хочу рассказать о том, с какими проблемами мы столкнулись в процессе внедрения SAP ERP при разработке ABAP-программ и какой инструмент нам помог оптимизировать этот процесс.
Системный ландшафт и процесс разработки ABAP-программ
При внедрении информационно-управляющей системы на базе SAP ERP, как правило, разворачивается комплекс систем:
- Система разработки.
- Система тестирования.
- Система продуктивной эксплуатации.
Система разработки обычно содержит минимум данных и полноценно протестировать написанную программу в этой системе не получается. Код из системы разработки переносится в другие с помощью, так называемых, транспортных запросов.
Стандартная ситуация: программист пишет код в системе разработки, переносит его в тестовую систему и в процессе тестирования обнаруживает, что написанный код работает некорректно, после чего он возвращается в систему разработки для исправления ошибок, а затем повторно переносится в тестовую систему (Рис. 1). Этот процесс зацикливается, и каждая такая итерация отнимает около десяти «непродуктивных» минут, которые разработчик тратит на рутинные действия по переносу запроса. И таких итераций может потребоваться много.
Бывают также ситуации, когда в тестовой системе программа отрабатывает нормально, разработчик переносит ее в продуктивную систему и видит, что имеются серьезные проблемы с производительностью этой программы. В тестовой системе это не проявлялось, потому что объем данных в ней был не такой большой, как в продуктивной системе, или нагрузка на БД была меньше. И опять разработчик возвращается в систему разработки, чтобы оптимизировать программный код. Теперь каждая итерация у него будет занимать еще больше времени, так как, в большинстве случаев, перенос изменений в продуктивную систему сопровождается цепочкой согласований изменений с разными ответственными лицами.
Рис. 1. Системный ландшафт
Оптимизация процесса разработки
Поняв, что теряем много времени на подобные вещи, мы пришли к выводу, что нужно этот процесс оптимизировать: надо уменьшить число итераций по исправлению кода и таким образом сократить общее время разработки (Рис. 2).
Рис. 2. Оптимизация Системного ландшафта
В первую очередь мы обратили внимание на SQL-запросы. Они часто бывают самым слабым местом в коде: либо данные выбираются некорректно, либо выбираются очень медленно.
Те, кто знаком с разработкой на 1С, знают, что там есть инструмент, который называется «Консоль запросов», позволяющий выполнять произвольные запросы напрямую в продуктивной системе без дополнительных разработок. Мы решили, что нам нужен такой же инструмент для SAP, то есть нам требуется инструмент, который бы позволял оперативно тестировать этот запрос на продуктивных данных и сразу же вносить в него корректировки без переноса кода. Этот инструмент дал бы возможность при разработке использовать в коде ABAP-разработки уже полностью протестированный запрос.
Я решил заняться поиском такого инструмента.
Существующие инструменты
Я рассмотрел существующие инструменты SAP по работе с таблицами, в поисках такого, который помог бы с тестированием произвольных запросов в продуктивной системе, – у всех были те или иные недостатки (Рис. 3):
Рис. 3. Недостатки существующих инструментов
- Транзакция SE16/SE16N
- Можно делать выборку только из одной таблицы. Не подходит для запросов с несколькими таблицами.
- Транзакция ST04 (Additional functions -> SQL Command Editor)
- Во-первых, воспринимает только Native SQL-запросы (синтаксис СУБД), что накладывает некоторые неудобства, так как при разработке программ на ABAP для универсальности используются Open SQL-запросы, отличающиеся синтаксисом. Это, впрочем, можно было бы «пережить», если бы не «во-вторых».
- Во-вторых, работает только в том случае, если в качестве СУБД используется Oracle.
- Транзакция SQVI
- Нельзя соединять таблицы по не ключевым полям.
- Нельзя составлять запросы с подзапросами.
- Не отражается текст запроса. Выборка настраивается графически.
Готовые Z-разработки, найденные в интернете, тоже не подходили по различным причинам. В основном, из-за каких-либо существенных ограничений.
В итоге, не найдя подходящего готового инструмента, я решили разработать его сам.
Разрабатываем
Для начала в транзакции SE80 создаем программу ZSQL, GUI-статус MAIN100 с кнопкой «Выполнить» и Экран 0100.
Укрупнённо алгоритм программы выглядит так (Рис. 4):
Рис. 4. Алгоритм программы
Считывание SQL-запроса
Для получения SQL-запроса будем использовать текстовый редактор, который создадим на экране с помощью класса CL_GUI_TEXTEDIT. Для этого добавим на Экран 0100 пустой контейнер с именем MYEDIT, в который будем выводить редактор.