Согласно существующему техпроцессу на FTP оператор ЭДО выкладывал ZIP-архивы. Фоновое задание замечательно все считывает, посредством класса cl_abap_zip разбирает, и дальше как-то обрабатывает заархивированые счета-фактуры, цифровые подписи и т.д. и т.п. Но оператор ЭДО принял решение выкладывать 7z-архивы. Потому встала задача разбора 7z-архива из фонового задания. Поиск подходящих классов, ФМ ничего не дал. Чтение SDN, нот, форумов тоже не сильно не помогло. Собственно прошу помощи для направления дальнейших поисков.
P.S. Ну очень уж не хочется писать свой парсер для 7z наподобии cl_abap_zip.

тут на RAR-то ни джавы ни абапа не найдёшь, не то что 7z.
Только команда операционной системы.

Проблема еще и в том, что 7z может сжимать разными алгоритмами (LZMA, LZMA2, Bzip2, PPMd, DEFLATE) - и их все реализовавать муторно.
Stenj_90, если решение найдется, напиши, плиз. Мне тут похоже светит переписывать cl_abap_zip (правда не очень срочно), если были бы наработки по LZMA2 - очень бы помогло.


Да, это было бы оптимально (как минимум потому, что удалось бы задействовать многопоточность), но не с каждым базисом можно договориться на установку софта за разумное время.

Насколько помню, cl_abap_zip тоже через системную функцию работает.
Реализовывать ZIP на чистом абапе похоже на интерпретатор ассемблера под GW-BASIC.

постановщику надо обосновать, быстро базис нагнут

в принципе, как и всё на абапе, можно через рабочую станцию и "эксель" реализовать, то есть без сервера приложений. Но это надо деплоить 7z на клиента, если его ещё не было, с правами запуска возиться.

сорри за оффтоп, но проблема должна решаться на административном уровне.
Кто деньги платит - ваша организация или оператор ЭДО?

ну, тут может сервак HP-UX администрируется индусами в Цюрихе и 7z туда ставится неочевидно (скажем, не под тот релиз чпукса доступные бинарии созданы) а ЭДО уже вчера надо внедрять. Я бы тогда на RFC библиотеку воткнул для доступа к машине с 7z, может и что другое заодно бы выполняло.