Добрый день.

Кто-нибудь владеет информацией об алгоритме компрессии/декомпрессии тела лога?

Что мне удалось выяснить:
На основании статьи https://help.sap.com/viewer/6b94445c94a ... ec318.html
понятно, что логи сжимаются с использованием алгоритма сжатия LZ4 - Огонь, отличный алгоритм.
Однако, каким именно образом формируется контент для Encode() - так и не понял, различные варианты подбора алгоритмов ничего не дали.
Мне необходимо выполнить Decode() лога, для этого надо понять, что подается на Encode().
Декомпрессия происходит вызовом системной функции, насколько я понял

поэтому, не нашел способа просмотреть её.
Может быть, кто-то уже решал подобную задачу?

UPD: алгоритм сжатия EXPORT и распаковки IMPORT интересует в применении к BALDAT-CLUSTD

А чем Import не подходит, цель то какая?

BALDAT кластерная таблица.
Как и с другими подобными обращение только через iMPORT/EXPORT

Анализатор логов подключить.
Логика анализатора реализована не в SAP.
по-сути, необходимо распаковать тело сообщения, хранящееся в BALDAT

из ABAP - да.
А при считывании LRAW-значения из БД непосредственно... не ABAP-кодом - IMPORT/EXPORT не доступен.
хотяяя, можно FM написать и дергать по RFC... но это значительно медленнее, чем с ханы на прямую

На уровне БД невозможно считать эти данные.

Ну я же считал. Они лишь сжаты. Их можно распаковать и отобразить.
На сколько я понял, перед полем с RAW-данными идет длина (в распакованном виде), что необходимо для распаковки по алгоритму LZ4.
Простейшая структура для распаковки:

Вопрос, только, какая логика распаковки используется в IMPORT:
1) конкатенируются hexstr (LRAW) и распаковываются
2) или же по отдельности распаковываются блоками до 512 байт
На деле перепробовал много различных последовательностей трансформации HEXSTR и распаковки, но пока результат - отрицательный

Пример:
Этот кусок HEXSTR должен в распакованном виде превратиться в 512 байт текста

SAP не раскрывает как lraw хранятся и прямых способов не существует.
Кроме Import/Export есть еще способ реплицировать через SLT

Делал я подобную ерунду. Но я восстанавливал утерянный ABAP-код из технического журнала самой БД, то есть просто текст. В Вашем же случае мало распаковать, нужно ещё потом разобрать структуру данных самого журнала. В общем случае в кластере могут сохраняться любые данные любой структуры, и не плоские тоже. Прочитать эти данные можно только в точно такую же структуру известную заранее. В самом кластере информация об этой структуре сохраняется только частично. Ну, и если надеяться, что алгоритм упаковки в кластере такой же, как в таблице ABAP-кода (REPOSRC), то можете попробовать. По ссылке исходный код на C++.

p.s.
Ещё один нюанс. На тот момент, когда я это делал (2014), автор кода даже не догадывался о существовании юникода (что было понятно из его комментариев), поэтому половину данных просто игнорировал. Возможно с тех пор это уже исправлено.

https://www.daniel-berlin.de/devel/sap- ... urce-code/

Благодарю за наводку, коллега!

upd: Всё так и есть. Разобрался. Спасибо. Выработал для себя подход к чтению из кластерных таблиц.
Решение: распаковка и чтение структуры, а не текста.
Система использование SAPом "кластерных" таблиц теперь понятна.

Для тех, кто интересуется данной темой:
Рекомендую изучить примеры программ: SBAL_DEMO_*
или же запустить транзакцию sgl1, повесить точку останова на import from и в отладчике изучить принцип действия.
Сама сериализация и компрессия осуществляется функциями ядра SAP и в открытом виде исходников не найти (как я понял). Но для чисто ABAP-программистов это и не требуется.