Стоит задача внедрить обмен SAP с десятком унаследованных АРМ (MS SQL + VB .Net; Clipper).

Сейчас рассматриваются два варианта (За XI надо платить, поэтому мне запретили про него думать):
1. Сделать некий ABAP-прокси, пихать IDOC в него, а он будет переправлять данные во внешнюю БД Oracle. "Обменная" такая БД. А внешние программы будут эти данные с утра грузить к себе. Ну и обратно в том же духе.

2. Классика. Выгружаем IDOC-файл в директорию сервера. А АРМ-ы уже сами с горем пополам дешифруют эти данные и так же шифруют в него свои выгрузки.

Какие плюсы и минусы у каждого варианта? Что и почему выбрали бы вы?

Я бы ничего не выбрал. Взял бы нормальный инструмент(Delphi или C какой-нибудь) написал RFC сервер и все бы распихивал куда надо, в on-line, без всяких расшифровок. Напрямую.

На языке выского уровня, типа Ruby, Python или Perl, это намного быстрее и проще.


Для передачи IDOC'ов во внешние системы, не способные полноценно его обработать и вернуть статус, SAP рекомендует писать скрипты. Поднять RFC-сервер, с точки зрения производительности, конечно, лучше. Но вызов скрипта, по сравнению с тем, что творит с IDOC'ами SAP, занимает бесконечно мало времени.

А можно про скрипты подробнее? Я не совсем уловил мысль.

http://help.sap.com/saphelp_47x200/help ... ameset.htm

Я так понял, что Вы хотите выгружать IDOC'и в файлы:
http://help.sap.com/saphelp_47x200/help ... ameset.htm[/quote]

Бывает, что передаётся по 100 000 IDOC'ов в сутки. Вот тогда, конечно, стоит задуматься о написании RFC-сервера на Perl или Ruby

А зачем они вообще нужны, эти IDOC? Надо синхронизировать данные. Делаешь select во внутреннюю таблицу. Передаешь ее RFC-серваку. Он распихивает эти данные в другую систему, получает данные и отдает их обратно в SAP. Никакого распарсивания. Никакого геморроя с дешифрацией IDOC-ов.

НА Delphi RFC-сервер пишется за 15 минут. А может и того меньше. Насчет простоты тоже сомневаюсь. Хотя, каждому свое. Кому-то на ассемблере будет проще написать.

Ну да.
И геморрой с обработкой ошибок, если в SAP что-то вернуть надо.
А для IDOC BD87 есть для этих целей.
Лучше подробнее про механизм EDI прочитайте.

На Перл и Ruby он уже написан Спасибо Piers Harding.

даа, жалко, что нету у вас XI задача классическая для него. а как вы будете IDOC в Oracle-MSSQL переводить? я бы второй сценарий быбрал, и скриптами бы на уровни BS обходился. а можно данные в XML запарсить. RFC хорошая вещь, но ругается, если много данных...

А много это сколько? У меня мегабайты на ура проходят. Я имею ввиду размер одной передаваемой таблицы. Синронизация SAPа с Oracle и MSSQL на основе RFC крутится уже не первый год. Ни разу на ограничение не нарывались. Хотя поверь базы у нас очень не маленькие.

все дороги ведут как известно в рим, и их не мало. каждая фирма имеет свои особенности. конечно, если рфц-канал стоит и накатан, то вы им и пользуйтесь. я помню, в одной фирме (20000 персонал, 20 стран представительства) главный по базису в концерне персонально наблюдал за каждой RFC-связъю - шпионаж. по-этому у них все всегда надо было с UC 4 делать(то есть файлы). меня всегда в RFC нервировали тайм аутс связи. потому что если RFC без ограничений открыта, это дырка, может много стоить.но ето что касается R/3, с .XI я мало знаком

Глупости. Все саповские сервера, включая XI, MI и Solution Manager общаются друг с другом по RFC.

RFC - это всего лишь протокол обмена данными над tcp/ip. Так что нет проблем его зашифровать.

dito