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 тоже есть много чего интересного, в том числе и по обсуждаемому здесь вопросу.

Уважаемый aag, попробую прокомментировать некоторые из Ваший ответов и дать ответы на вопросы.
aag
Т.е. дублирование проверок - дабы уменьшить вероятность реджектов и дубирование данных - дабы застраховаться от вылетов в дампы, вы считаете нормальным?

Да, считаю это нормальным и более того, там где это необходимо мы это делаем, потому как если программа по интеграции, которая затягивает данные из плоского файла, например работает в автоматическом режиме, то я не хочу, чтобы что-либо привело к её краху и потом разбирайся что=же там произошло, также я не хочу, чтобы пользователи получали зачастую невразумительные сообщения об ошибках и потом долго и мучительно разбирались, а где-же это у меня в файле в какой такой строке и в каком таком поле ошибка.
aag
И почему где-то в Германии за меня кто-то определил, что корректно, а что не корректно? И что телефон, напр. не может содержать букв? Возможно, для каких-то областей это критично, а мне -наплевать.

Это определяется не в Германии, а зачастую на уровне настроек и правил валидации.
aag
Разве я говорил, что IDOC - быстрые, а бапи-шки медленные? Загрузка ETL Informatica клиента штатными BAPI со скоростью 2-3 клиента в минуту на не самом слабом (16-процессорном) сервере - это как, быстро или медленно? Для меня - неприемлемо медленно. Давайте вспомним, что SAP позиционируется как корпоративная система, которая должна оперировать большими обьемами данных (для тысячи клиентов, как правило, SAP не покупают).

Упоминание ETL Informatica появилось первый раз. Кроме того к своему стыду я не знаю что это за продукт, потому не могу судить о причинах такой медлительности загрузки.

aag
Пробовал. Ткните пальцем, где описано как проверяются адреса по клиенту. Его коммуникации. Где описаны все проверки при загрузке кредитных и депозитных сделок. Да, это то самое описание логики работы функций, о котором пишет СергейТТТ. А если оно неизвестно, что интеграция выполняется методом "тупого тыка". А "знаниях предметной области" и хорошей проработке интеграционной архитектуры можно говорить как раз после того как набиваются шишки на этом тыке.
Ну вот тогда уж ничего не могу сказать - я на самом деле убеждён, что грамотные программист и консультант проработают интеграционную архитектуру прежде чем приступать к реализации.

СергейТТТА6дуллаh,

так какая же скорость - запись в секунду или 2-3 записи в минуту ?

как вы понимаете, производительность определяется не только архитектурой и качеством кода, а еще и множеством других вещей - правильной инсталляцией (кто ставил, как настроил), текущей нагрузкой (что там помимо этой загрузки крутится), настройками СУБД (что там настраивали и зачем), сетевые вещи (полоса пропускания между серверам), третьим ПО (какое-то априори непогрешимое промежуточное ПО ? не верю ;))), мощью железа, наконец..

я не считаю SAP "священной коровой", проблемы с ней есть, но также есть и решения, причем в силу распространенности и пожилого возраста системы, эти проблемы известны, описаны и имеют варианты решения. Т.е. надо, чтобы на эти проблемы смотрели специалисты по системе, с ходу такого класса проблемы решать будет трудно и долго
Абсолютно согласен с СергейТТТ. Прежде чем заявлять, необходимо привести как минимум характеристики серверов и сети, при которых производились замеры производительности.
Например у нас на проекте (в системе разработки) при 4-х процессорах и объёме оперативки 16 Гб (для сервера SAP), сервера БД(Oracle) и SAP - отдельные физически сервера, между серверами - 1Гбит,всё просто летает. Загрузка около 800 записей банков происходит менее чем за минуту. Используются BAPI как для создания основной записи банка, так и для обновления существующей, при этом допринятия решения о том, создавать заново или обновлять ещё происходит проверка на существование записи банка в SAP, так что...

А6дуллаh
Вот, а начальную загрузку в 3 суток хотите увидеть? Загрузите тем же способом 100 тыс. записей.
Уважаемый А6дуллаh.
Для сведения, загрузка 3000 ОЗМ с созданием при этом 6*16 сбытовых ракурсов для каждой основной записи материалов, которая реализована на batch input (сиречь CALL TRANSACTION с режимом обновления L), а не на BAPI, происходит примерно за 3 часа. И что, где собака порылась...?

За сим также прекращаю дискуссию и разводить с любителем трёпа (судя по профилю) разговоры не собираюсь.

Уважаемый aag, отвечу на некоторые Ваши замечания, хоть и обещал больше не участвовать в этом обсуждении:
aag
Alex Kuznetsov
...потому как если программа по интеграции, которая затягивает данные из плоского файла, например работает в автоматическом режиме, то я не хочу, чтобы что-либо привело к её краху и потом разбирайся что=же там произошло, также я не хочу, чтобы пользователи получали зачастую невразумительные сообщения об ошибках и потом долго и мучительно разбирались, а где-же это у меня в файле в какой такой строке и в каком таком поле ошибка.

Вы противоречите сами себе. Сначала вы пишете, что строгие проверки при загрузке данных должны быть, а теперь - по сути, признаете, что интерфейсы SAP для загрузки вас не удовлетворяли. И правила валидации вы настраивали сами вне SAPа и определение что считать корректным, а что нет - тоже оставалось за вами. Совершенно верно, но зачем тогда говорить что там все хорошо сделано, если эта программа по интеграции не настраиваема?

Пожалуйста не передёргивайте контекст и слова. И кроме того где противоречие в моих словах? И когда я говорил о том, что интерфейсы SAP для загрузки меня не удовлетворяли?
Да я признаю, что зачастую SAP выдаёт при работе интеграционных решений сообшения, которые малопонятны обычному пользователю.
aag
Alex Kuznetsov
Ну вот тогда уж ничего не могу сказать - я на самом деле убеждён, что грамотные программист и консультант проработают интеграционную архитектуру прежде чем приступать к реализации.

Вы хотите сказать, что нет таких проблем, с которыми не смогут справится грамотные специалисты. Согласен. Но количество этих проблем вызывает недоумение.


Представляете, у меня тоже иногда это недоумение возникает, тем не менее для простых случаев никаких недоумений нет.

aag
Alex Kuznetsov
Загрузка около 800 записей банков происходит менее чем за минуту. Используются BAPI как для создания основной записи банка, так и для обновления существующей, при этом допринятия решения о том, создавать заново или обновлять ещё происходит проверка на существование записи банка в SAP, так что...

Вообще-то 800 записей - слишком маленькая цифра, чтобы судить. Я правильно понял, что вы используете BAPI_BUPA_CREATE_FROM_DATA ?

Нет, для этого используются BAPI_BANK_CREATE и BAPI_BANK_CHANGE.