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

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

metalstorm
...
По поводу разработки - ИМХО в пока что РФ НЕТ нормальных, компитентных, центров разработки, которые могли бы реализовывать все задачи, а если и есть то единицы....


Какую задачу реализовать? )))

Насколько я помню Пермские доработки, в целом, складывалось чувство, что очень многие вещи они переусложнили. Сталкивался с тремя доработками: 2-

2-е по расчетам по норме, и счет-фактура. Первые мы вообще сделали без "ломания" get consumption, чисто на алгоритме среднего. А счет-фактура, описание на N-листах с необходимыми настройками счета и алгоритмов которые оттуда данные забирает.... в общем.... как-то сложновато... IMHO

В целом, честно говоря я считаю, что собственно систему хаять очень сложно. По сравнению с OeBS:
1. ОЧЕНЬ мало ошибок собственно Oracle (SPL). Система очень хорошо оттестировала.
2. Очень оперативно выходят патчи, система развивается.
3. Тех. поддержка правда какая-то странная. То тупит по черному, то на нормальные запросы просто посылают на 3-и буквы, то на разработчиские SR-ы просто подрываются и сверх.оперативно фиксят. В общем... скорее я не умею саппорт готовить ((((

Недостаток - крайне ООП /объектное/ построение системы. Кол-во уровней абстракции, настройки, кешей и пр. просто зашкаливает. Например meta данные для GUI: таблицы в БД. -> кэш на сервере -> XML в файловой системе -> HTML для отдачи клиенту -> кэш браузера -> JavaScript
Meta данные для служб: таблицы в БД -> Wizard -> анотации в Java -> АртиФАКт генератор -> код Java + XML -> cm.jar -> загрузка в структуры системы.

Пи....ц

metalstormLeonid Kudryavtsev
Какую задачу реализовать? )))

Да хотя бы создание кастомной формы на основе существующей :) (для добавления полей к примеру), если метаданные закопировать проблем нет, а вот замодифицировать кобол, и внести туда свою дополнительную логику как то сложновато ))) В версии 2.2 большинство page сервисов к сожалению не на жабе. Хотя оракла нам давала клятву все на нее перевести..

Вы так делаете? Можешь подробнее рассказать?

Мы делали двумя способами.
1. "Кривой" но простой: Чистый JavaScript (добавление элемента) + дополнительные Ajax вызовы для параллельной модификации своей таблицы с доп. информацией.
Понятно, что "криво" и "транзакционность" оставляет желать лучшего, но поля были бизнес не критикал, а нужно было быстро и чтоб было уже завтра ))).

2. "Более правильный" Маинтайнентс-экстеншен + дополнительный List.
2.1. Дополнительные листы (аккордионы ))) ) добавляются нормально. Работает.
2.2. Поля в главном объекте (root) - в версии 2.1 добавить нельзя. Если нужно дополнительное поле (не подчиненный список) - была предложение добавить вырожденный список и передавать данные в header'е списка, но такой задачи не было. Т.ч. не реализовывали.
Делал не я, т.ч. деталей не знаю. Есть рабочий код.

Кроме того:
Научились делать новые объекты "с нуля".
+порталы (pure JSP)

IMHO В ERP/Billing/покупной-системе системные объекты (Oracle) модифицироваться не должны. Если нужны дополнительные поля - кастом таблица и связь 1:1 (один к одному). IMHO.

Andrey Nikolaenko
всегда можно повесить интерцептор на pageService, но, как было проницательно отмечено:

В данном случае - не помогает совершенно (по крайне мере в версии 2.1)

Максимум, можно сделать маинтенанс-екстеншен и добавлять там в структуру свои дочерние списки. Модифицировать метоописание корневого (существующего) объекта - не получается . А добавить новые списки - можно. С этом случае не нужна модификация метоописаний существующих entity. Просто добавляется новый entity (child-таблица).

Не уверен, что понятно выразился ))) Но в общем работает.

Игры с интерсепторами и какая либо модификация метоописаний существующих entity - не катят совершенно ((( Если только в новой версии не меняли ядро.

Ну и можно делать свои entity.

Andrey Nikolaenko
Тем более, в CC&B/ETM практически все существенные мастер- и транзак-объекты снабжены расширяемыми флекс-филдами (т.н. характеристиками).


В 2.1. нет характеристик у CI_PAY, CI_PAY_EVENT. Ну и вообще у всего, что PAY (((

LeadenBullet,

Я бы порекомендовал продублировать в форуме Работа-Вакансии. А то тут вроде
a) как offtopic
b) неудобно пересылать (делиться) ссылкой с друзьями ))) А в Работе-Вакансии будет нормальный топик
c) вилка зарплат. Место работы? Москва + долгая долгая командировка (командировочные, проживание)? Или трудовая тоже в Екатеринбург будет оформляться, лежать.