Здравствуйте!
Собственно вопрос в следующем: как сформировать сообщение в виде текстовой строки? Начал ковыряться с jdbc-адаптером и вот налетел. Пока нашел только общие фразы о том, что без java-мэппинга не обойтись. Не подскажете?

можно через xslt, можно через абап, можно джавой. Лишь бы на выходе SQL был.
Но он будет вылазить в AuditLog по-умолчанию (можно через logSQLStatement = false попробовать отключить), а то неудобно когда гигантские простыни забивают аудит на раз.

А как для принимающего интерфейса указать текстовую строку как тип сообщения?

Уже разобрался. XSLT рулит. А вот с результирующим сообщением проблемы возникли. Вроде создал структуру, как описано в документации, а PI на мэппинге ругается. Не подскажете, как правильно создать тип сообщения для resultset?

В результате докопался: взял ответное сообщение, удалил из него непосредственно данные, оставил только описание и подсунул как External Definition. Это правильно?

1) если нет валидации то во время выполнения структура может быть любой
2) для очистки совести можно сделать интерфейс без структуры (dummy interface), у которого нет определения и ссылки на SWCV. Тогда в меппингах валите туда хоть свопы от винды. Правда, по словам Саши Ерина, такие сценарии уже не работают в ICo/AAE, но там можно модулёк воткнуть для контейнеризации.

Если можно, еще вопрос: а как быть в случае сложных запросов? Native SQL рекомендуется использовать только в тестовых целях, а вылепить XML-SQL из запроса с JOIN'ами, UNION'ами, подзапросами и прочими прелестями просто нереально. Рисовать вьюшки в скуле - не всегда есть доступ к разработкам в целевой базе. И что в этом случае делать?

я делал так. Писал анонимный блок:
BEGIN
UPDATE ... ;
IF sy-dbcnt > 0
DELETE ... ;
DELETE ... ;
INSERT .... ;
INSERT .... ;
INSERT .... ;
ENDIF;

PROCEDURE ZZZ(...)
DELETE ...;
UPDATE ...;
ENDPROCEDURE;

ZZZ(123, 456, '222');
ZZZ(123, 456, '222');
ZZZ(123, 456, '222');

END;


То есть сперва в утилите для БД отлаживал код, особо нетривиальные куски оформлял в виде процедур, а потом генерил текст и процедуры (константный обычно) и вызовов процедур (генерируется просто). Также всякие UPSERTы в виде отдельных UPDATE и INSERT DMLов.

рекомендацию про "NativeSQL только для тестов" я не видел.
XMLSQL позволяет джойны писать руками не хуже чем Native (там второй формат у XMLSQL есть, с подстановкой отдельных констант).
А совсем сложные вещи тогда через Кравчиковский адаптер делать, либо ccBPM, либо как уже показал.

Спасибо, очень познавательно
Насчет рекомендации только для тестов - так на sdn.sap.com, по-моему, в хелпе по настройке receiver jdbc и написано

Это ничем не обоснованное суждение и мнение. Часто со старыми БД, к которым новые JDBC-драйвера не подходят (информикс десятилетней давности например), работа вообще непредсказуема: например, в Sender JDBC в запросе из таблицы (select * from tab) имена полей возвращались что-то вроде <rowset>
</FIELD1/>aaaa<//FIELD1/>
</rowset>

То есть вообще невалидный XML. Сценарий загрузки в БД через XMLSQL в ReceiverJDBC работал вроде штатно, но глядя на глюки сендера я бы за работоспособность Native больше поручился.

Я думаю, что в Native просто нечему глючить. Никакой трансляции не делается, все локали можно установить самому (в принципе и в XMLSQL можно тоже, но надо хранимую процедуру написать). Но для тривиальных задач Native конечно не нужен.