Два способа выгрузить файл

Без предисловий, сразу код в начальной итерации:

А теперь можно его покритиковать. (далее…)

Как варить компот

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

Вот для примера типичный код из события OpenFI BTE 1120 (замещения перед сохранением бухгалтерской проводки):
User-exit source sample
Вот такой компот, бывает что и на тысячи строк тянется эта простыня.

Почему так получается? Это скорее следствие скупости, лени, спешки плюс недостаток фантазии.

Работать – работает, больших проблем не доставляет. Открыл – всё видно. Можно даже копипастить подходы, использовать общие переменные.

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

Хорошая идея – категорический запрет на решение разных задач в рамках  одного ABAP фрагмента (инклюда, функции, метода). Совсем уж общего решения предложить нельзя, так как есть нюансы, да и многое дело вкуса.

Приступим к первой итерации.

(далее…)

Всё под контролем – очередь транспортных запросов

Есть у меня один повод для переживаний – это запросы, которые не доехали до продакшена.

Они всё время норовят где-то затеряться и забыться.

Я-то сделал, отдал в тест. А дальше дело ответственного консультанта, мяч уже на его стороне. 

Дано:

  • Проект поддержки системы ERP
  • Обычный ландшафт DEV-QAS-PRD
  • Сторонняя система управления задачами
  • Куча мелких задач на доработку

При этом стоит в обязательном порядке связывать создаваемый запрос с задачей/инцидентом.

Раз-два и вот прототип маленькой помогалки готов:

Обзор транспортных запросов

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

Всё понятно – один сложный запрос ещё варится, два запроса уехали в прод, четвёртый на тесте.

Как же я люблю когда много зеленых галочек. Успокаивает. Что ещё нужно?

А некоторые солидные господа используют для этого Solution Manager ChaRM. Но, мне почему-то кажется, что там не будет такой кучи зеленых галочек. Это фатальный недостаток.

Важные слова не важны

В процессе написания кода по заданной спецификации неожижанно обнаружил для себя, что ключевые слова ABAP не являюся зарезервированными.
Поэтому нижеследующий код компилируется и даже выполняется:

Даже если так писать и можно, то этого делать всё-таки не следует:

  • Усложняет восприятие, хотя есть и подсветка кода и uppercase/lowercase
  • Name-conventions
  • Ограничения при работе с БД
  • Это не смешно

Зато есть служебная таблица TRESE, в которой перечисляются разные наименования полей, которые нельзя создавать из-за ограниченний в разных БД.

Some thoughts about services

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.

EU_INIT job

1 500 000 seconds is equal to 416 hours!

Let’s look at the job log:

EU_INIT 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.

Error handling when calling other system using RFC

Preparation

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.

(далее…)

Пасьянсы и установка SAP ERP

Установка SAP ERP — процесс местами странный и трудоёмкий.

Первое.

Установка требует отдельной и жирной машины. Даже если это будет тестовая машина с минимумом данных для пары пользователей.

Для текущей стандартной версии мне понадобилась VM 12GB RAM/300GB HDD/вменяемый CPU.  И очень желательно, чтобы там ничего кроме сабжа не стояло и не планировалось.  Платформа SAP HANA имеет более высокие требования, непомерные для меня, хотя посмотреть бы хотелось. (далее…)

Как побороть WSAECONNRESET: Connection reset by peer в SAP GUI

На некоторых видах прямых соединений из дома на нужные мне сервера NetWeaver я часто сталкиваюсь с ошибкой:

WSAECONNRESET: Connection reset by peer

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

Кто виноват и что делать? (далее…)

В погоне за большой кнопкой

«Самый лучший гуй — одна большая кнопка
в центре экрана с надписью «Сделай мне хорошо!»
(с) Опытный дизайнер

«Самый лучший гуй — одна большая надпись
в центре экрана «Тебе уже хорошо!»
(с) Опытный программист

Цитата #437964
Неудобства: При работе с программой
приходится нажимать на различные кнопки
(с) bash.org.ru

 

В идеале каждая система должна стремиться к минимизации своего интерфейса.

В качестве плохого примера в системе SAP ERP можно вспомнить транзакцию проводки амортизации AFAB:

Стандартный экран проводки амортизации

Первый экран выглядит очень типично для SAP ERP, поэтому и проблемы у этого экрана старые идеологические:

1. Первый экран (экран выбора) не даёт никакой информации о текущем состоянии

2. Все проверки происходят после заполнения всех параметров и запуска процесса

3. Объем задачи большой, заранее не просчитывается, поэтому установлено простое ограничение на тестовый прогон – 1000 записей

4. Формирование фонового задания и отслеживание его статуса – не самая простая пользовательская операция: пять кликов на запуск, пять кликов на просмотр, причём через непростые малознакомые экраны.

5. Нет никакой отчётливой сигнализации об ошибках расчёта

 

Я просто удивляюсь, почему за последние десять лет никто так и не решился переписать междумордие этой важной задачи.

BTW: Вполне вероятно, что в “Пульте управления закрытием” это и сделано, вот только это тема совсем другого разговора.

Приступим?

(далее…)