LOOP AT itab GROUP BY group

В трансформации удобно использовать конструкцию, если нужно прочитать содержимое в пределах семантической группы.

LOOP AT itab GROUP BY 

( comp_code = result_fields-comp_code

  busentity = result_fields-busentity

  rebuilding = result_fields-rebuilding )

REFERENCE INTO DATA (group_ref).

     LOOP AT group_ref ASSIGNING <result_fields>.

     <...>

     ENDLOOP

ENDLOOP.

Если есть записи:

comp_code busentity rebuilding cha1 cha2

1000            1001       1003          abc   xyz

1000            1001       1003          qwe  rty

1000            1001       1003          asd   dfg

1000            1001       1004          zxc   vbn

1000            1001       1004          yui   opp

То в первом цикле мы упакуем в группу group_ref первые три записи, и пройдемся по ним, 

во втором цикле упакуем следующие две записи и пройдемся по ним.

Формула

В правиле преобразования формулы RIGHT, LEFT работают в два раза быстрее, чем SUBSTRING:

Мелочь, а приятно.

DTP перестал забирать записи

Возникла странная ситуация на BI7.4 on HANA. Запросы загружались в PSA в нулевую таблицу /BIC/B000xxx000. Далее забирались вверх потоком. Через 16 минут они почему-то стали загружаться уже в первую таблицу /BIC/B000xxx001. Дельта DTP их по прежнему забирал, но передавал 0 записей. 

Источник не был изменен за это время. Объем - примерно 40-50 записей.

Исправить удалось так:

1. Откатил все последние запросы из таблицы /BIC/B000xxx001

2. Убрал в DTP оптимизацию под HANA

3. Заново запустил DTP - процесс увидел записи

4. Снова включил оптимизацию под HANA

5. На всякий случай сделал полный откат запросов и загрузил их все. Подхватил из обоих таблиц.

Ошибка при активации DSO

В исходной ERP системе была одна запись из трех миллионов, в котором одно поле было, видимо, null. 

При инициализации дельты эти три миллиона записей из PSA передавались в DSO и активировались там около 3х часов. В итоге на одной записи активация падала со словами что-то вроде "Can'not generate SID for object 'iOBJ' value ''". Соответственно даже зная объект, отловить эту некорректную запись было не возможно. 

Коллега подсказал такой кусок кода в rule routine к этому объекту:

data: lv_char(60) type c.

lv_char = source_fields-iobj(60).

replace all occurrences of regex '[[:cntrl:]]' in lv_char with ''.

result = lv_char.

Что такое '[[:cntrl:]]' мне не понятно, но кривого значения как небывало.