aag
Ключевое слово здесь - интеграция. Строгая валидация данных необходима при ручном вводе, в экранных интерфейсах. А при закачке извне, следует понимать что данные могут быть некорректные. Да, это плохо, но такова жизнь - других данных нет. И правила валидации при этом должны быть гибче и мягче.

Да, данные могут быть некорректные, тем не менее задача интеграции не допустить попадания некорректных данных в систему, т.е. организовать проверку на самых ранних подступах данных из другой системы в SAP. Поэтому приходится изощряться и даже до вызова BAPI или ,batch input делать самостоятельную проверку и выдавать вразумительные сообщения, кроме того, для собственной подстраховки ещё и сохраняешь в базу в свои таблицы то, что тебе на вход подали, чтобы потом не говорили, что данные мол, верные, а программы неправильно работают.

aagПри этом стандартные BAPI 1) работают невыносимо медленно - и медленно именно из-за этих огромной кучи этих проверок
Да ну, BAPI говорите медленно... - пример в студию, чем например, обработка вызова BAPI медленней вызова транзакции через CALL TRANSACTION и передачи туда BDCDATA, или создания и процессинга IDOC-а? Могу-ли я Вам напомнить, а может даже и просвятить, что BAPI зачастую вызывают те-же функциональные модули и подпрограммы, что и стандартные программы и транзакции. Соответственно вся валидация данных происходит также. При обработке IDOC-ов то-же самое.

aag 2) перечень этих проверок неизвестен и требования SAP к качесту данных заранее тоже неизвестно. И нигде не описано. А Вы не пробовали открывать документацию к BAPI? Там правда почти всё на английском и немецком, но описано достаточно для того чтобы понять для чего BAPI предназначено и что ожидает на вход. Или языковые проблемы?

А6дуллаhВнезапно, несмотря на то, что "в SAP всё есть", оказалось, что для интеграции он плохо приспособлен. Зияющие дыры, способ закрытия которых - месяцы тупого тыка.

Месяцы тупого тыка, скорее из-за незнания предметной области и плохой проработки архитектуры интеграционного решения.

Для А6дуллаh приведите пожалуйста пример "нормальной" (кроме 1С - дабы флейм не разводить) ERP системы, в которой интеграция с другими делается на раз и без долгого и кропотливого программирования? Ну так, для разнообразия, чтобы не просто SAP хаить, а аргументировано :-)

А6дуллаh
Ну да, ну да...Слышен самонадеянный молодой консультант...

Вы, извините, меня лично знаете чтобы такое утверждать?
Надеюсь, что это было Вами высказано в порыве негодования... могу простить если так.
А6дуллаh
Доки по BAPI - это те, которые в браузере BAPI? Конечно, смотрели. Там комменты по три строки, не более, и правил валидации нет. Не сильно полезней просто коммента в столбце.
А учитывая, что этих BAPI - тысячи, а в каждом из них могут легко быть сотни параметров, я бы еще поискал тех, кто заявит, что что-то "знает" :)

К сожалению это не те доки, а те которые ведутся непосредственно к ФМ.
К примеру вот такие - как в присоединённом файле.

Разработчик, умеющий вдумчиво читать и анализировать информацию сможет разобраться что к чему, прочитав доку к самой BAPI и доку к параметрам.
Кроме того не надо забывать, что зачастую вызов транзакции через batch input может встать колом, просто из-за того, что консультанты либо скрыли какое-то поле, либо сделали его обязательным для ввода и не уведомили об этом разработчика. Поэтому BAPI в данном случае предпочтительней.

ERP'шникAlex Kuznetsov,

В OeBS абсолютное большинство интерфейсов тщательно документировано, API имеют валидацию входных данных, а на сайте поддержки (metalink) можно найти готовые примеры PL/SQL кода почти на все случаи жизни. Если надо - могу дать ссылку на доки по интерфейсам, чтобы можно было оценить.
О, супер - ссылку в студию, правда думаю для простых смертных она будет недоступна, т.к. на metalink-е, а это значит надо быть клиентом Oracle для доступа к информации, для SAP-а кстати эта информация тоже не открытая :-).
А мне интересно, в OeBS что, при работе интерфейсов практически вся логика обработки данных лежит на плечах сервера БД? И это называется API? А чем-же тогда собственно занят OAS во время работы интерфейсов?

ERP'шник
Опять же, лучше обратиться к первоисточнику "Oracle Applications Concepts"
http://download.oracle.com/docs/cd/B40089_10/current/acrobat/120oacg.pdf
Спасибо за ссылку, весьма интересная информация. Вместе с тем, что я нашёл в сём документе, воспользовавшись поиском по словам API и interface:
По API - Workflow API - совсем не то, что нужно в данном контексте, хотя и можно использовать, но это всё равно, что штаны через голову одевать :-), и без программирования и валидации тут ну никак не обойтись - совсем не лёгкий путь.
По слову interface - уже немного больше: UI (User Interface) и всё что рядом с ним мы в расчет не берем :-)
Oracle e-Commerce Gateway. - это прямо почти то, что надо - и настройка входных и выходных форматов файлов и правила валидации и конвертации и интерфейсные файлы,и технология EDI. Всё это используется и в SAP - причем вполне стандартно и отлаженно и также документировано, только вот для общего пользования недоступно (я имею в виду, что не пользователи SAP прямого доступа к более менее подробной информации не имеют).
Oracle Integration Repository - сие есть инструмент, заслуживающий пристального внимания. Действительно интересная вещь - снимаю шляпу.

Бегло прочитав четыре документа которые я указал выше, ну и ещё один (Oracle Order Management Open Interfaces, API, and Electronic Messaging Guide (zipped)), я так понял, что интерфейсные вещи довольно сильно размазаны по разным возможностям и в работе интерфейсов с точки зрения реализации именно бизнес логики участвуют как сервер приложений (ну или конкретней, определённые приложения), так и сервер БД (именно как место где реализована бизнес логика).
Вот и закрадываются в меня "смутные сомнения", что это может оченна сильно влиять как на разработку интеграционных решений, так и на производительность сервера БД и системы в целом.

Кстати у SAP тоже есть достаточное количество интрументов для интеграции с другими системами, взять к примеру репозитарий BAPI(Business Application Programming Interface) , инструмент LSMW (Legacy Systems Migration Workbench), SXDA - Инструментальные средства переноса данных, ALE (Application Link Enabling) EDI(Electronic Document Interchange) и IDOC(Intermediate Documents), Enterprise SOA и WebServices, ну и наконец написание на ABAP своих программ, которые будут реализовывать сложную бизнес логику, при которой за один проход на основании данных из файла создаётся несколько видов различных документов из разных функциональностей, вот только при этом сервер БД занимается только своей работой, а именно хранением данных и предоставлением их серверу приложений.

Вместе с тем возвращаясь к обсуждаемой теме, в OeBS также в процессе интеграции данных производится жесткая валидация перед тем как они будут посланы в обработку.

PS. ERP'шник, спасибо ещё раз за интересные и полезные ссылки, приятно иметь дело с профессионалом, а не просто проходящими мимо людьми. Кстати на Help портале SAP тоже есть много чего интересного, в том числе и по обсуждаемому здесь вопросу.