На новом ABAP-ядре параметры TABLES функциональных модулей стали OBSOLETE.
При этом табличный тип не может быть использован в качестве параметра (import/export) метода бизнес-объекта, т.е. не будет создана полноценная BAPI (останется всего-лишь rfc- функциональным модулем).
Может кто решил для себя этот вопрос - в какой секции передавать таблицы?

либо по-старинке - истользовать TABLES
либо на новый манер - делать бизнес-объекты с использованием ABAP-OO (через классы)

Спасибо за Ваш ответ.
По старинке есть еще один небольшой минус. Например, при генерации web-service поверх BAPI ее табличный (TABLES) параметр RETURN (н-р типа BAPIRET2) доступен также на импорт. Некрасиво.
Насчет нового подхода, если возможно, напишите немного подробнее.
Для бизнес-объекта (того, что создается через транзакцию SWO1), в качестве метода могу выбрать лишь функцию, API и пр., но но не метод класса (SE24). Возможно речь идет о чем-то другом?

Спорный момент - TABLES по определению является изменяемым параметром. К тому-же ведь никто не запрещает _накапливать_ сообщения из ряда последовательно вызываемых BAPI
Нет, речь именно о SWO1

Кстати, а что это за ядро и в чём проявляется OBSOLETE?
Просто сейчас ещё раз просмотрел справку - TABLES объявлены устаревшыми только для perform

Для CF подобных примечаний не наблюдается.

Идея как раз, похоже, обратная у SAPа - отделить мух от котлет, т.е. разделить входные и выходные табличные параметры BAPI.
Но у меня затык в использовании табличных типов именно в параметрах методов БО (объявленных в секциях BAPI import/export; при имплементации API-функции в БО).
Возможно, я что-то недосмотрел. Если кто подскажет, буду признателен.

Во-первых, идет warning при сохранении BAPI, во-вторых, вот цитата из SAP документа "Programming Guidelines in ..." - "Function modules. Guidelines. Don’t use TABLE parameters in functions-interfaces (there are none in methods). Use ‘ ‘Importing’, ‘Exporting’ parameters in function modules instead."
Версия ABAP-ядра сейчас 7.0