Я могу аргументировать только собственным опытом - перечисленные мной продукты, так или иначе связанные с java, уже сейчас пользуются достаточно большой популярностью, а специалисты имеют достаточно предложений, чтобы выбирать.

Что касается теток в бухгалтерии - обычно они не сталкиваются непосредственно с этими технологиями. Слава богу, им не нужно вникать, скажем, каким образом данные из 1С попадают в MDM, а оттуда в R/3. Но, конечно, использование подобных продуктов подразумевает и довольно масштабные проекты. Что можно считать и плюсом.

ога пару десятков миллионов java прогеров из Индии жадно облизнулись предвосхищая колоссальные доходы всего лишь 50 баксов в день.... бугага

не согласен с безоблачными перспективами джаверов в сапе. То что абап умрет слышу уже 5 лет и все что-то никак - даже наоборот. А с выходом вэб динпро абап - вообще теперь клепать портальные приложения можно очень даже просто - если не хватает функционала джавовского - оборачиваешь вэб сервис в абап прокси и работаешь.
Вэб динпро компонент интегрируется в гайдед процедуры - и там все равно на чем он написан на абапе или на джаве. К тому же один большой минус джавера в сап - тот что функционал написан на абап - и джаверу в любом случае нужен абапер - а обратное не верно.

ABAP хорош для SAP GUI (потому что другого ничего нет). Для EP писать,
на ABAP это совсем не есть гуд, да и людей с подобной квалификацией на рынке маловато.
Если говорить честно, то SAP уже много лет назад выпустил технологию, позволяющую создавать Web приложения на ABAP: BSP, но, к сожалению, она так и не прижилась.

в квалификации потеряешь - точно в Сапе не нужно писать серьезных
проэктов, а чем J2EE плохо ?

Это на счет что есть гуд а что нет - примерчик:

SAP Webdynpro consultant, Webdynpro consultant.

My client is of Australia's fastest growing consultancies have a position for a SAP Webdynpro consultant. the successful candidate will have at least three years experience using Webdynpro with either Java or ABAP (ABAP preferred). You will need experience in EP 6.0 or 7.0 and Netweaver along with excellent development skills in Webdynpro.

Кто вам сказал, что BSP не прижилась? И BSP прижилась, а ITS так и вообще, так сказать, рулит... И Webdynpro на ABAP будет жить долго и счастливо. Просто вы в силу своей сферы деятельности деятельности с этим пока так широко не встречались. А что до JAVA, я вообще заметил, что к JAVA в SAP склоняются больше люди с техническим складом ума, т.н. кодеры. К сожалению для SAP это не всегда подходит, т.к. самое сложное и интересное в нем - логика (спросите любого спеца по Workflow или BW), и клиента, в общем-то не особо интересует, на каком языке это будет реализовано, главное, чтобы бизнес-логика работала. А вот логику на Java реализовать - вот это уже не есть гуд, т.к. сделаете вы всего лишь обертку над ABAP.

У нас, к сожалению, не Австралия по-этому чувака с "three years experience using Webdynpro with ABAP (ABAP preferred"
не за космические деньги придется искать бесконечно долго.

А никто и не пробует... Я по специальности в России вообще работу найти не смог (SAP SRM) - ну нету у нас этого пока...

а у нас уже в институтах такая специальность появилась?)))

По большому секрету
В наши дедовские времена это называлось логистикой И была она на любом экономфаке... От переименования 60-летние деды по-другому читать не станут.

1 не согласен что значит кодеры ?( кодеры как раз на абапе пишут потому что програмиские знания не нужны)

2 логику можно точно также писать на жаве язык намного богаче и поддерживать программы легче

любая логика это сначала выбор данных из нескольких таблиц и потом из обработать (быстрей всего из взять напрямую подключившиь к БД )
Я писал такие приложения, про убогость АБАП ОО говорить нет смысла

Не могу согласиться... Я работаю в проекте с Индийскими коллегами, у которых очень хороший опыт в яве, они очень хорошие программисты (как оказалось в той же яве). Именно поэтому им доверили разработку для SRM-проекта на 25000 (двадцать пять ТЫСЯЧ) пользователей. Последствия были более чем печальны, ибо высококлассные программисты делали бизнес-логику на JavaScript (разработка для SRM связана с программированием Web Service), на ABAP (на котором по вашим высказываниям программистские знания не нужны, они не смогли этого реализовать, т.к. не знали бизнес-логики). После вашего поста у меня сложилось впечатление, что вы не работали с OO ABAP, либо работали с очень ограниченным количеством задач.

Простите, но я никогда не поверю, что для бизнес-логики ява в контексте бизнес-приложений намного-лучше. А ну-ка приведите пример кода на Java чтения из таблицы базы данных во внутреннюю память приложения.

на ABAP это выглядит так (причем независимо от базы данных, это про легкость поддержки)



Что касается до выборки из таблиц и ущербность OO ABAP (если уж до работы с базой данных через классы), скажите, а что вы знаете о Persistent-Классах в ABAP?

А уж после фразы про то, что тут уже появляются сомнения даже про вашу разработку на Java. Тут как-то про объектность даже и говорить не приходится. В бизнес логике, по крайней мере в тех проектах, в которых я работал, с выборкой из табличек вообще не заморачиваются, очень часто работаю через Business Objects и Classes. Из табличек выбирают только если есть ограничения по времени разработки, и нет времени организовать доступ к данным. Потому что правильно организованная бизнес-логика дает гораздо больший прирост в производительности, чем вопрос выборки из таблиц напрямую или через драйвер.

А у меня сомнения в ваших познаниях в области программинга ,
доступ данных не может быть без драйвера , вот пользовать layer
или писать SQL напрямую это вопрос не такой однозначный

приведите пример серьезной задачи для которой ява не подходит

Сомневаться - это всегда очень хорошо.
Я думаю, что правильно поняли мою мысль, несмотря на цепляние к словам. К сожадению вы так и не привели пример доступа к таблице базы данных, ну да ладно.
Давайте сформулируем вопрос по-другому (дабы не устраивать идеологических споров по поводу того, какой язык лучше). Приведите пример из области Бизнес-Логики в приложениях SAP, для которого использование Java было бы удобнее, чем ABAP.