Задача: обновлять данные в таблицах удаленного MS SQL по данным из SAP HCM.

Проблема в том, что на стороне получателя есть автоинкрементные первичные ключи в таблицах.
Для выгрузки иерархического справочника после каждой вставки в таблицу нам нужно знать присвоенный id записи для построения иерархии внутри таблицы по первичному ключу этой таблицы (колонки id и parent_id).
Плюс к этому в таблицах MS SQL есть внешние ключи, поэтому чтобы что-то туда записать, нужно знать id определенных записей других MS SQL-таблиц.

Для реализации выгрузки нужен такой доступ к базе MS SQL, чтобы к таблицам были возможны select, insert, update и delete из ABAP,
т.к. необходима будет вставка новых записей, обновление уже существующих и удаление неактуальных.

ОС сервера приложений SAP: SUSE Linux Enterprise Server 12.1 ( LINUX_X86_64 )

Идеальный вариант был бы установить на сервер приложений SAP библиотеку dbmssslib.so согласно ноте 1644499 - Database connectivity from Linux to SQL Server ( https://launchpad.support.sap.com/#/notes/1644499 )
Тогда можно было бы всё прекрасно настроить через транзакцию DBCO и реализовать в ABAP через EXEC SQL.

Но базисник ни в какую не хочет ставить на продуктивный SAP сервер пакеты из репозитария packages-microsoft-com-prod.

Я вижу, что ранее этой библиотеки в принципе не существовало для Linux.
Как тогда решить эту задачу?

А у вас в SAP HСМ какая база ?

БД HCM на Хане
HDB 1.00.122.18.1531375173

Ну, если базисник такой упертый, эскулируйте вопрос на руководство.

Как вариант для уменьшения рисков: развертка отдельного сервера приложений с нужными библиотеками для доступа к внешней БД MS SQL (раньше, бывало, под имеющуюся на сервере версию Linux вообще не было нужных библиотек для доступа к MS SQL, так ставили под эту задачу сервер приложений на Windows).

Да уже эскалировал...
Приняли решение выгружать из SAP в csv.
Автоинкрементным ключам в выгрузке ставить 0 + добавить в конец файла поля, по которым можно будет найти в базе-получателя id строки.

Потом загружать этот csv-файл в Talend ESB и java-кодом уже запихивать данные в удаленную MS SQL.

Но мне это решение не нравится, если честно, в плане дальнейшей поддержки интеграции.

Господа. Зачем такие сложности. В наше время запустить виртуалку и запустить там sap gateway - минут 20. Потом пишется rfc. А в rfc уже делаешь все что ты хочешь. Все в on-line. Прямая связь сапа и внешней субд. Неважно какой.

Serge69, а можно поподробнее для тех, кто не в курсе?
Что именно будет крутиться на виртуалке?
sap gateway - это отдельное ПО или часть ABAP сервера приложений SAP?

Как sap gateway поможет топикстартеру приконектиться к внешней СУБД MS SQL?

Sap gateway - это часть сервера приложений. Инсталяшку можно взять у базисников. Либо попробовать скачать виндовозовскую версию. Rfc - это прога написаная на С или delphi, php и т.д. можно погуглить на тему sap rfc. Там даже красивые картинки есть обьясняющие как работает sap rfc. И описание api в гугле тоже есть. На виртуалке будут 2 проги - gwrd.exe и ваш rfc

Serge69, теперь понятно.

Ваша идея включает разработку прокси-програмки на отдельном языке программирования ( С или delphi, php и т.д.), которая с одной стороны будет реализовывать RFC-интерфейс для SAP, а с другой - уметь обращаться в БД MS SQL и крутиться на отдельной виртуальной машине с sap gateway.

Уверен, так можно сделать, но что-то это не кажется простым, быстрым и архитектурно-правильным решением.

Была у нас такая на C написанная.. 2-3 раза каждый месяц по звонку ночью я просыпался чтобы ее перезапустить.
А подобный коннект через DBCO годами работает без проблем, правда в oracle льет.