Текущее время: Пт, ноя 01 2024, 02:31

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Снова про Enterprise Portal
СообщениеДобавлено: Вт, дек 20 2005, 07:18 
Гость
Доброго всем времени суток!
Снова задаю вопрос про портал саповский: его преимущества и возможности. Кто внедрил, что внедил, отзывы.


Пометить тему как нерешенную
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, дек 22 2005, 11:09 
Менеджер
Менеджер
Аватара пользователя

Зарегистрирован:
Вт, авг 09 2005, 21:20
Сообщения: 538
Вы это просто так спрашиваете? или что то конкретное интересует?
А то вопрос звучит... мол кто видел море? как оно ваабще?


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:   Тема решена
СообщениеДобавлено: Пт, дек 23 2005, 07:13 
Гость
Ну почти как про море, только в ином ракурсе: вот де есть у меня море, в шкафу лежит. Начальству надо представить наиболее красочно, что с этим "морем" делать и чем оно может быть удобным в жизни как нашей компании так и других, которые обслуживаем. В общих словах для себя я уже понимаю что это и счем едят. Даже презентацию им обзорную делала. ИНформацию брола и доки и SAp-овски презентаций. Их это не устроило. Я так понимаю, им конкретики надо: "вот это можно для этого использовать, а это- для этого, а если вы будете использовать вот это, то выгоду и удобство получите вот в этом и этом, а экономия во-о-о!"
На курсы никто меня не пошлет пока.
Поэтому и спрашиваю у всех, кто уже использует портал, что вы используете и чем это удобно в вашей компании и т.п.


Пометить тему как нерешенную
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 23 2005, 16:51 
Гость
багира_я написал(а):
Я так понимаю, им конкретики надо: "вот это можно для этого использовать, а это- для этого, а если вы будете использовать вот это, то выгоду и удобство получите вот в этом и этом, а экономия во-о-о!"
...
Поэтому и спрашиваю у всех, кто уже использует портал, что вы используете и чем это удобно в вашей компании и т.п.


Ну раз ракурс интересует практический и не технический - думаю надо или проектных менеджеров про мотивацию спрашивать. Чего технарей терзать?
С точки зрения ПО - продукт на мой взгляд ОЧЕНЬ сырой.
Как интеграционная платформа различных АСУ - очень еще слабая вещь. С точки зрения сайтостроительства - тоже не ахти. Проще и понятней на ABAP в BSP создать сайт корпоративный (а то и вообще поставить Apache или что-то еще).

Как портал - я скажу так когда выйдет еще релизов пару от текущего 6-го, то наверное можно будет про него говорить что-то. Пока не стабильное ПО, технологически сырое, внедренчески выбивается из общего подхода SAP ко внедрению, опять же Java как основная технология, использованная в портале - не лучшая основа для Web и для Frontend программирования.

А так - спрашивайте подробнее, отвечу.

P.S. А портал (6-й и 5-й) я не люблю. И вообще я не люблю ПО которое стартует 15 минут, работает 5, а потом снова стартует 15 минут.


Пометить тему как нерешенную
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Вс, дек 25 2005, 16:43 
Младший специалист
Младший специалист

Зарегистрирован:
Вт, мар 08 2005, 11:17
Сообщения: 69
Откуда: Россия
Пол: Мужской
Anonymous написал(а):
багира_я написал(а):
Как портал - я скажу так когда выйдет еще релизов пару от текущего 6-го, то наверное можно будет про него говорить что-то. Пока не стабильное ПО, технологически сырое, внедренчески выбивается из общего подхода SAP ко внедрению, опять же Java как основная технология, использованная в портале - не лучшая основа для Web и для Frontend программирования.

А так - спрашивайте подробнее, отвечу.

P.S. А портал (6-й и 5-й) я не люблю. И вообще я не люблю ПО которое стартует 15 минут, работает 5, а потом снова стартует 15 минут.


два года уже как часы (швейцарские) работает, две миграции прошли настолько незаметно, что их как бы и не было.
Про яву как не лучшую основу для веб программирования, товарищ, а что же может быть лучше для веб программирования как не ява, а такие технологии как web dynpro настолько упрощают процесс написания приложений под портал, что bsp даже и не снилось.
Портал это не корпоративный сайт!Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ!Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ!!
и если кому-то надо именно это, то действительно проще и быстрей на apache че-нить повесить.
Портал это средство объединения информации и предоставления ее конечному пользователю. Если в вашей компании 20 человек работает, то действительно смысла в портале нет, а если 20 000 то все преимущества налицо, доживем ли мы до тех пор, когда уборщица себе отпуск будет через портал бронировать не знаю.
Про сырость так это только к России относиться, с большим нежеланием наши компании тратят деньги на инновации, сначала хотят посмотреть, как это у других работает, а уж потом если все хорошо то и сами приобретают.

Стартует действительно мин 20(кластер), а про 5 мин работы это ерунда.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вс, дек 25 2005, 18:29 
Директор
Директор

Зарегистрирован:
Чт, ноя 04 2004, 20:42
Сообщения: 893
Что такое EP можно посмотреть на примере www.sdn.sap.com :) Кстати по-моему, по портальным технологиям SAP в 2003 году была в квадрате лидеров IDC


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, дек 26 2005, 09:10 
Гость
Ракурс интересует и технический тоже.
Интересует в первую очеред, что из преложенного сапом используется. Возможные проблемы.
Интеграция не сап приложений - работает или нет?
Организован ли у вас доступ на портал из вне. Я имею в виду не анонимный, а авторизованный доступ из интернет.


Пометить тему как нерешенную
Вернуться к началу
  
 
 Заголовок сообщения: Кстати...
СообщениеДобавлено: Пн, дек 26 2005, 11:39 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, июн 20 2005, 10:06
Сообщения: 79
Недавно обратил внимание, что в SAPовских презентациях о существующих и грядущих продуктах нет скриншотов SAP GUI. А вот скриншотов Internet Explorer'а с портальным интерфейсом как раз очень много.
Такие дела...

_________________
klim


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 30 2005, 12:05 
Гость
Тут звучали еще и негативные отзывы о портале. Можо причины недовольства. Что плохо и т.п. Конечно интересует и что хорошо.
Еще, насколько получается программы не сап интегрировать с порталом.


Пометить тему как нерешенную
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Сб, янв 07 2006, 21:36 
Гость
Багира_я написал(а):
Тут звучали еще и негативные отзывы о портале. ...
Еще, насколько получается программы не сап интегрировать с порталом.


Вообще в портал по идее можно свести много чего при условии что это "чего" имеет свой Web-интерфейс пользователя. Вот с SSO проблема. Есть на мой взгляд 2 выхода - либо пользоваться решением Михаила Прусова или закупать LISSI (есть такой продуктик) в качестве основы SNC/SSF для портала и PKI компании в целом.
Если у внешнего продукта с Web-интерфейсом туго - тогда берем соответсвующее IDE и пишем, пишем, пишем и интегрируем.

К замечанию выше про J2EE и Java как платформу для Rapid Development - я скажу так: сказка красивая! Никаких оссобенных выгод Java+WebDynpro или VisualComposer не дает без ДОТОШНОЙ организации проекта внедрения/разработки. А похвастаться серьезно проработанной системой управления проектом, высокой степенью документированности решения и пр. пр. пр. большинство компаний не могут. С таким же успехом и трудозатратами возможно построение портала при использовании PHP5/Zend и т.д. Объектный подход в силу раскрученности не подразумевает ТОЛЬКО UML моделирования - надо еще много чего дописать и доделать ручками. Да и производительность с ресурсоемкостью у J2EE просто на двойку. А если еще учесть что SAP по сути ПЕРЕПИСАЛ сановский J2EE и до сих пор у клиента нет нормальных инструментов профилирования, диагностики и управления платформой. На каждый серьезный чих системы - зови спеца из SAP или от партнера. У меня на памяти 6 случаев серьезного отказа SAP J2EE. Вплоть до того что невозможно подключиться Visual Administrator к J2EE инстанции. Выход из строя LogWrite сервиса - ситуация тоже не из лучших... В общем так вот ..
В такой ситуации при попытке использовать SAP EP в качестве основы портала компании можно рассматривать как безрассудный энтузиазм руководства проектом.
Серьезно над Java и J2EE и Sun-у и SAP-у стоит поработать еще лет 5-6 и тогда может они наконец доделают среду, доведут ее до ума. А пока слабовата платформа J2EE.

И как тут справедливо замечалось ранее - внедрение SAP EP по структуре отличается от "классического" внедрения рядовой R/3. Тут не обойдешься 3-х системным ландшафтом с настроенным транспортом и выделенными ключами разработчикам. Тут надо городить огород с инфраструктурой разработки, создавать репозитарии, нет автоматического контроля версий и вообще очень много переносится на внедренцев и разработчиков, вернее предполагается их очень высокий профессиональный уровень: отличное знание SAP ABAP, SAP J2EE, просто J2EE и Java в частности. А еще необходимо чтобы они разбирались в RFC, BAPI и многом другом. И конечно обязательно знание Web-технологий.

Тут впору задуматься над постановкой работ над проектами. Некоторым возможно стоить посмотреть в сторону X-programming концепции при организации работ, аутсорсинг опять же ..


Пометить тему как нерешенную
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 10 2006, 15:12 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Пн, ноя 07 2005, 15:59
Сообщения: 1071
Откуда: Moscow
Пол: Мужской
N2 написал(а):
Вот с SSO проблема.
[...]
К замечанию выше про J2EE и Java как платформу для Rapid Development - я скажу так: сказка красивая! [...] С таким же успехом и трудозатратами возможно построение портала при использовании PHP5/Zend и т.д.
[...]
Серьезно над Java и J2EE и Sun-у и SAP-у стоит поработать еще лет 5-6 и тогда может они наконец доделают среду, доведут ее до ума. А пока слабовата платформа J2EE.
[...]
И как тут справедливо замечалось ранее - внедрение SAP EP по структуре отличается от "классического" внедрения рядовой R/3.

Хотя я не являюсь большим поклонником EP, на такие категоричные утверждения очень хочется возразить.

По поводу SSO. Во-первых, соответствие SAP Logon Tickets российским ГОСТам - это проблема НЕ портала и, тем паче, не Java WAS. Во-вторых, SSO – это просто автоматическое инициирование процесса аутентификации, а не шифрование данных, поэтому не совсем верно связывать его с SNC (шифрование трафика) и SSF (шифрование данных с электронной подписью). Вовсе не обязательно, что в рамках SSO производится аутентификация посредством сертификата. Портал предоставляет инструменты User Mapping, позволяющие регистрировать пользователя приложений различными методами. Если для соответствия работы с портальными приложениями требованиям законодательства недостаточно передачи данных с использованием SSL и ticket/form-based/basic/digest аутентификации, то задача интеграции сертифицированных ФСБ/ФАПСИ алгоритмов встанет в любом случае. Совершенно не важно, какие инструменты построения удаленных интерфейсов используются. Кроме того, надо заметить, такие требования относятся к довольно узкой сфере возможного использования портала предприятия.

Небольшую свинью подложила Microsoft с патчем IE, после установки которого стала невозможной Basic HTTP Authentication через iView типа Application Integrator. Патч, вопреки RFC 2617, запрещает указание параметров авторизации в URL (http://user:password@domain.zone), поэтому приходится искать решение, чтобы на лету изменять заголовок http-запросов. Несложный proxy-сервис на Java пишется за несколько дней.

Теперь про разработку. С чем идет сравнение WebDynpro, мне не удалось понять (не ABAP/4 же рассматривается как образец «платформы для Rapid Development»). Это всего лишь один из API, причем очень высокого уровня. Разному уровню задач соответствуют различные методы решения. Благо, технологии Java (в отличие от PHP, пока ориентированного исключительно на server scriptlets) предоставляют богатый выбор.

К слову, о «слабоватой платформе J2EE». Так называемая «технология J2EE» собственно технологией не является. Это набор различных стандартизированных интерфейсов, по каким-то соображениям не включенных в стандартный пакет разработки. Имплементацией занимаются разработчики базового ПО, к которому относятся EJB серверы и клиенты, Servlet контейнеры, XML сервисы и т.д. Поэтому утверждение, будто бы «SAP по сути ПЕРЕПИСАЛ сановский J2EE» выглядит очень странно. Судя по всему, автор периодически подразумевает под J2EE технологию EJB (опять же, Sun разрабатывает только интерфейсы этой надстройки над RMI). В таком ракурсе тем более странно сравнивать Java и PHP. EJB ориентирована на распределенные трансакции и обеспечивает персистенцию данных. Отсюда и ресурсоемкость с низкой, относительно единого приложения, производительностью. Еще бы – каждый модуль портала является самостоятельным приложением, способным работать в распределенном контексте сессии.

Собственно, разработка приложений под Java WAS практически ничем не отличается от обычного процесса создания приложений для прочих серверов EJB и Servlet-контейнеров (кроме того, что ряд работ выполняются еще проще даже персоналом с невысокой квалификацией за счет специальных средств разработки от SAP). Если для работы приложения используется единый сервер (а даже в рамках кластера часто достаточно обычного load balancing – как на том же SDN, не требующего возможностей EJB) и его масштабирование не планируется, вполне можно обойтись простыми web-modules. SAP следует четким стандартам Sun и разработка не требует никаких особенных знаний.

Чрезвычайно удивило то, что сравнивается внедрение портала (middle tier) и R/3 (business logic). Понятное дело, что разработка продуктов на Java имеет собственную специфику, отработанную, кстати, в течение многих лет. Странно представлять все это как недостаток EP или J2EE в целом. Смею предположить, что масштабы внедрения разработок на основе стандартов J2EE на порядки превосходят внедрения ABAP-систем.

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

Все вышесказанное не является аргументацией в пользу внедрения Enterprise Portal, выбора Java в качестве языка реализации и прочих общих положений. Однако критиковать эти продукты следует все-таки более обосновано.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 10 2006, 16:42 
Гость
korchagin написал:
Хотя я не являюсь большим поклонником EP, на такие категоричные утверждения очень хочется возразить.

По поводу SSO. Во-первых, соответствие SAP Logon Tickets российским ГОСТам - это проблема НЕ портала и, тем паче, не Java WAS.

С утверждением согласен. Однако и у праворульных машин проблем тоже нет, кроме той, что в нашей стране машины леворукие по стандарту.
Я хочу заметить, что разработчик платформы должен адаптировать ее к стандартам страны, в которую он ее поставляет. Я имею в виду SAP, а не Sun в данном случае.
korchagin написал:
Во-вторых, SSO – это просто автоматическое инициирование процесса аутентификации, а не шифрование данных, поэтому не совсем верно связывать его с SNC (шифрование трафика) и SSF (шифрование данных с электронной подписью). Вовсе не обязательно, что в рамках SSO производится аутентификация посредством сертификата. Портал предоставляет инструменты User Mapping, позволяющие регистрировать пользователя приложений различными методами.

Полностью принимаю возражение. Однако давайте разберемся- что SAP предлагает в качестве основы для SSO? - SAPCRYPTOLIB .... Поправьте если я не прав.
По поводу технологии мепинга хочу заметить: технология хороша если она дает на практике выгоду от применения (и не только финансовую). Согласны? Теперь ответьте: нужен портал на 50 пользователей? или компании можно обойтись без него? - Наверное можно без портала .. я так думаю. А вот если в компании 2000 народу должно работать с порталом - а в портал допустим сведено порядка 40 различных АСУ и в среднем пользователь работает с 5-6 АСУ - попробуйте помепить месяцок такое решение - я готов буду подарить Вам веревку и мыло душистое ( не воспримите как оскорбление, но впору будет повесится).
korchagin написал:
Если для соответствия работы с портальными приложениями требованиям законодательства недостаточно передачи данных с использованием SSL и ticket/form-based/basic/digest аутентификации, то задача интеграции сертифицированных ФСБ/ФАПСИ алгоритмов встанет в любом случае. Совершенно не важно, какие инструменты построения удаленных интерфейсов используются. Кроме того, надо заметить, такие требования относятся к довольно узкой сфере возможного использования портала предприятия.

Про ФАПСИ Вы правильно заметили, но дальше тут очень скользкое утверждение по поводу узкой сферы использования. В вашем случае получается что интеграция в портал должна делаться по технологии "пользователь -> портал -> система". Т.е. Пользователь по HTTP(HTTPS) общается с порталом на SAP J2EE, а тот в закрытой зоне по закрытым от пользователя интерфейсам тягает данные и кажет в браузер пользователю. А как же интеграция "пользователь -> inframe(система)"? А такая интеграция используется в большинстве случаев! Статус 302 протокола HTTP никто не отменял ;). А тут как-раз SSO и нужен. Передаете Вы в HTTP заголовке просто куку или SAPLogonTicket неважно! Удаленная система должна идентифицировать вашего пользователя. А что такое SSO для нас? - это или PKI+SAPCRYPTOLIB или UserMapping или своя разработка ( и потом, не дай бог, сертификация в ФАПСИ).
korchagin написал:
Небольшую свинью подложила Microsoft с патчем IE, после установки которого стала невозможной Basic HTTP Authentication через iView типа Application Integrator. Патч, вопреки RFC 2617, запрещает указание параметров авторизации в URL (http://user:password@domain.zone), поэтому приходится искать решение, чтобы на лету изменять заголовок http-запросов. Несложный proxy-сервис на Java пишется за несколько дней.

Rapid Development. Very quick. Скажите пожалуйста - а что еще будет патчить MS в этом году???, а то надо план работ писать, программистам платить, время планировать, выдавать дату релиза и его функциональность.... Мне кажется что тут стоит сделать ремарку: в тени остался факт того что SAP EP "нормально" ( ну если браузер не патчить и рабочую станцию перевести на ручное обновление и с выходом на Windows Update тестировать каждый патч от MS ) работает только с IE. Попробуйте использовать Opera, Mozilla, FireFox и т.д. и вы поймете как иногда весело бывает смотреть в окно браузера. Вот он - несомненный плюс SAP EP. Мы уже повеселились разок с порталом, когда полкомпании могло войти в портал, а половина дальше логон-экрана не могла пройти. И фреймы очень весело отображались. А потом на SAP support нам тихонечко сказали "- ребята, только IE, и только такой. И не будем мы Вам официально это подтверждать, даже не просите. Потому что во всех анонсах у нас все поддерживается, уж Mozilla точно."...
korchagin написал:
Теперь про разработку. С чем идет сравнение WebDynpro, мне не удалось понять (не ABAP/4 же рассматривается как образец «платформы для Rapid Development»). Это всего лишь один из API, причем очень высокого уровня. Разному уровню задач соответствуют различные методы решения. Благо, технологии Java (в отличие от PHP, пока ориентированного исключительно на server scriptlets) предоставляют богатый выбор.

Если сравнивать WebDynpro на Java и WebDynpro (SAP WAS 7.0) на ABAP - я однозначно выбираю ABAP - быстрее, проще, мощнее. Если брать ядра SAP WAS 6.20/6.40 - BSP(MVC)+HTML_Template_Editor_любой+HTMLB практически аналогично по скорости начальной разработки SAP J2EE. А вот когда вопрос переходит в плоскость отладки и поддержки(читай развития Web-приложения) то тут сравнение практически неприемлемо. Все сильно зависит от качества разработки, ее объема и т.д.
Теперь про ABAP - я базисник, не программист, однако ABAP - язык ОЧЕНЬ высокого уровня. И уж выше чем Java :). На ABAP отчеты и диалоги пишутся ОЧЕНЬ быстро. Добавьте огромную библиотеку классов высокого уровня - написать сложный Web-сервис можно в пару строк.
И еще - когда говорят про PHP - почему-то всегда вспоминают его script_based. Предлагаю зайти на http://www.php.net в раздел "Documentation". Дело в том что PHP уже 2-й релиз (4-й и 5-й PHP) во всю объектный. Более того Объектная модель в PHP-5 является частью ядра. Почитайте http://www.zend.com. Полюбопытствуйте на http://pear.php.net. Хотя уверен, что Вы неплохо сами осведомлены об объектности PHP.
А еще:
Можно обратить внимание http://www.zope.org/ .
Можно обратить внимание http://www.perl.org/ .
Дело в том что использование ООП не обосновано при построении портала - и выбор исключительно ООП систем для построения портала НИЧЕМ не обоснован, кроме моды. Я видел прекрасные реализации портала, построенные на PERL.
Также могу и дальше перечислять платформы для построения систем, порталов на базе HTTP протокола (а портал не подразумевает HTTP протокола).. Но надеюсь я Вам ответил: " ..с чем можно сравнивать".
korchagin написал:
К слову, о «слабоватой платформе J2EE». Так называемая «технология J2EE» собственно технологией не является. Это набор различных стандартизированных интерфейсов, по каким-то соображениям не включенных в стандартный пакет разработки. Имплементацией занимаются разработчики базового ПО, к которому относятся EJB серверы и клиенты, Servlet контейнеры, XML сервисы и т.д. Поэтому утверждение, будто бы «SAP по сути ПЕРЕПИСАЛ сановский J2EE» выглядит очень странно.

Согласен, некоректное с моей стороны утверждение. Вы тут более правы.
korchagin написал:
Судя по всему, автор периодически подразумевает под J2EE технологию EJB (опять же, Sun разрабатывает только интерфейсы этой надстройки над RMI). В таком ракурсе тем более странно сравнивать Java и PHP. EJB ориентирована на распределенные трансакции и обеспечивает персистенцию данных. Отсюда и ресурсоемкость с низкой, относительно единого приложения, производительностью. Еще бы – каждый модуль портала является самостоятельным приложением, способным работать в распределенном контексте сессии.

По вопросу некоректности сравнения хочу отметить следующее: PHP имеет PEAR/PECL расширения. И для них не нужно разрабатывать интерфейс. Потому что интерфейсов не много - он просто один. И сравнение я считаю правомерным.
Описывать недостаток системы - ее архитектурой я считаю неверным. Таким методом можно продавать запорожец по цене мерседес 600 и ставить их рядом. А на недоуменные вопросы покупателей отвечать - это такая архитектура. Давайте по модному сравним - на деньги. Если мне при прочих равных условиях для системы на Java надо закупить аппаратуры на 10 млн $, а для тяжелой системы на ABAP нужно закупить аппаратуры на 5 млн $ - как вы думаете какой я выбор сделаю? И не говорите мне про TCO! Я сразу отвечу Вам:
Как я утверждал выше - скорость разработки на ABAP выше или сопоставима со скоростью разработки на Java. Стоимость сопровожнения ABAP сопоставима со стоимостью сопровождения на Java. Временные затраты на модификацию при использовании ABAP ниже чем при использовании Java. ПО на ABAP более стабильно; платформа ABAP более стабильная, более отказоустойчивая.
О чем кричат менеджеры, когда рекламируют Java -> о том что она дешевая. Для меня получается странно!! Однако когда почитаешь разные скуцес сториес - становится понятно почему менеджеры любят Java... Приведу пример, а потом его повторю со своим комментарием (в скобках жирным буду давать свой коментарий):
"... При использовании Java нам удалось сильно съэкономить. Мы оставили 2-х архитекторов, полностью разбирающихся в системе. И сформировали проектную команду из Java кодеров. В короткие сроки кодеры написали систему и полностью ее документировали. Учитывая частичный характер отладки приложения, нам удалось снизить время отладки и выпуска приложения для заказчика....
...
Затраты по сопровождению приложения мы покрыли из доп. соглашения с заказчиком на сопровождение. Для сопровождения мы использовали 2-х разработчиков из проектной команды, которые плотно работали с архитекторами и пользователями" ...

Теперь комментарий:
"... При использовании Java нам удалось сильно съэкономить. Мы оставили 2-х архитекторов, полностью разбирающихся в системе( т.е. разогнали проектную команду которая была и перегрузили пару оставшихся "счастливцев". 1-я экономия за счет жесткой эксплуатации). И сформировали проектную команду из Java кодеров(раз ты "кодер" - значит дешевый! будешь хорошим, добрый дядя сделает тебя архитектором, чтобы ты пахал на меня с утра до ночи. 2-я экономи за счет жадности.). В короткие сроки кодеры написали систему и полностью ее документировали(зачем нам технические писатели? кодеры пишут, пусть и документируют. 3-я экономия за счет жадности.). Учитывая частичный характер отладки приложения(!!! люди пишут - а программа-то сырая, мы ее цуток потестировали, что запускается. 4-я экономия на тестерах и качестве), нам удалось снизить время отладки и выпуска приложения(не удивительно) для заказчика....
...
Затраты по сопровождению приложения мы покрыли из доп. соглашения с заказчиком(гениально! продать машину с заведомым браком, как новую и за сервис брать деньги! по полной! 5-я прибыль) на сопровождение. Для сопровождения мы использовали 2-х разработчиков из проектной команды(а тут и группу кодеров разогнали, оставили самых склоняемых на трудовые будни. 6-я экономия.), которые плотно работали с архитекторами и пользователями" ...

Делайте выводы сами господа. Мне кажется, что делай по человечески продукт на Java - его стоимость зашкалила все что можно. Такими вот сукцес сториями кишит пол интернета.....
korchagin написал:
Собственно, разработка приложений под Java WAS практически ничем не отличается от обычного процесса создания приложений для прочих серверов EJB и Servlet-контейнеров (кроме того, что ряд работ выполняются еще проще даже персоналом с невысокой квалификацией за счет специальных средств разработки от SAP).

Извините, хочу уточнить, вы имеете в виду разработку интерфейса пользователя или разработку логики обработки данных? Если Вы говорите о разработке интерфейса, то я с вами согласен. Средства у SAP хорошие - Eclipse как-никак. Да и VisualComposer неплох для поделок.
А что мешает посадить за "рисование" пользовательского интерфейса для того же BSP новичка? В общем ничего. Дайте ему Macromedia Dreamweaver с загруженной HTMLB библиотекой - вот и все. Нарисует он экраны для любой BSP под ABAP. А можно и без HTMLB нарисовать. Кому что нужно....
А теперь про разработку логики обработки. Скажите - нужна здесь квалификация? или нет? знание объектов? репозитария? проектных решений? стандартов? так какая квалификация тут нужна?

korchagin написал:
Чрезвычайно удивило то, что сравнивается внедрение портала (middle tier) и R/3 (business logic). Понятное дело, что разработка продуктов на Java имеет собственную специфику, отработанную, кстати, в течение многих лет. Странно представлять все это как недостаток EP или J2EE в целом. Смею предположить, что масштабы внедрения разработок на основе стандартов J2EE на порядки превосходят внедрения ABAP-систем.

Ну хорошо хоть мидлтайр портала признаете.
Я не уверен что на J2EE на порядки больше внедрений, чем на ABAP. Думаю что необходимо сравнить по цифрам. В ракурсах внедрения, успешного внедрения. На моей памяти в 1998 году у SAP уже было более 25000 крупных много системных инсталляций ( собсно в системах называлась цифра в 120 000 установок). Сколько сейчас, я не знаю вполне возможно что цифра в районе 100 000 инсталляций и 4-500 000 систем. А вот сколько систем на Java???
korchagin написал:
Все вышесказанное не является аргументацией в пользу внедрения Enterprise Portal, выбора Java в качестве языка реализации и прочих общих положений. Однако критиковать эти продукты следует все-таки более обосновано.

С некоторыми Вашими утверждениями я согласен. Однако считаю что свое мнение я обосновал.


Пометить тему как нерешенную
Вернуться к началу
  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, янв 11 2006, 15:52 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Пн, ноя 07 2005, 15:59
Сообщения: 1071
Откуда: Moscow
Пол: Мужской
N2 написал(а):
Я хочу заметить, что разработчик платформы должен адаптировать ее к стандартам страны, в которую он ее поставляет. Я имею в виду SAP, а не Sun в данном случае.


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

N2 написал(а):
Однако давайте разберемся- что SAP предлагает в качестве основы для SSO? - SAPCRYPTOLIB .... Поправьте если я не прав.


Не вполне понял, в чем вопрос. В качестве API для работы с SAP Logon Tickets предлагается SAPSSOEXT плюс SAPSECULIB. Для прочих методов аутентификации – стандартные способы, которые поддерживаются соответствующими iView.

N2 написал(а):
попробуйте помепить месяцок такое решение


В принципе, есть три варианта mapping – когда первоначально параметры авторизации определяет admin, user или тот и другой. Так что пользователь может сам сопоставить себя с учетной записью системы. В общем-то, в данном вопросе, опять же, поднимаются проблемы не продукта SAP Portal, а SSO вообще.

Точно так же обеспечение шифрации трафика от системы к какому-либо клиенту – не вопрос реализации клиента. Тем более, когда этот клиент – обычный WinGUI, хотя бы и в inline браузера.

N2 написал(а):
в тени остался факт того что SAP EP "нормально" ( ну если браузер не патчить и рабочую станцию перевести на ручное обновление и с выходом на Windows Update тестировать каждый патч от MS ) работает только с IE.


Да, это, на мой взгляд, одна из наиболее существенных проблем портала. Полностью похерена платформенная независимость, так хотя бы использовали в таком случае в полной мере преимущества MSIE (несомненные, но проприетарные). Но, увы...

А вот тут я грянусь оземь, и оборочусь в ваххабизм.

Мой опыт работы с EP совсем небольшой, однако, я успел столкнуться с целым букетом потрясающих «особенностей» этого продукта. Например, просто поразило, что один из первостепенных модулей CMC в SR1 (релизе! который, к тому же, уже содержит аж SPS9!) неспособен аплоадить файлы в репозитарий. По причине того, что разработчики ЗАБЫЛИ указать «multipart/form-data» в свойствах формы. В последующих SP эту проблему закрыли, однако прецедент дает основания ожидать новых сюрпризов.

Про неработающий до установки обновлений TREX я уже писал раньше. То, что поддержка русского языка в поисковике пока «экспериментальная» и включается ручным редактированием конфигурационных файлов, в рекламных буклетах и презентациях не пишут. Впрочем, простой поиск работает вполне удовлетворительно.

Интересные глюки связаны с кешированием на клиенте. Например, после установки обновлений портала, приходилось вручную чистить кеш IE, потому что JavaScript работал неправильно. Но самое любопытное – это вываливание в цикле ошибок Java в окно браузера (как IE, так и Mozilla) при поиске на SDN. Судя по всему – из-за конфликта версий закешированных библиотек портала SDN и собственного.

Невероятно эффективное пожирание ресурсов – за месяц умеренно активной работы с порталом единственного пользователя, объем базы вырос на целый гигабайт. Видимо, персонализация требует немалых жертв. Только не говорите мне про ресурсоемкость Java – она тут совсем ни при чем.

Отдельная песня – настройка внешнего вида портала, доступная только через веб-интерфейс. На каждый чих-пых, для того, чтобы увидеть изменения, необходимо подождать пару минут, пока будет очищен кеш браузера. О том, что этот браузер – исключительно MSIE – упоминать излишне. Гибкость структуры интерфейса тоже впечатляет.

Но более всего меня убила уже описанная выше проблема с Basic Authorization в MSIE. SAP помалкивает, будто это не их дело. В форумах SDN давно смирились: https://www.sdn.sap.com/irj/sdn/thread?threadID=13734 https://www.sdn.sap.com/irj/sdn/thread?threadID=15558

Проблема, конечно, решаема, но почему пользователь должен придумывать собственные костыли для одной из наиболее важных функций портала?

N2 написал(а):
Теперь про ABAP - я базисник, не программист, однако ABAP - язык ОЧЕНЬ высокого уровня. И уж выше чем Java. На ABAP отчеты и диалоги пишутся ОЧЕНЬ быстро. Добавьте огромную библиотеку классов высокого уровня - написать сложный Web-сервис можно в пару строк.


Я не вижу смысла сравнивать Java с каким-либо специализированным языком вроде ABAP. Преимущества ООП – тема давно избитая, не подходящая ни данной теме, ни форуму, и лично для меня исчерпанная. Что касается Perl и PHP – я, в принципе, достаточно знаком с этими языками (лет восемь - Perl, немного меньше - PHP, как процедурный, так и объектно-ориентированный код, в т.ч., коммерческие приложения, в т.ч. в рамках публичного портала). Не хочется сравнивать уровень развития основанных на этих языках технологий. Могу только отметить, что мне неизвестны продукты, ориентированные на Perl или PHP, хотя бы немного соответствующие уровню таких серверов приложений, как IBM WebSphere, BEA WebLogic, Oracle AS, или, хотя бы, JBoss или Orion.

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

Вся та функциональность, которая заложена в стандартном пакете, запросто могла бы быть реализована с несравнимо меньшими затратами ресурсов, и с гораздо меньшей стоимостью поддержки и модификации. При этом не важно, на каком языке программирования – Java, Perl, PHP или еще каком-то.

Не надо забывать, что NetWeaver объявляется SAP как «сервисно-ориентированная» платформа. Всякая ботва, вроде Business Connector Server, выбрасывается, и заменяется единой платформой построения распределенных систем. А EP – это всего лишь полезная примочка, один из сервисов, который реализован на этой платформе. У меня есть подозрения, что спустя какое-то время Java WAS займет куда более весомые позиции в ландшафте системы управления предприятием. В качестве примера можно посмотреть на ближайшего конкурента – OEBS и Oracle Fusion Middleware.

А вывод, несмотря на все рассуждения, такой: а чего ж не внедрять. Не потому, что имеет неоспоримые достоинства, а потому, что, наверное, это вполне можно будет продавать. Лейбл правильный, модно и престижно.

Автору топика могу заметить вот что – думается мне, Ваше руководство, так же, как и мы все, прекрасно понимает, что этот EP нужен не им, а Вам (в копилку опыта, так сказать). Посему обосновывай – не обосновывай, если еще не возникла необходимость в подобном продукте, или нет планов кому-нибудь его впаривать в дальнейшем – никто его внедрять не возьмется. Разве что уж совсем нечем работника занять.


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, янв 11 2006, 16:27 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Вт, авг 31 2004, 14:57
Сообщения: 5258
Откуда: Ростов невеликий
Пол: Мужской
korchagin написал:
Да, это, на мой взгляд, одна из наиболее существенных проблем портала. Полностью похерена платформенная независимость, так хотя бы использовали в таком случае в полной мере преимущества MSIE (несомненные, но проприетарные). Но, увы...

вот-вот...
Цитата:
Невероятно эффективное пожирание ресурсов - за месяц умеренно активной работы с порталом единственного пользователя, объем базы вырос на целый гигабайт. Видимо, персонализация требует немалых жертв. Только не говорите мне про ресурсоемкость Java - она тут совсем ни при чем.
Однако, если рассматривать возможные методы реализации корпоративного портала, особенно в таких масштабах, которые могут быть востребованы подавляющим большинством клиентов, могу согласиться с тем, что мощность сервера приложений и заложенные в нем возможности масштабирования и организации сервисов - совершенно чрезмерны.
Вся та функциональность, которая заложена в стандартном пакете, запросто могла бы быть реализована с несравнимо меньшими затратами ресурсов, и с гораздо меньшей стоимостью поддержки и модификации. При этом не важно, на каком языке программирования - Java, Perl, PHP или еще каком-то.
Не надо забывать, что NetWeaver объявляется SAP как 'сервисно-ориентированная' платформа. Всякая ботва, вроде Business Connector Server, выбрасывается, и заменяется единой платформой построения распределенных систем. А EP - это всего лишь полезная примочка, один из сервисов, который реализован на этой платформе. У меня есть подозрения, что спустя какое-то время Java WAS займет куда более весомые позиции в ландшафте системы управления предприятием. В качестве примера можно посмотреть на ближайшего конкурента - OEBS и Oracle Fusion Middleware.

10 лет назад то же (ресурсоёмкость) говорили про sap 4.0. Т.е. ощущаем себя Beta-тестерами. ИМХО, чрезмерность - понятие временное.
[/quote]


Пометить тему как нерешенную
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, янв 11 2006, 16:45 
Гость
Цитата:
Я не вижу смысла сравнивать Java с каким-либо специализированным языком вроде ABAP. Преимущества ООП – тема давно избитая, не подходящая ни данной теме, ни форуму, и лично для меня исчерпанная.

Я согласился бы с вами, если бы не одно НО.
Дело в том что уже более 7 лет SAP AG позиционирует SAP WAS на ABAP как мультизадачную среду для построения чего-бизнесу-угодно.
С точки зрения прикладного разработчика нет таких задач, которые нельзя было-бы реализовать на ABAP (кроме сетевых сервисов наверное, однако и они реализуемы плагинами к icm, да и нужны ли они прикладникам??? ).
Проследите хронологию развития SAP R/3 до SAP ERP и вы увидите что творится совершенно непонятное:
- паралельно с развитием SAP R/3 4.0B выпускается SAP Bussiness Connector 4.0, который позиционируют как основу B2B
- потом идет тенденция разделить BASIS и APPLICATIONS, затрачиваются огромные усилия, выпускается SAP Bussiness Connector 4.7 который объявляют ПОСЛЕДНИМ в линейке Java систем и анонсируют новый подход в SAP - Internet Connection Framework - основа SAP WAS ( тогда под торговой маркой WAS понимали ТОЛЬКО ABAP машину).
- с выходом релиза 4.6 идет большая маркетинговая компания о новом, более новом, полностью объектном ABAP (еще его называют в пресс-релизах ABAP версии 5.0, акцентируя внимание что он на поколение выше базового ABAP/4)
- потом появляется SAP WAS J2EE, который объявляют интеграционной платформой, этаким middleware для интеграции прочих АСУ предприятия с основной системой на SAP R/3 4.7
- через год акцент меняется и во всю идут анонсы об остаточности ABAP и переноса всего на Java.
- через полгода после таких объявлений SAP заявляет о безоговорочном развитии ABAP как mainstream в своих продуктах, полной объектизации ABAP, появлении в нем в последствии WebDynpro, до этого обкатанном на J2EE

То ли SAP AG внутри технологически колбасит - и их топы борятся за технологии, толи у них полная дезорганизация по технологии - что поперло, туда и полезли.... Может они устаканяться и оставят ABAP-у свое, а Java-е свое ...

В общем кроме догадок остается только недоумение ...


Пометить тему как нерешенную
Вернуться к началу
  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB