I have a fresh new SAP ERP installation and one of the common tasks is automatically created jobs EU_INIT, EU_PUT, EU_REORG.
Here is my real-live shot.
1 500 000 seconds is equal to 416 hours!
Let’s look at the job log:
I hope someday the job will be finally completed.
But what am I talking about?
In my experience there is a widespread practice to use small frequent jobs. So sometimes I have to go to SM37 transaction and make sure that all is fine. For example, I would have 3-7 jobs recurring every five minutes (send mail, checks, post-processing tasks, receive data from external system, post data to external system and so on).
In this case daily view of SM37 is flooded with thousands of jobs that do nothing. BTW: Write logs to SLG1 is more practical solution than write to job log or spool.
Recurring short job can be converted into one big job with infinite loop inside: do some work + wait five minutes + work again + sleep + work + … etc.
And here we come to general idea of services or daemons. I would like to implement this concept sometimes somewhere.
You have configured outbound connection and started to write code.
Iteration 1
CALL FUNCTION ‘RFC_PING’ DESTINATION ‘DUMMY’.
Looks fine enough. But if you make mistake or connection is temporarily down or happens something else, you will get short dumps CALL_FUNCTION_REMOTE_ERROR, CALL_FUNCTION_NO_DEST or CALL_FUNCTION_OPEN_ERROR etc.
You should always avoid short dumps in common environment.
На некоторых видах прямых соединений из дома на нужные мне сервера NetWeaver я часто сталкиваюсь с ошибкой:
WSAECONNRESET: Connection reset by peer
Она возникает примерно через минуту, если ничего не делать в SAP GUI. Все окна вылетают, блокировки не снимаются, несохранённый результат теряется. Это может быть очень неприятно и обидно.
«Самый лучший гуй — одна большая кнопка в центре экрана с надписью «Сделай мне хорошо!» (с) Опытный дизайнер
«Самый лучший гуй — одна большая надпись в центре экрана «Тебе уже хорошо!» (с) Опытный программист
Цитата #437964 Неудобства: При работе с программой приходится нажимать на различные кнопки (с) bash.org.ru
В идеале каждая система должна стремиться к минимизации своего интерфейса.
В качестве плохого примера в системе SAP ERP можно вспомнить транзакцию проводки амортизации AFAB:
Первый экран выглядит очень типично для SAP ERP, поэтому и проблемы у этого экрана старые идеологические:
1. Первый экран (экран выбора) не даёт никакой информации о текущем состоянии
2. Все проверки происходят после заполнения всех параметров и запуска процесса
3. Объем задачи большой, заранее не просчитывается, поэтому установлено простое ограничение на тестовый прогон – 1000 записей
4. Формирование фонового задания и отслеживание его статуса – не самая простая пользовательская операция: пять кликов на запуск, пять кликов на просмотр, причём через непростые малознакомые экраны.
5. Нет никакой отчётливой сигнализации об ошибках расчёта
Я просто удивляюсь, почему за последние десять лет никто так и не решился переписать междумордие этой важной задачи.
BTW: Вполне вероятно, что в “Пульте управления закрытием” это и сделано, вот только это тема совсем другого разговора.
Так вот, в моей основной системе исторически так сложилось, что:
много пользователей работают через 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, то пользователи в другом конце страны не могут что-то настроить, то вдруг кому-то кажется, что низкий уровень безопасности в браузере решает проблему…
Если следить за хронологией, то можно заметить:
Chrome – никогда не поддерживал Java-апплеты, и не собирается
Edge – не поддерживал Java-апплеты, и не будет поддерживать
Хочу с экзитами закончить и подвести промежуточные итоги в этой части:
Код теста получается больше продуктивного кода.
Во многих случаях подходы TDD оправданы и рекомендуются к употреблению.
Обзор существующего продуктивного кода без тестов вызывает существенное напряжение мозговых извилин.
Если пытаться покрыть тестами уже написанный код, то часто без рефакторинга не обойтись. А рефакторинг – несколько другая и более сложная задача, чем само покрытие тестами. Рефакторинг можно отложить до момента, когда вы будете делать с кодом что-то ещё.
Если у вас есть продуктивный код, который не меняется годами, то его покрывать тестами нужно в последнюю очередь.
Код может быть остаться непокрытым из-за замкнутой петли: Нельзя сделать правильные тесты, потому что сначала надо сделать серьёзный рефакторинг, а делать рефакторинг не рекомендуется пока нет тестов. Разрывайте эти петли, если тесты всё-таки нужны.
В некоторых случаях выполнить покрытие тестами не получается. Так бывает. Смиритесь.
По некоторым метрикам подсчета полноты покрытия гораздо проще добиться 100%, чем по другим. Но это не значит, что нужно делать так, как проще.
Тесты нужны не для того, чтобы добиться 100%, а для того, чтобы они когда-нибудь правильно упали. Потому что уметь правильно падать – это самое главное. Если это верно для каратистов и велосипедистов, значит и для программистов тоже. Лучше правильно упасть плохо крутя педали, чем неправильно упасть хорошо крутя педали.
Считается, что главной метрикой качества тестов является покрытие. В разработческих интернетах часто можно встретить формулировки в стиле “полное покрытие”. Как правило, под полным покрытием понимается некий абсолют в 100.00%.
Процент покрытия – цифра сомнительная, ровно настолько же сомнительная, как и “средняя температура по больнице”. Процент покрытия по проекту – это среднее покрытие его частей. То есть: Модуль-1 имеет покрытие 90%, Модуль-2 имеет покрытие 10%, в среднем покрытие будет равно 50%, если допустить что модули примерно равны по содержимому.
