PPAhithereМожно же сделать фоновое задание, которое будет из САПа коннектиться в другую БД и переливать туда данные.

у вас есть пример такого решения на абапе?
наши консультатнты утверждают, что во внешний оракл писать нельзя - юзайте выгрузку в эксель или рисуйте интерфейс в SAP PI с кнопочкой - "передать справочник наружу"

еще попутно вопрос - правда, что в сапе нельзя перехватить событие изменения таблицы(нет триггеров) и для обеспечения реплики справочников во внешней системе прийдется переодически переливать все данные?
Насчет первого: Зачем обязательно на ABAP-е, таблицы SAP в Oracle (схема SAPSR3) созданы как обычные таблицы - можете обычным PL SQL- ем читать и писать в другую базу без проблем. Создайте хранимки, поставьте их на расписание в Oracle и все. По полномочиям все правильно нужно делать все Oracl-вым пользователем имеющим только права на чтение.
Если полноценную репликацию (с отслеживание изменений, а не полным сравнением и заливкой разницы) хотите организовывать, то тогда нужно конечно искать за что зацепиться - у меня идей на этот счет нет.

Насчет второго: Вся логика по изменению таблиц в SAP-е реализована на сервере приложения, СУБД используется только для хранения данных, так что на тригеррах БД ничего не отписано. В других многоплатформенных ERP видимо тот же подход, по крайней мере в Oracle JD Edwards EO это тоже так.
Вот в Oracle E-Business Suite много из логики на БД Oracle реализовано, но она и одноплатформенная (только на СУБД Oracle можно ставить)

Насчет идеи с материализованной вьюхой не понял - создать с с SAP-овских таблиц репликационные материализованные вьюхи хотите или просто формировать их PL SQL кодом? Пересоздать SAP-ские таблицы для организации стандартной Oracle репликации на основе материализованных вьюх IMHO не получится, потому как таблицы создаются при инсталяции и если создавать новую таблицу в SAP-е, то ее нужно из SAP-а создавать а SAP уже создаст в СУБД таблицу. Тем более на SAP-вские таблицы в метаданных на сервере приложения уже много что подвешано - проверки, умолчания и т.п.

PPAImpConsНасчет идеи с материализованной вьюхой не понял - создать с с SAP-овских таблиц репликационные материализованные вьюхи хотите или просто формировать их PL SQL кодом? Пересоздать SAP-ские таблицы для организации стандартной Oracle репликации на основе материализованных вьюх IMHO не получится, потому как таблицы создаются при инсталяции и если создавать новую таблицу в SAP-е, то ее нужно из SAP-а создавать а SAP уже создаст в СУБД таблицу. Тем более на SAP-вские таблицы в метаданных на сервере приложения уже много что подвешано - проверки, умолчания и т.п.

не совсем понял почему не получится...

...

Можно сделать и FAST REFRESH (с перекачкой только измененных данных)
но в этом случае на стороне SAP-Oracle придется создавать materialized view log
а это уже объект базы данных который, вероятно, нельзя создавать на продуктиве по лицензионным причинам

Я вам и писал про перекачку только изменений. Но я знал только про вариант с созданием стандартной Oracle репликации основанной на материализованных вьюхах (снапшот репликации, если в названии что то не путаю).
Насчет FAST REFRESH с зайдествоанием materialized view log, не знаю технологии, насчет лицензии наверно да, т.к. лицензии на СУБД под SAP насколько слышал распространяются только на цели SAP, если используете функции не касающиеся SAP-а, то можете уже за рамки лицензионого соглашения выйти.

хотя счас повспоминал про оракловую репликацию (на той версии которой я еще работал - 8i) на снапшотовской репликации (с помощью материализованных вьюх), можно было только каждый раз полностью все перезакачивать, а перекачивать только изменения можно было только advanced репликацией (сохранение всех транзакций на источнике и накат на приемнике).
Вот и подумал что использование функции подобно упомянутой Вами (FAST REFRESH для материализованных вьюх) используется в снапшот репликации новых версий и Вы имеете в виду уже ее.

Насчет перекачки всех данных каждый раз, Вам уже написал Proforg, - при больших объемах данных это явно не самый оптимальный способ. Если данных ожидается много, то можно или даже нужно подумать о более продуманом варианте XI/PI или о IDOC и т.п.

РеалистtadminPPAмне базис сказал, что в SAP базу вообще ходить нельзя - саперы переодически мониторят ее и если узнают - накажут...очень похоже на развод :)
Неужели это правда?
Про мониторинг я не верю, смешно. Скорее всего писать напрямую запрещается.
А что в лицензионном соглашении написано?
А причем тут лицензионное соглашение? Разве Вам мало здравого смысла?
Тем более, что SAP реализует транзакции средствами APP сервера, а не с помощью БД.
Читать из СУБД на которой базируется SAP разрешено по любому - базис во всех ERP системах будет противится созданию пользователей работающих напрямую с БД, но на создание пользователя(лей) СУБД только читающих стандартные таблицы базис почти всегда можно убедить, если это в самом деле необходимо в связи с каким то интеграционными или аналитическими аспектами.
Насчет записи в таблицы СУБД на которых базированы стандартные таблицы SAP, вот тут я бы опасался не из-за каких то нарушений лицензионых соглашений, а из-за возможности нарушить ссылочную целостность данных (integrity).
В SAP-е есть довольно удобный инструмент загруки пакетных данных LSMW - вы можете записать последовательность проводимых действий при записи одного элемента при работе в интерактивном режиме (в программе SAP-а - транзакции), затем подготовить, например в Excel, кучу записей и с помощью записанного LSMW загрузить подготовелнные данные не боясь нарушения ссылочной целостности, т.к. SAP будет загружать эти данные как если бы Вы забивали их в интерактивном режиме вручную - т.е. со всей бизнес логикой заложенной для загружаемых данных в системе. Я бы лучше использовал его чем пытался грузить данные напрямую.
Писать напрямую не запрещается, SAP контролирует только изменение объектов (таблиц, программ и т.п.) когда пытаешься менять стандартный объект ситстема просит ключ на изменение объекта, который ты можешь получить сгенерив его на SAP сайте поддержки. Понятное дело что SAP будет знать что данный стандартный объект Вы может изменили и при вопросах связанных с проведением поддержки будет это учитывать. Насчет накажут - не понятно как, а раз не понятно, то и не понятен сам вопрос :).