Вполне бытовая задача при разработке ERP-системы — настройка оповещений посредством электронной почты.

Соответственно сразу возникает несколько идей, куда ложить текст шаблона:

• непосредственно в тексте программы, хардкод никто не отменял
• в хранилищах  OAOR/SMW0 — по обстоятельстам
• в текстах SO10, если они довольно простые и/или ведутся прямо в продуктивной системе

… хотя можно встретить и более экзотические варианты.

Задача может стать чуть более изощренной, если потребуется в письмо добавить красоты в виде HTML. В первом приближении HTML — это простой текст со специальной разметкой в виде тегов. Поэтому можно не отказываться от старых вариантов и мириться с неудобствами в виде редактирования plain-text и отсутствия проверок.

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

• дополнительно нагружать текстовый шаблон особой разметкой и реализовать её обработку на ABAP, что не технологично
• искать альтернативные технологии

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

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

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

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

Дано:

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

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

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

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

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

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

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

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

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

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

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

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.

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.

(далее…)