Иван ivanbolhovitinov

Эта статья ориентирована на ABAP-разработчиков в системах SAP ERP. Она содержит много специфических для платформы моментов, которые малоинтересны или даже спорны для разработчиков, использующих другие платформы.

Есть такой эвфемизм: “исторически сложилось”.

Так вот, в моей основной системе исторически так сложилось, что:

• много пользователей работают через SAP GUI for HTML;
• практически вся отчетность выгружается в Excel через ZWWW.

А это значит что без правильно настроенной связки Браузер+Java жить непросто.

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

Кроме этого, ZWWW работает через технологию OLE, без вариантов. А веб-приложение нельзя подпускать к OLE-интерфейсам клиентской машины даже в радиусе поражения ракет класса “земля-воздух”. Следовательно, нужна ещё одна прослойка в виде Java-апплета, которая будет проксировать OLE-вызовы и выполнять сопутствующие махинации.

Так как SAP GUI for HTML и сам является прослойкой между ABAP-инстанцией и ITS-сервером, то всё это сооружение начинает походить на игру Дженга.


Такая игра идёт постоянно. То браузеры начинают отключать старую джаву, то джава-апплеты теряют полномочия, то что-то происходит с проверкой подписи апплета, то появляются какие-то черные/белые списки исключений, то вдруг апплет начинает жутко тормозить на какой-то версии JRE, то выходит новая версия офиса, то обновляют ITS/ABAP, то пользователи в другом конце страны не могут настроить политику безопасности, то вдруг кому-то кажется что проще выставить в браузере низкий уровень безопасности …

Если следить за хронологией, то можно заметить:

• Firefox – прекратит поддерживать Java-апплеты уже через год
• Chrome – даже если когда-то и поддерживал, то уже всё закончилось
• Edge – не поддерживал Java-апплеты, и не будет поддерживать
• Oracle – отказывается от поддержки Java-плагинов начиная с Java 9

Скоро останется только старый и не очень добрый IE. Евошний разработчик хоть и обещал поддерживать IE11 в Windows 10, но мы-то с вами знаем …

Что будет, если у бухгалтера внезапно отобрать возможность выгрузить любой отчет в Excel? Апокалипсис!
И вот Джавапокалипсис прилижается.

Эта статья ориентирована на ABAP-разработчиков в системах SAP ERP. Она содержит много специфических для платформы моментов, которые малоинтересны или даже спорны для разработчиков, использующих другие платформы.

Это третья часть публикации. Начало можно прочитать тут:
Модульные тесты в ABAP. Часть первая. Первый тест
Модульные тесты в ABAP. Часть вторая. Грабли

Будем меряться

Считается, что главной метрикой качества тестов является покрытие. В разработческих интернетах часто можно встретить формулировки в стиле “полное покрытие”. Как правило, под полным покрытием понимается некий абсолют в 100.00%.

Процент покрытия – цифра сомнительная, ровно настолько же сомнительная, как и “средняя температура по больнице”. Процент покрытия по проекту – это среднее покрытие его частей. То есть: Модуль-1 имеет покрытие 80%, Модуль-2 имеет покрытие 20%, в среднем покрытие будет равно 50%, если допустить что модули примерно равны по содержимому. А верно ли что 80% в четыре раза лучше чем 20%?

Эта статья ориентирована на ABAP-разработчиков в системах SAP ERP. Она содержит много специфических для платформы моментов, которые малоинтересны или даже спорны для разработчиков, использующих другие платформы.

Это вторая часть публикации. Начало можно прочитать тут: Модульные тесты в ABAP. Часть первая. Первый тест

Первый шаг сделан. Теперь нужно расширить и углубить наше наступление. Глобальная цель – максимально полное покрытие тестами, в рамках целесообразности происходящего. Под пристальным наблюдением — экзиты.



Под катом я приведу несколько примеров граблей, на которые можно наступить.

Эта статья ориентирована на ABAP-разработчиков в системах SAP ERP. Она содержит много специфических для платформы моментов, которые малоинтересны или даже спорны для разработчиков, использующих другие платформы.

В умных книгах и статьях много про это написано в целом. Но вопрос по части специфики в ABAP-программировании раскрыт мало.

ABAP-программирование может быть совсем разным. Но почти в любом большом проекте его можно разложить на следующие кучи:

• Экзиты (user-exits). Сюда относятся: проверки, замещения, BTE (Business Transaction Events), BAdI, CMOD и подобные способы расширения стандартной функциональности.
• Собственное приложение. Вполне вероятно, что это будет вариация на тему CRUD.
• Отчеты. Можно сказать, что отчёт – это такое собственное приложение, но у программ такого рода есть свои нюансы.
• Входящая интеграция, исходящая интеграция. Мы вызываем, нас вызывают, как это часто не совпадает.
• Вспомогательные библиотеки. Полуфабрикаты, необходимые для построения готового продукта.

И сейчас отдельно про экзиты.