Джавапокалипсис в отдельно взятой системе

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

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

  • много пользователей работают через 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, то пользователи в другом конце страны не могут что-то настроить, то вдруг кому-то кажется, что низкий уровень безопасности в браузере решает проблему…

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

 

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

И вот Джавапокалипсис прилижается.

Рассмотрим варианты.

(далее…)

Аудит в ландшафте разработки ABAP. Часть 9. Диапазоны номеров

Небольшой периодический аудит в системе разработки, как и периодическое медицинское обследование не бывает лишним. Это может понадобиться, если вы:

  • входите на проект с существующим большим историческим слоем разработок;
  • принимаете большой объём разработок от подрядчика/субподрядчика;
  • просто решаетесь на ежегодную генералку или ревизию.

В данной заметке делается обзор в части аудита диапазонов номеров.

(далее…)

Куда пристроить модульные тесты в ABAP. Часть шестая. Промежуточные итоги.

Хочу с экзитами закончить и подвести промежуточные итоги в этой части:

  • Код теста получается больше продуктивного кода.
  • Во многих случаях подходы TDD оправданы и рекомендуются к употреблению.
  • Обзор существующего продуктивного кода без тестов вызывает существенное напряжение мозговых извилин.
  • Если пытаться покрыть тестами уже написанный код, то часто без рефакторинга не обойтись. А рефакторинг – несколько другая и более сложная задача, чем само покрытие тестами. Рефакторинг можно отложить до момента, когда вы будете делать с кодом что-то ещё.
  • Если у вас есть продуктивный код, который не меняется годами, то его покрывать тестами нужно в последнюю очередь.
  • Код может быть остаться непокрытым из-за замкнутой петли: Нельзя сделать правильные тесты, потому что сначала надо сделать серьёзный рефакторинг, а делать рефакторинг не рекомендуется пока нет тестов. Разрывайте эти петли, если тесты всё-таки нужны.
  • В некоторых случаях выполнить покрытие тестами не получается. Так бывает. Смиритесь.
  • По некоторым метрикам подсчета полноты покрытия гораздо проще добиться 100%, чем по другим. Но это не значит, что нужно делать так, как проще.
  • Тесты нужны не для того, чтобы добиться 100%, а для того, чтобы они когда-нибудь правильно упали. Потому что уметь правильно падать – это самое главное. Если это верно для каратистов и велосипедистов, значит и для программистов тоже. Лучше правильно упасть плохо крутя педали, чем неправильно упасть хорошо крутя педали.

Куда пристроить модульные тесты в ABAP. Часть пятая. Тридцать восемь попугаев

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

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

А что значит равны? И что такое 10%?

(далее…)

Куда пристроить модульные тесты в ABAP. Часть четвёртая. Как вы лодку назовёте…

Продолжаю записывать мысли на тему.

Для работы ABAP Unit неважно:

  • сколько у вас тестовых классов вообще;
  • как называется тестовый класс;
  • в каком месте он расположен;
  • как называются его методы.

Главное, чтоб локальный класс:

  • был доступен;
  • имел кличку “for testing”;
  • имел методы с кличками “for testing”.

 

Но, с другой стороны, даже имена переменных-то тоже не являются случайным набором букв.

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

(далее…)

Про дилетантов

Не так давно на Хабре пробежала статья, в которой некий дилетант кидал камни в огород SAP.

Один из камней:

Почему люди переводившие продукт не понимали русский язык? Потому что даже при перепечатывании русскоговорящий человек должен был усомниться, увидев фразу «Пушномолочная свинья-несушка» — так до определенного времени называлась программа RAIMEWMS (сейчас название уже исправили). В оригинале она называется «Eierlegende Wollmilchsau», что переводится как «Мастер на все руки», но умный Magic Gooddy посчитал, что Wollmilchsau – это 3 отдельных слова (Woll, milch, sau) и перевел фразу «Eierlegende Woll milch sau» как «Яйцо укладки шерсти молока свиноматки». Остается только гадать, как это потом превратилось в «Пушномолочная свинья-несушка».

Вот вопрос: кто больший дилетант? Тот, кто сделал такой перевод, или тот, кто кинул камень?

По пунктам:

(далее…)

Куда пристроить модульные тесты в ABAP. Часть вторая. Первые грабли.

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

Грабля первая. Обработка ошибок.

Допустим, наш ФМ делает не замещение значений, а проверку:

function zfi_bte_00001120.

  if ls_bseg-zuonr eq space.
    message ‘Поле Присвоение обязательно для заполнения’ type ‘E’.
  endif.

endfunction.

Тут есть две проблемы.

(далее…)

Куда пристроить модульные тесты в ABAP. Часть первая. Первый тест.

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

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

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

А теперь отдельно про экзиты.

(далее…)

Формирование фоновых заданий и массовый запуск транзакции ASKB/ASKBN

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

Загвоздка первая: транзакция ASKB полно и продуктивно работает только в фоновом режиме. На всякий пожарный случай от греха подальше.

Загвоздка вторая: транзакция ASKB не умеет работать с несколькими БЕ. Экран выбора не оставляет выбора. Если бы на нашем проекте было бы мало БЕ (одна-две-три), то можно было бы просто создать напрямую несколько фоновых заданий и дело в шляпе. Но если у нас сотня БЕ, то уже необходима собственная запускалка, раз стандартной нет никакой.

Отлично, приступаем к реализации.

(далее…)