Сейчас работаю. Общие впечатления (плюсы):

1. Продукт на порядок продуманней, чем к примеру OeBS.
2. Наличие архитектора, заметно не вооруженным глазом. В целом, система достаточно "стройная", помойки (как в OeBS) нет и в помине.
3. Требования заказчика по правилам начислений "в первом приближении" были решены консультантами вообще без каких либо кастомизаций. На мой взгляд, это огромное достижение системы. В целом, очень много что предусмотрено.
4. Rich Web Interface. По сравнению с убогим HTML-интерфейсом OeBS, огромное достяжение. Аякс в полный рост.
5. Есть возможности кастомизации для консультантов: зоны, порталы, скриптинг и т.д. Значительно более продуманно, чем персонализации в OeBS.
6. Используются технологии типа Аякс, XML/XSLT, Hybernate, Cobol и т.д. Для программиста, скилы наверное будут востребованы на рынке ))).

Из минусов (можно пропустить, читать итоги):
1. Пока еще редкость на территории России.
2. Кроссплотформенность. Возможности СУБД не используется в принципе. Ни PL/SQL, ни констрейны и т.п. и т.д. Ключегенерирование методом random вызывает изумление и легкий шок.
3. Java:
3.1. В целом, достаточно тяжелая и тормознутая система. Клиент - DHTML, JavaScript, AJAX - в целом красиво. Но "тяжелые" экраны отрабатывают достаточно долго, на мой взгляд, задержки на экранах типа Account Center - настолько высоки, что комфортной работу можно назвать с трудом
3.2. Java (как ей и положено :) ) - умеет говорить только одну ошибку Null pointer exception. Что не очень приятно. Хотя в целом, ошибок собственно в SPL-коде достаточно (очень!) МАЛО. Но искать свои ошибки (например при кастомизации) - умучаешся.
3.3. Большая избыточность кода (даже без учета Cobol copy book'ов) - задача на 25 строк PL/SQL'я реализована минимум 5-6 классами Java, а скорее и больше.
4. Cobol
4.1. Медленно и тормознуто. С трудом читаемые алгоритмы. Лично мне, после 100 Kb copy book'ов начинает болеть голова и хочется закрыть текст программ нафиг. Помогает Application Viewer, где текст разбит на программные блоки с гиперсылками. В общем, даже терпимо.
4.2. Cobol - что еще сказать. Лично я изучать кобол не хочу ))). Старый, ленивый.
5. Кастомизация:
5.1. У SPL свой подход (правильный) к процессу разработки. External Design, Internal Design, Unit Case'ы, написание кода. Но где в России и на каком проекте внедрения программисту так дадут работать? Писать код в авральном режиме - очень тяжело и практически не возможно. Просто перезапуск сервера (что требуется при изменении кода) - 3-5 минут. Т.е. для нормальной разработку (комфортной), нужно делать Unit Case, что бы делать Unit Case, нужно нормальное задания.... а такое на проектах внедрения в Российских (не SPL) консальтерах будет большой редкостью IMHO.
5.2. Много разных Alogoritm Sport'ов, User Exit'ов, Interceptor'ов и т.д.... В целом, с одной стороны все достаточно логично и красиво (по понятиям Java :) ), с другой, избыточно (см.п.3.3,4.1.) и в тот же момент недостаточно гибко (например для Page Service интерсепторы вызываются, а для List Service интерсепторов нет).
Кастомизация требует Java/Cobol. В БД ничего по нормальному не напишеш (PL/SQL не используется). Простые задачи по обработке, решаемые в 20-25 строк PL/SQL - а нужно кучу непонятного кода на Java для работы через Hybernate делать.
5.4. В последних версиях, начиная с 2.1 очень сильно продвинулись встроенные средства кастомизации (скриптинг и т.д.). На 2.2. не смотрел. Но на мой взгляд, там опять таки, начинают быть заметны влияние новомодных технологий (Java,XML). Вместо того, что бы сделать по простому, начинают делать по правильному ((((. С одной стороны, скриптинг в 2.1 (по сравнению с 2.0.5) стал значительно более функциональным, с другой - и более громоздким.


В общем:

IMHO Система хорошая. Большинство недостатков проистекают из достоинств. Т.ч. даже, это скорее ворчание, чем реальная критика.

Для клиента, самый большой недостаток должен быть пока еще малая распространненность в России: мало специалистов, небольшой опыт у независимых (не SPL) консалтеров, удаленный центр разработки SPL (дорогие разработки). Но думаю, это со временем пройдет ))).

Недостаток для меня - увлеченность новомодными технологиями (типа Java, Hybernate, XML/XSL). Как я сказал, если что-то можно сделать "просто и понятно" или сложно, но "правильно". Делаю (как сейчас и пложено) сложно, медленно, но "правильно". Но это общий недостаток современных технологий программирования IMHO.

А почему возник такой вопрос? Вроде узок круг причастных к SPL на территории России и Беларуссии )).

Вообще, можно зарегистрироваться в http://energy-forum.ru/. Там могут более подробно ответить.

Infernal V. Raven
Еще из минусов - сложная интеграция. Службы XAI без серьезной доработки использовать не представляется возможным.

С чем сравнивать "сложность" интеграции. По сравнению с другими системами - XAI это круто. XAI доработки вообще не требует.

Если говорить не о XAI, а SysDL - то какие притензии к Oracle? _Заявленные_ функции (родные объекты) работают, то, что дофига объектов в оригинальном SysDL нет - ну нет их. Никто и не обещал.

Infernal V. Raven
Ориентация платформы - чистый биллинг(притом биллинг одной-двух услуг. Как я понимаю, в основном для энергосбытовых компаний), попробуй туда еще чего-нибудь прикрутить - замучаешься.


Для прикручивания дано очень много возможностей. Термин "открытая" к системе вполне подходит. Но понятное дело, что это не среда программирования. Врят ли SPL стоит выбирать для "заказных" разработок.

Опять, с чем сравнивать "замучаешься"?

Чистой специфики энергосбытовых компаний в "чистом" дистрибутиве IMHO не так уж и много. Если поискать в google, внедрения есть в разных компаниях и много не энергетических.

Infernal V. Raven
Да и те части которые хочется подкрутить, обычно написаны на КОБОЛе, что неприятно.

Согласен, но только частично:
1. Я категорически против модификации (подкручивания) компонентов системы. Только в самых экстренных случаях.
2. С точки зрения "читабельности" - через application viewer, разобраться в коболовских алгоритмах вполне можно. Если бы в application viewer работал банальный поиск и выделение/копирование текста - вообще было бы счастье ))).
3. Код на Java не намного более читаемый.
4. Если нужны новые алгоритмы или батч-процесс - их можно кодировать на Java, забыв о Коболе. Представители Oracle клятвенно заверили, что если каких либо алгоритм-спотов на Java нет, они их делают в приоритетном порядке. Уже в 2.1 большинство алгоритмов Java-enabled.

Infernal V. Raven
тормоза при залитых данных на тестовой площадке ощущаются

Большенство тормозов - это порталы или откровенно тормознутый/перегруженный сервер. Нужно предметно разбираться с порталами, железом, средой. Собственно pure SPL-операции (выставление счета и т.д.) от объема не сильно зависят.

Если не секрет, что это за проект? Перьм?

У нас проблема именно с финансовой информацией. Загрузили всю финансовую историю с 1996 г. Но при этом еще "уехали" планы запросов в режиме choose на Oracle СУБД. Сейчас админов ткнули носом, они думаю, как планы запросов зафиксировать. Собственно CC&B не при чем (если не считать, что балансы он считает экстравагантно).

Для расширения Oracle Utilities CC&B (v2.1) достаточно Java. В реальности Cobol не требуется.

Почти все интерфейсы системы позволяют их реализовывать как на Cobol, так и на Java.

Все новое можно делать на Java: алгоритмы, новые сущности, новые службы (таблицы,экраны) и т.д.

Cobol требуется, только если Вы хотите изменять стандартный (Oracle) код или планируете писать свой код на основе стандартного (т.е. copy/paste и потом менять). Но, опять таки, нужно учесть: 1) что врят ли такое будет приветствоваться Oracle. 2) не все исходные тексты поставляются 3) Cobol )))

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


1. Мы настроили. Хотя теперь работающую копию Eclipse+SDK бережем как зеницу ока.
Средства коллективной работы - не настраивали
2. Что значит "Докрутка Eclipse" ? В него нужно SPL-плагины поставить и Artifact Generator. Главное делать точно по картинкам из доки.
3. IMHO Нигде. Only help. Информации там много. но структурирована очень плохо. (в 2.1)
Собственно SDK (GUI) почти не используем. Модификация метоописаний в БД - ручные insert'ы. Сейчас проще через таблицы, чем через их кривой GUI интерфейс. Java-код в Eclipse.
В самом начале SDK использовали, но сейчас через таблицы удобнее.
Патчи делаем самописные: SQL-скрипт + copy нужных файлов (*.jsp, cm.jar). Стандартный механизм патчивания не изучали.

LeadenBullet
Интересно, у вас есть компетенция по разработке расширений для CC&B? Больших сил потребовала подготовка специалистов?


Разработка расширений, IMHO:
1. Алгоритмы. - Почти без проблем
2. Порталы - Просто свои JSP страницы
3. Batch процессы - Вроде тоже реализуются без особых проблем
4. Новые таблицы и стандартный SPL интерфейс (описание новой сущности, сервис, описание интерфейса) - у нас не очень много своих сущностей. Разработчик примерно за 2 месяца разобрался. Хотя вопросы возникают и многие остаются без ответа
5. JavaScript user-exit'ы - так же без особых проблем. Типовые случае в доке хорошо описаны.

Oracle'вый курс был не сильно познавательным. Хотя и полезным. Нам оставили исходники ряда кастомизаций, т.ч. в ряде случаев пользовались ими как примерами.

1+2+5 - в принципе ничего сложно. 3 изучали на курсе. 4 разбирались сами но потребовалось прилично времени.

To kmtz:
http://forums.oracle.com/forums/thread.jspa?messageID=2757225
user620144 - это я. За что они меня так назвали, не знаю.

SDK для СС&B 2.2.0 не смотрели, у нас 2.1