Great minds think alike

Слушаю последний выпуск подкаста:

https://radio-t.com/p/2024/07/27/podcast-920/ (тема про Haystack)

И там Григорий рассказывал про свою мечту, ну чтоб:

  • исходный текст был rich-text, чтобы можно было пожирнять, картинку вставить внутрь
  • объекты разработки хранились в базе данных
  • использование объектов было индексировано
  • версии объектов хранились прямо в базе данных без дополнительных гитов
  • был тулинг/IDE всё это поддерживающий
  • проект собирался не из файлов, а прямо из базы данных

Удивительно, но SAP/ABAP-разработка пошла по этому пути давным-давно, но:

  • до rich-text они так и не добрались, хотя до до остального — в целом скорее да
  • система получилась закрытой и своеобразной

… и мне это скорее нравится, если бы не это, то я бы скорее всего свичнулся.

Как в программе ABAP можно получить список последних введенных в поле значений?

Интересный вопрос.

Если кратко, то может быть и можно, но всё очень-очень сложно.

Тут вопрос в концепции.

С одной стороны, любая программа ABAP работает только на сервере. SAP GUI работает на компьютере пользователя и отвечает только за показ результата работы и ожидание дальнейших инструкций от пользователя. Пользователь видит результат, нажимает кнопку, SAP GUI передаёт нажатие кнопки на сервер, серверная программа снова отрабатывает и даёт новый результат, отправляет его на просмотр пользователю.

Это круг PAI-PBO, который никогда не прекращается.

BTW, с точки зрения архитектуры SAP GUI — это «тонкий клиент», так как никакая прикладная логика на нём не работает, только красивое отображение и приём-передача информации на сервер и обратно.

С другой стороны, список последних введённых значений хранится только на SAP GUI (то есть на компьютере пользователя), и сервер ничего не знает про это. Так же как и не знает какого цвета кнопки. Вы можете сами включить в SAP GUI любую тему и поменять все цвета, но на работу ABAP это никак не повлияет, и сервер про это никогда не узнает.

С точки зрения ABAP-сервера, нет никакой разницы, выбираете ли вы значение из истории, или вводите его вручную заново, или вставляете из буфера обмена.

На практике существуют некоторые пользовательские функции, когда необходимо взаимодействие ABAP-сервера и SAPGUI-клиента:

  • загрузка файла (GUI_UPLOAD)
  • выгрузка файла (GUI_DOWNLOAD)
  • показ индикатора прогресса (SAPGUI_PROGRESS_INDICATOR)
  • и ещё кое-что по мелочи

Оно реализовано очень нетривиально внутри, можете убедиться.

Если поглядеть в класс CL_GUI_FRONTEND_SERVICES, например в метод CALL_METHOD, то окажется, что ничего просто так сделать не получится.

Вообще большой вопрос — умеет ли SAP GUI отдавать такую информацию или нет, документировано это или нет. В классе не видно ни одного метода, отдалённо напоминающего требуемую функциональность.

Тупик, приехали.

На крайний случай, если очень-очень хочется, чисто теоретически, можно найти на клиенте (компьютере пользователя) файл, куда пишется история, загрузить его в ABAP и распознать.

c:\Users\Ivan\AppData\Roaming\SAP\SAP GUI\History\SAPHistoryIVAN.db

Этот файл пишется в моём случае в формате SQLite, который неизвестно как разбирать, напрямую в ABAP его анализ невозможен. Ещё неизвестно, что за защита на нём стоит, потому что внутре данные покорябаны:

Тоже приехали.

На моей памяти это задача одна из самых невозможных. Хотя казалось бы…

Расходимся, или вам есть что добавить?

Code review

В последнем выпуске подкаста Radio-T ведущие снова спорили о пользе или бесполезности Code review: https://radio-t.com/p/2024/07/13/podcast-918/

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

Я в текущих своих условиях вижу один довод «за» — если есть процедура Code review, то я пишу чище.

Кстати, устоявшегося термина на русском языке так и не сложилось. Википедия предлагает сразу четыре варианта:

Просмотр кода, рецензирование кода, обзор кода, ревизия кода

и ни с одним из них я не сталкивался в жизни.

На HeadHunter свежая вакансия: ABAP-разработчик (FI, CO, MM)

Обязанности и требования самые обыкновенные:

Обязанности:

  • Разработка программных приложений по модулям: FI, FI-AA, CO, MM;
  • Разработка отчетов и печатных форм;
  • Внесение изменений в существующие разработки;
  • Адаптация стандартных программ SAP;
  • Разработка межсистемных интерфейсов;
  • Оптимизация программного кода.

Требования:

  • От 5ти лет опыта в ABAP-программировании;
  • Опыт отладки, доработки и понимания чужого кода;
  • Опыт выгрузки в шаблоны Excel, Word, обработка XML;
  • Использование принципов оптимизации быстродействия ABAP-программ и SQL-запросов;
  • Знание технологий расширения SAP стандарта (User-Exit, BAdi, OpenFI и др.).

А вот в условиях я кое-за-что зацепился взглядом:

Условия:

  • Удаленная форма работы;
  • Полная занятость, полный день;
  • График работы 5/2, сб и вс — выходные, в пятницу до 15:30;
  • Посещение офиса в Москве несколько раз в месяц;
  • Версия SAP – 4.6C;

Версия 4.6С это примерно 2000 год.

Мне так помнится, что когда я начинал карьеру ABAP-разработчика, то у заказчика стояла версия 4.7, которую мигрировали сначала на 5.0, а потом и на 6.0.

В целом, если система стоит и работает с 2000 года по 2022 год, то она проработает и до 9999 года. А вот дальше — уже не получится.

Впрочем, нет, я не готов возвращаться на старый отладчик.

Нарисуй агитационный плакат в советском стиле. В нижней части кадра рука протягивает человеку в косттюме доисторический каменный молоток. Человек на главном переднем плане жестом руки отказывается от этого каменного молотка. По середине плаката находится крупная надпись «НЕТ!».

Агитационный плакат в советском стиле. В нижней части кадра рука протягивает человеку в косттюме доисторический каменный молоток. Человек на главном переднем плане жестом руки отказывается от этого каменного молотка. По середине плаката находится крупная надпись 'НЕТ!'.

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

Какого типа будет DATA(lv_amt_3) = lv_amt_1 + lv_amt_2 ?

Написал всё просто и понятно, и мне казалось очевидно, что будет на выходе:

Как же я ошибся! А будет вот что:

chatGPT

Ну допустим, я показал ему текст некоторой программы:

Так вот, сервис может пояснить за код, лучше чем я:

(далее…)

Кое-что новое o VARYING

Есть в ABAP кое-какие языковые конструкции, отсутствующие в топовых языках, по крайней мере на базовом уровне, например MOVE-CORRESPONDING.

VARYING — это одна из таких конструкций. Я изредка использовал её в базовом варианте:

Результат предсказуем:

Но как иногда оказывается, у этой конструкции есть две дополнительных глубины.

Во-первых, можно крутить два поля одновременно:

И оказывается так тоже можно, результат не удивит:

А во-вторых, поля в последовательности могут называться как угодно.

Мне раньше казалось, что нумерация в поле очень важна: VAL01, VAL02. Магия! А вот нет. Так тоже можно:

Если чуть подумать, то станет всё понятнее, как оно было заложено и почему. Могу проиллюстрировать на менее интуитивно понятном примере:

Обратите внимание на DO 5 TIMES. Ха-ха? Знаете что произойдёт?

(далее…)

Кладбище велосипедов

Пробежала статья сегодня: Hello, SAP, Where Are My Global Classes?

Автор жалуется что классы как бы глобальные, а всё равно система всё больше и больше становится кладбищем велосипедов. Ничего найти нельзя, проще придумать очередной велосипед.

И тут же у меня возник резонанс: пробежал баг с неправильным расчётом и там важно было учесть количество дней между двумя датами.

В предыдущей редакции предыдущим автором использовал следующий подход:

 Хорошо, вот только теперь говорят, что дни надо считать только рабочие.

Вот и снова мы попадаем на кладбище велосипедов, хочешь RKE_SELECT_FACTDAYS_FOR_PERIOD, а можно и DURATION_DETERMINE, но наверняка способов ещё немало. И найти их проще через гугл, чем непосредственно в системе.