Как я обещал в прошлом посте, я рад представить план развития Платформы на этот год. Это стратегический план, в который мы включили только крупные изменения, но безусловно будут иметь место и сотни мелких улучшений.

Дисклеймер: Этот план не является догмой, и мы наверняка реализуем что-то сверх него, а что-то наоборот отложим. Однако в целом мы собираемся придерживаться этого плана, и предлагаем сообществу разработчиков на Платформе CUBA также на него ориентироваться.

Тизер: CUBA Studio будет встроена в IntelliJ IDEA!

Итак, поехали!

На заре 2018 хочется подвести итоги, и рассказать об изменениях в платформе CUBA за прошлый год. Если 2016 стал для нас революционным благодаря переходу в опенсорс, то 2017 стал годом планомерного развития: мы сфокусировались на предложении новых фич и услуг нашему сообществу.

Sql, RegExp, Gradle — что их объединяет? Всё это примеры использования проблемно-ориентированных языков или DSL (domain-specific language). Каждый такой язык решает свою узконаправленную задачу, например, запрос данных из БД, поиск совпадений в тексте или описание процесса сборки приложения. Язык Kotlin предоставляет большое количество возможностей для создания собственного проблемно-ориентированного языка. В ходе статьи мы разберемся, какие инструменты есть в арсенале программиста, и реализуем DSL для предложенной предметной области.

Весь синтаксис, представленный в статье, я объясню максимально просто, однако, материал рассчитан на практикующих инженеров, которые рассматривают Kotlin, как язык для построения проблемно-ориентированных языков. В конце статьи будут приведены недостатки, к которым нужно быть готовым. Используемый в статье код актуален для Kotlin версии 1.1.4-3 и доступен на GitHub.

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

Под катом:

• Uber JAR
• UI-компонент для предиктивного поиска
• Версионирование REST API
• Балансировка нагрузки в кластере
• Компонент приложения ZooKeeper
• Улучшения в Polymer UI
• Поддержка Bean Validation в CUBA Studio
• Поддержка Groovy в слушателях сущностей

Быстрое развитие технологий и инструментов разработки ПО приводит к тому, что технологии, лежащие в основе информационной системы, теряют свою актуальность и становятся тяжелой ношей. Взять, к примеру, какую-нибудь разработку компании для автоматизации процессов, написанную на Visual Basic 6.0 или Delphi 7, которая, мягко говоря, не сочетается с новыми трендами “все в web, все в облака”, да и не соответствует амбициям разработчиков.

Проблема перевода старой ИС на новые технологии, доходя до руководства, традиционно упирается в деньги: “поживем и так...”. Для разработчиков, в свою очередь, уже перенос модели данных и шаблонное программирование стандартных экранов вызывает негатив. При этом зачастую все усложняется требованием сохранения работоспособности старой ИС на этапе разработки и внедрения новой. Так или иначе, по моему опыту, продукт либо умирает совсем, вызывая мучения как программистов, так и пользователей, либо все же приходит понимание, что обновление ИС — неотложная необходимость.

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

Под катом пошаговая инструкция, как модернизировать устаревшую систему с минимальными усилиями на перенос модели данных и стандартных CRUD экранов.

Недавно мы выпустили новый релиз CUBA Platform и CUBA Studio. Если в версии 6.3 мы сделали акцент на архитектурных и технических новшествах, то этот релиз прибавил к платформе много фич, с которыми процесс разработки стал быстрее и удобнее. Мы добавили новые визуальные компоненты универсального пользовательского интерфейса, централизованный механизм валидации данных, движок для генерации альтернативного фронт-энда на основе Google Polymer и другие важные улучшения. Подробности — под катом.

Disclaimer: статья в первую очередь адресована разработчикам, уже знакомым с платформой CUBA.

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

Безусловно, главное событие года для нас – переход в open source. Это привело к взрывному росту сообщества и – как ни парадоксально – продаж. Под катом я расскажу о причинах и результатах этого шага, и в дополнение сделаю обзор основных новшеств с технической точки зрения.


Активные проекты на платформе CUBA

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

Но для того чтобы создать инструмент, способный что-то систематизировать и упорядочивать, нужно для начала самим научиться систематизировать и упорядочивать свои дела. Для нас главное дело — разработка системы документооборота ТЕЗИС. Поэтому неудивительно, что работа над каждым новым релизом системы тоже движется по четкому маршруту — как работа над любым документом в нашей СЭД.

В этой статье мы хотим ненадолго пустить читателя на внутреннюю кухню разработки системы документооборота. Мы расскажем об этапах подготовки к релизу СЭД ТЕЗИС и покажем, как выстроена работа над новыми версиями. Возможно, наш организационный опыт окажется кому-то полезным.

Незаметно пролетели почти три года с момента публикации первой статьи о платформе на Хабре. За это время многое изменилось: мы вышли на международный рынок, перешли к open source лицензии, обновили стек технологий и внесли множество улучшений во фреймворк и средства разработки. Поэтому вместо длинного списка изменений мы решили опубликовать ещё одну обзорную статью о платформе CUBA, которая, я надеюсь, будет интересна разработчикам кровавого энтерпрайза корпоративных информационных систем — как ещё не знакомым с платформой, так и тем, кто уже что-то слышал о ней.

Итак, под катом вы узнаете:

• Что представляет из себя платформа CUBA и какова её архитектура
• Какие решения эффективнее всего разрабатывать на CUBA
• Как платформа помогает сэкономить время разработки корпоративных систем
• Какое окружение необходимо для развертывания CUBA-приложений
• Как мигрировать устаревшую систему на CUBA
• Под какой лицензией распространяется платформа
• Как организована поддержка разработчиков

Не секрет, что мы в Хоулмонт сами используем СЭД ТЕЗИС. Странно было бы, имея в руках современный и надежный инструмент для хранения и согласования документов, пользоваться чем-то еще. Неудивительно и то, что для любой достаточно крупной компании штатной функциональности СЭД порой не хватает. В этой статье мы расскажем, как создавался дополнительный модуль к нашей внутренней СЭД ТЕЗИС — модуль управления финансовыми ресурсами, или просто модуль финансовых заявок, как мы его зовем. А заодно воспользуемся случаем и немного покажем, как проводится проектное внедрение системы на примере отдельно взятой организации.

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

У системы документооборота тоже может быть свой фундамент — технологическая платформа. Выбор платформы и принципов, на которых она построена, в буквальном смысле влияет на то, как СЭД будет дальше жить — ведь эти принципы и есть те самые “кирпичики”, которые обеспечивают ее устойчивость.

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

Именно в таких случаях важен выбор платформенного решения. Однако, какой должна быть платформа, лежащая в основе будущей СЭД? Какие фундаментальные принципы должны лежать в ее основе? Мы выделили для себя три основных принципа, которыми должна обладать технологическая платформа системы электронного документооборота, чтобы обеспечить успешное развитие СЭД в будущем.

Спустя два года присутствия на российском и года на мировом рынках платформа CUBA присоединяется к кругу свободно распространяемого программного обеспечения и переходит на лицензию Apache 2.0. Таким образом, широкий круг разработчиков Java, ориентирующийся на открытые технологии, получит возможность разрабатывать и распространять свои CUBA приложения абсолютно бесплатно, а также изменять и развивать платформу самостоятельно!

Кто не знаком с платформой, приглашаем вас ознакомится на наш сайт или прочитать первую статью о платформе на хабре.

Возьмем типового корпоративного заказчика, допустим, банк. В каждом банке есть руководящие органы – совет директоров и правление, потребности которых в работе с документами едва ли можно удовлетворить при помощи обычной СЭД. Причем не надо путать задачу обеспечения деятельности коллегиальных органов с так называемым «АРМом Руководителя», который есть в некоторых СЭД. Руководитель, пусть даже самого высокого ранга, в принципе такой же участник бизнес-процесса, как и любой другой сотрудник, он тоже согласует и утверждает документы. Только в силу своей занятости и высокого статуса, руководители более требовательны к удобству работы с системой и, как правило, очень мобильны. Короче говоря, руководителям нужно ограниченное подмножество функций СЭД, упакованное в красивый и удобный интерфейс на планшете, но это все-таки СЭД, а не какая-то другая система.
А когда мы говорим об автоматизации коллегиальных органов, типа совета директоров и правления, то на первый план выходит коллективная работа и поддержка процессов корпоративного управления, для чего используются специализированные системы. СЭД, даже с «АРМ Руководителя», не покрывает этот комплекс задач.

“Время – это капитал работника умственного труда.”
Оноре де Бальзак

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

Всеобщие мучения с системой учета времени, по причине отсутствия времени (см рисунок), не стали веским основанием для разработки своей системы. Спасла же ситуацию идея написать реальное приложение для демонстрации возможностей нашей платформы CUBA. Совмещая приятное с полезным, система учета времени стала первым кандидатом.

В настоящий момент разработка завершена, приложение внедрено в нашей компании, и мы готовы поделиться им со всеми желающими.

В этой статье я расскажу, как мы в сжатые сроки (< 1 мес), ограниченными силами (человек и еще полчеловека) разработали это приложение.

Платину добывают так же, как золото – моют песок, собирают драгоценные крупицы, затем переплавляют. Регулярные работы по добыче платины на месторождении Кондёр в Хабаровском крае были начаты старателями артели «Амур» еще в 1984 году. Как оказалось, залежи платины здесь огромны, свидетельством чему стали самородки весом от полутора до трех с половиной килограммов. В 2007 году образовался холдинг «Русская платина», куда вошла артель «Амур» и ряд других предприятий.

А когда возникает холдинг, то неизбежно появляется и потребность в автоматизации документооборота, потому что бизнес-процессы усложняются, их участников разделяют тысячи километров, и не то что с бумагой, даже с электронной почтой и таблицами Excel для регистрации документов обработать весь поток становится невозможно. В общем, группа компаний «Русская платина» решила внедрить СЭД ТЕЗИС.

Продолжаем серию материалов, позволяющих по-новому взглянуть на применение ECM или СЭД для автоматизации корпоративных бизнес-процессов.

Бывает так, что жизнь подбрасывает задачи, которыми ты вовсе и не собирался заниматься, когда проектировал свою систему документооборота. Можно, конечно, гордо сказать «наша система для этого не предназначена» и это будет вполне честный профессиональный ответ. А можно трезво подумать, как использовать возможности ЕСМ по-новому и рискнуть выйти за границы отведенной себе ниши – и заказчика удовлетворить, и новый опыт наработать.

Если ECM-система была спроектирована с хорошим запасом гибкости и адаптивности, то область ее применения можно безбоязненно расширить на многие смежные задачи, выходящие за рамки канцелярского документооборота. Автоматизировать процесс МТО – материально-технического обеспечения, посягнув при этом на традиционную поляну ERP? А почему бы нет, если заказчик того просит?

Продолжаем серию статей на тему "СЭД: путь от простого к сложному".

Можно ли при помощи СЭД автоматизировать контроль казначейской деятельности в компании, у которой подразделения и дочерние организации находятся на большом удалении друг от друга? Это смотря какая у вас СЭД. Сразу оговоримся: речь не идет о том, чтобы все бизнес-процессы свести к перекладыванию «бумажек» и смоделировать работу всех подразделений по принципу канцелярии. Отнюдь!
Дело в том, что узко-предметный подход к разработке бизнес-приложений, в том числе и СЭД, давно в прошлом. Сегодня любая приличная система обладает изрядным запасом гибкости и функциональности, поэтому может быть использована для решения порой нетипичных задач. Так и получилось в вертикально-интегрированной нефтяной компании НК «Альянс», где, ввиду интенсивного документооборота и необходимости организовать эффективное взаимодействие между пользователями из разных регионов России и Казахстана, выбор СЭД ТЕЗИС в качестве платформы оказался более чем успешным.

Сегодняшней публикацией мы открываем серию материалов, позволяющих по-новому взглянуть на применение СЭД для автоматизации корпоративных бизнес-процессов. Реализация ВРМ-стратегии при помощи системы электронного документооборота может казаться заманчивой идеей — в конце концов, в любое современное решение встроен BPM-движок. Однако, взаимосвязь бизнес-процесса и документа на практике оказывается сложнее, чем представляется в теории. В серии статей мы совместно с экспертом Станиславом Макаровым расскажем о том, почему налаженная автоматизация хранения и обработки документов — первый шаг к будущей BPM-автоматизации. В последующих статьях мы планируем продемонстрировать актуальность этой мысли примерами реальных бизнес-процессов, таких как бюджетирование, договорная работа или материально-техническое обеспечение.

В этой статье я расскажу о нашей реализации hot deploy — быстрой доставки изменений Java-кода в работающее приложение.

Для начала немного истории. Мы уже несколько лет делаем корпоративные приложения на платформе CUBA. Они очень разные по размеру и функциональности, но все они похожи в одном — в них много пользовательского интерфейса.

В какой-то момент мы поняли, что разрабатывать пользовательский интерфейс, постоянно перезагружая сервер — крайне утомительно. Использование Hot Swap сильно ограничивает (нельзя добавлять и переименовывать поля, методы класса). Каждая перезагрузка сервера отнимала минимум 10 секунд времени, плюс необходимость повторного логина и перехода на тот экран, который ты разрабатываешь.

Пришлось задуматься о полноценном hot deploy. Под катом — наше решение проблемы с кодом и демо-приложением.

Фреймворки Google Web Toolkit и Vaadin достаточно хорошо себя показывают, когда вы просто используете их. Если вдруг вам понадобилось расширить их функциональность, то вам придётся серьёзно попотеть. В этой статье я хочу рассказать, как написать простой компонент на GWT, добавить к нему серверную часть Vaadin и использовать в своём приложении. Я не буду создавать некий совсем пустой GWT/Vaadin проект и с самого начала настраивать компиляцию GWT, вместо этого возьму приложение на базе CUBA.Platform, в котором и реализую сам компонент, а затем попробую в деле. Так будет видно, насколько хорошо всё впишется в настоящее приложение. Отдельное внимание я бы хотел уделить отладке компонента, поскольку она нетривиальна и всегда вызывает трудности у разработчиков.

Хочу предупредить, что не всё описанное в статье относится к GWT и Vaadin, часть шагов и приёмов применимы только в контексте использования CUBA.Platform, за счёт этого сильно упрощена настройка окружения и некоторые рутинные действия.