Java development

Использование шрифтов в JasperReports

2012-08-21T01:40:00.000-07:00

Не так давно одной из моих задач было создать модуль отчетности, позволяющий разным клиентским приложениям использовать его для генерации и отдачи сгенерированного контента. При реализации этой задачи я активно работал с библиотекой JasperReports 4.5.1. Одна из первоочередных задач при работе с кирилическими документами - подключение шрифтов. В стандартном варианте подключения JasperRepots не имеет поддержки UTF-8 шрифтов. В нашем случае были необходимы шрифты Arial и Helvetica. Ни того ни другого нет по умолчанию. Дальше я опишу два подхода. Первый был выбран на скорую руку и я впоследствии решил от него отказаться. Второй подход - то как надо было делать сразу и он верный.

Решение 1. - Неправильное(мое оценочное суждение).

Скачать файлы ttf, из интернета, либо, если у вас windows, то их можно найти в директории {WIN_INSTALLATION_DIR}\Fonts\
Положить эти файлы в директорию проекта, чтобы они были доступны в classpath. Например сюда {project_dir}\src\main\resources\Arial.ttf
Явно указать название файла в отчете.

Такой подход привел сразу к проблемам, выяснилось, что выделение жирным не работает, потому что указанный шрифт не содержит жирного варианта. Была выбрана заплатка в таком виде - явно указывать шрифт для элемента. Поскольку сроки поджимали так и было сделано: Конечно, это жутко неудобно не только потому, что так можно делать только для элемента, а внутри элемента разделение на жирный и нежирный шрифт работать не будет, но и как следствие мы лишаемся гибкости в комбинировании элементов и их расположении. Ну и плюс к тому нужно постоянно прописывать явно имя шрифта. Почитав внимательнее документацию по JasperReports был выбран и использован верный способ работы со шрифтами.

Решение 2 - Правильное(рекомендованное документацией и сообществом JasperReports)

Для этого решения используется расширение стандартных шрифтов JasperReports через конфигурационные файлы. Шаги следующие:

Скачать/скопировать необходимые шрифты в папку {project_dir}\src\main\resources\fonts
Создать файл jasperreports_extension.properties в директории {project_dir}\src\main\resources\. Файл приведен ниже:
Создать файл specialfonts.xml в директории {project_dir}\src\main\resources\fonts Файл содержит описание того откуда JasperRepots будет брать файлы шрифтов и какой файл какому(жирному, курсиву и т.д.) стилю соответствует. Ниже пример моего файла:
Указать какой шрифт будет использоваться в шаблоне отчета.

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

JBOSS 7 and several persistence units.

2012-08-20T07:05:00.002-07:00

В течение этого года один из проектов, в котором я участвую, пишется с использованием технологий JEE, EJB3, JPA. Проект интеграционный и зачастую возникает задача использования нескольких баз в рамках одного модуля. Решается это просто: используется несколько persistence-unit в рамках одного persistence.xml. Например вот так: Все бы ничего вот только проблема заключается в том, что при таком подходе при запуске JBOSS жалуется на ошибку инициализации CoreReportAnotherSchemaJPA контекста, он пытается в нем найти связку для класса ReportCategory, который вроде бы даже не определен в этом persistence-unit. Оказывается проблема заключается в следующем. При определении персистеных классов во всех модулях нашего проекта используется аннотация Entity. Ниже пример такого класса: При старте приложения, сервер приложений не обращает внимание на то, что явно указаны классы в persistence-unit он сканирует на предмет наличия аннотации Entity доступный в classpath классы. Отсюда возникает эта коллизия. Решение оказалось довольно простым в спецификации есть тег exclude-unlisted-classes по умолчанию он имеет значение false, поэтому и добавляются не нужные мне классы и происходит коллизия с тем что указано. Включив этот флажок получаем именно то что нам нужно - включаться будут только те классы что указаны руками. Конечно, в обычном приложении без интеграционных замарочек с legacy кодом в разных базах такой проблемы не возникнет. Но кому-то все же этот прием может понадобится. Ниже приведен пример работающего кода с означенным тегом:

Использование placeholders из одного properties файла для конфигурации другого.

2011-01-26T13:07:00.000-08:00

Иногда появляются нетривиальные задачи конфигурирования приложения для определенных нужд. Один из примеров: есть приложение, которое должно работать в разных environment'ах: development, test, production. В зависимости от environment'а используются разные файлы конфигурации/настройки. Другой пример - одно и тоже приложение может запускаться в нескольких экземплярах в одном application-сервере, при этом по разному сконфигурировано, с помощью разных файлов настроек.
Во втором случае одно из достаточно неплохих решений я опишу ниже. Файлы конфигурации - это обычные property-файлы с парами ключ значение. При этом конфигуарция всех модулей находится в одном месте, путь к которому я указываю через переменную окружения CONF_HOME. Эта переменная указывает на корень конфигурации. А в нем уже идут директории module1, module2, ..., moduleN, module1-diffconfig, modulek-n-configuration. Внутри каждой папки есть файлы типа conf.properties.

В spring чтобы использовать значения из файлов настройки в виде ${server.property1} нужно объявить в context.xml следующую конструкцию:

Но ведь мне нужно иметь возможность без перекомпиляции модуля запустить несколько его экземпляров с разными файлами настройки.

Решение следующее: в каталоге CONF_HOME для каждого экземпляра модуля заводится отдельная папка, а в ней находятся файлы настройки с одинаковыми именами,но, понятно, с разными значениями одних и тех же параметров:

Понятно, что основной вопрос - как нам изменить строчку в context.xml

чтобы вместо module1 подставлялось значение для конкретного экземляпра модуля. Решений может быть несколько, один из простых вариантов - сделать дополнительный файл настроек module.properties в котором будет одно поле nodeName=module-specific-conf. Можно сделать таким образом, чтобы это значение подменялось при мавенской сборке. Поскольку это не тема данной статьи, то варианты решения я оставлю на усмотрение любознательного читателя.

Итак я сделал дополнительный файл настроек, который собирается в war-ник и его значение используется при поиске специфичных для приложения настроек.
Казалось бы теперь все очень просто и нам должна помочь вот такая конструкция:

Но ни тут-то было. Spring при инициализации бина, не может распознать nodeName. Оказывается это связано с некой спецификой при загрузке property-файлов и работы PropertyPlaceholderConfigurer-ов. На форуме Spring'а есть несколько тем и даже запросы в джире на изменения, но все мимо. На помощь приходит SpEL - Spring Expression Language, появившийся в Spring 3. С его помощью проблема решается просто и элегантно. Вот так:

Объяснения требует лишь одно выражение:

Здесь решетка означает, что дальше идет SpEL, а дальнейшее - это доступ к бину и его свойству. Вот все просто получилось, благодаря третьему Spring.

Wicket работа с Ajax

2010-04-21T10:56:00.000-07:00

Рассмотрим как работает Wicket с Ajax. Для демонстрации рассмотрим следующий пример: при нажатии на гиперссылку, меняется содержимое другой области страницы.
Шаблон страницы:

Класс страницы:

Из кода видно, что при клике на гиперссылке, происходит ajax вызов метода onClick класса гиперссылки. Внутри этого метода обновляется значение поля totalAmountLabel. Чтобы обновление действительно произошло нужно вызвать target.addComponent(). Конечно, таким образом можно обновлять и поля формы, в зависимости от изменений других полей.

Wicket кастомизация html при рендеринге компонентов.

2010-04-19T03:10:00.000-07:00

Зачастую при написании приложений на основе компонентных фреймворков, стандартный шаблон компонента требуется подправить. Например, поменять стиль, динамически вставить дополнительный элемент html разметки. В этой статье я разберу как это можно сделать в Wicket.

В базовом классе Component есть два метода для динамического добавления/изменения содержимого компонента:

Этот метод позволяет изменять содержимое компонента, то есть добавлять новые теги или заменять их.

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

Рассмотрим случай, когда по какой-то причине мне нужно добавить атрибут class со специфичным значением в компонент AjaxFallbackLink.

Код довольно прост. В заивсимости от какого-то условия я добавляю (или меняю уже существующее значение) атрибута class у тега гиперссылки. Аналогичным образом можно удалить этот же атрибут. Для этого можно использовать следующий метод:

Теперь рассмотрим случай, когда ссылки добавляются динамически. Из предыдущей статьи известно что для этого используется вспомогательный компонент RepeatingView. Проблема в том, что компонент-ссылка содержится в WebMarkupContainer, а последний в RepeatingView. И сразу непонятно где именно нужно переопределять метод onComponentTag, чтобы добраться до самой ссылки. Опытным путем я пришел к тому, что переопределять его нужно так же в самой ссылке. Не знаю почему, но для меня это было неочевидно. Я перепробовал варианты с переопределением этого метода как для RepeatingView, так и для WebMarkupContainer. В итоге пришел к самой ссылке.

Рассмотрим пример с изменением содержимого тега компонента.

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

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

Wicket Работа с динамическими списками элементов

2010-04-15T22:14:00.000-07:00

Теперь, когда я рассказал про общую концепцию, установку и валидацию в Wicket, перейдем к работе с его компонентами.

Задача. Необходимо отображать данные, количество которых меняется, то есть неизвестно заранее сколько их будет. Это может быть таблица товаров, перечень допустимых действий над объектом или что-то еще. Все это объединяет тот факт, что мы не знаем в момент написания шаблона, сколько табличных или списочных элементов нам понадобится.

Для этих целей используется компонент RepeatingView, он не отображается сам при отрисовке страницы. Его основное назначение - быть контейнером для динамических данных.

Сразу перейдем к примеру и его объяснению. Я буду отображать на странице некие статические данные (понятно, что здесь может быть вызов сервиса, предоставляющего данные из базы). Шаблон страницы (Example.html) выглядит так:

Шаблон довольно простой. Стоит заметить, что для всех элементов, содержащихся в interestLinksList будут повторяться только внутренние элементы. То есть span повторяться не будет.

Рассмотрим класс страницы.

Теперь разберем этот код более подробно. Класс ListItem вспомогательный. Он создан лишь для удобства работы со списками. Статическая константа LIST необходима тоже лишь для демонстрации, поскольку в обычном приложении будет использоваться поставщик данных из сервис слоя. Более интересно наличие промежуточного компонента WebMarkupContainer. Этот компонент необходим для того, чтобы Wicket мог отличить различные элементы динамического списка. Для этого разработчик создает этот промежуточный компонент и устанавливает ему id с помощью вызова

Замечу, что в Tapestry 5, этот процесс автоматизирован и скрыт от глаз разработчика, что, по моему мнению, является правильным шагом. Здесь же нужно это делать самому. Таким образом после выполнения программы мы получим страницу, содержащую html примерно такого вида:

Уникальные id я опустил. Главное, что нет никаких вспомогательных тегов и повторяющийся контент содержится внутри основного тега контейнера. RepeatingView точно также можно использовать и с повторяющимися элементами формы. Я покажу это в статьях, посвященных различной работе с формами.

Wicket - первое приложение.

2010-04-14T02:10:00.000-07:00

Собственно с этой статьи и надо было начинать рассказ про Wicket, но лучше поздно чем никогда. Итак, я предполагаю использование maven. Cтруктура каталогов соответствующая.

1. Добавляем в pom.xml зависимость:

Сюда же можно добавить поддержку wicket-security, но об этом я расскажу в статьях, посвященных интеграции с этой подсистемой.

2. Создаем страницу Index.
Общее описание коцепций я приводил здесь. Ниже шаблон и класс страницы, а так же properties файл.
Шаблон

Класс страницы.

properties файл.

3. Создаем класс WicketApplication.
Это класс расширяет WebApplication, в котором находятся методы, управляющие различными свойствами Wicket приложения. Я в нем хочу переопределить то какую страницу Wicket будет отдавать как "домашнюю".

Класс WebApplication содержит много интересных методов. Я буду разбирать их в следующих статьях на тему Wicket.

4. Добавить WicketApplication в spring контекст.

5. Изменить web.xml.
Он должен иметь следующий вид:

Здесь требуется пояснение. Первая строка необходима, чтобы загрузить в контекст бин wicketApplication. SpringWebApplicationFactory - это реализация интерфейса IWebApplicationFactory, позволяющая получать WebApplication объект из контекста Spring.

Теперь после запуска приложения, мы всегда будем попадать на стартовую страницу.

Wicket - Специфика работы с валидаторами полей и ошибками

2010-04-12T01:46:00.000-07:00

Задача. Обеспечить проверку данных, вводимых в форму, а так же информирование об ошибках ввода.

Информирование об ошибках.
Чтобы ошибки отображались в форме, нужно добавить FeedBackPanel как в шаблон, так и в класс страницы.

Обязательные поля
Если поле является обязательным, то можно выделить его с помощью "красной звездочки", но выделение это выглядит не очень красиво.Для этого используется FormComponentFeedbackBorder. Ниже пример использования

Можно вместо звездочки сделать свою разметку.

Валидаторы.
Базовые валидаторы Wicket достаточно скудные. Мне в конкретной задаче понадобился валидатор, который проверяет, что поле содержит ровно 12 цифр. Оказалось, что для этого нужно писать собственный валидатор. Ниже я привожу сам валидатор, класс страницы.

Остановимся чуть подробнее на этом классе. Конструктор принимает имя поля, на которое навешивается валидатор и размер этого поля. Метод непосредственно осуществляющий проверку не представляет особого интереса, в нем вызывается метод error, записывающий ошибку в feedbackpanel данной формы. Тут нужно заметить, что если Вы забыли добавить компонент FeedBackPanel в форму, то ошибку Вы не увидите, хотя валидатор отработает и не допустит некорректного ввода в форму. Метод resourceKey возвращает префикс, с которого начинается локализованное сообщение об ошибке, хранящееся в properties - файле страницы.

Ну и последний метод предоставлет значения для замены placeholder'ов в сообщении об ошибке. Теперь остается подключить валидатор к полю:

Те кто имеют опыт работы с Tapestry оценят насколько Wicket отстает в развити от данной технологии. Для Tapestry такие валидаторы писать просто нет нужды, все уже сделано за нас.Сравнение этих технологий я проведу позднее. А пока про валидаторы все.

JPBM - часть 6 - производительность.

2010-04-09T03:16:00.000-07:00

После пяти статей про JBPM самое время написать про основную фобию разработчиков перед такого рода движками - ПРОИЗВОДИТЕЛЬНОСТЬ. Именно это магическое слово я слышу каждый раз когда речь заходит о workflow или process management продуктах. Одной статьей развеять эту убежденность не получится, но я все же попробую начать.

Я провел несколько тестов. В чем они заключались? На входе имеем сервлет, обрабатывающий запросы следующим образом: на основе входных параметров(v1, v2, v3), создается объект и передается в экземпляр процесса, который после этого запускается. Использовался типовой процесс бизнес-приложения(25 нодов, в среднем 10 переходов). Сервер приложений jboss-5.0.1.GA . Для тестирования использовался Jmeter. Тест состоит из трех ThreadGroup, каждая из которых содержит 100 пользователей, посылающих запросы в систему.

Тестирование отклика системы.
Проверялось сколько запросов система готова обработать за единицу времени. Рассматривались два случая: асинхронное и синхронное исполнение процесса со стороны JBPM. В первом случае сервлет заканчивал обработку запроса запуском процесса, после чего последний выполнялся в отдельной нитке. Во втором варианте сервлет ожидает окончания исполнения процесса и только после этого заканчивает обработку входящего запроса.

Синхронное исполнение

Из таблицы видим, что в этом случае обрабатывается 10.1 запроса в секунду. Максимальное время исполнения процесса 3 секунды, минимальное 10мс. 90% запросов исполняются за время < 1с.

Асинхронное исполнение

Видим, что разница в 9.5 раз по скорости, имеем 95.2 запросов в секунду. Максимальное время исполнения процесса в данном случае - 30 секунд. Минимальное -
100мс. 80% запросов исполняются за время < 1 c.

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

XML - интерфейсы WebMoney и Java

2010-04-09T01:29:00.000-07:00

У WebMoney есть X-интерфейсы. Они предназанчены для того, чтобы программным способом взаимодействовать с этой платежной системой. Выставлять счета, получать различную статистику.

При этом порядок работы разный и заивсит от того как вы проходили регистрацию в платежной системе. Если через Light, то у вас p12 ключ и некоторые параметры (ваш wmid и подпись через Signer) передавать не надо. Если регистрация проходила через Keeper Classic, то у вас kwm ключ, и вам необходимо указывать ваш wmid и подписывать сообщения через Signer.

Для работы через эти интерфейсы есть хорошая библиотека WebmoneyJava Я работал через нее. Кошелек был зарегистрирован через Keeper Light. Но тут мне понадобилось перевести приложение на другой акканут, который был зарегистрирован через Keeper Classic. Вот тогда и началаись проблемы. Чтобы работать c ключами classic, необходимо:

Сохранить ключ из кипера в файл.
С помощью KeyExtractor преобразовать этот ключ в Base64
Положить получившийся файл в то место где его будет видеть сервис. Указать путь к нему в самом сервисе.

Трудности начинаются со второго пункта. Я тщетно пытался найти на сайте WebMoney ссылку на приложение KeyExtractor. После долгих поисков, я все же ее нашел. KeyExctractor можно скачать здесь.

Дальше меня поджидала еще одна проблема: выяснилось, что изменился формат хранения classic ключей. Сейчас KeyExtractor преобразует их в xml Base64. Таким образом библиотека webmoneyjava не работала с новым представлением classic ключей. Я нашел обновленную версию соответствующей библиотеки, написанной на C#. После чего поправил код webmoneyjava. Исправления затронули :

SignerImpl
wmsignerjx.Signer
wmsignerjx.Montgomery

Ниже я привожу код изменненых классов.

Теперь можно смело использовать соответствующий сервис для работы с Classic ключами.

JBPM - Часть 5 - Интеграция со Spring.

2010-04-02T05:39:00.000-07:00

Если использовать стандартный механизм взаимодействия с JBPM, то дотсуп к основным объектам фреймворка получается не очень удобным способом. В моем приложении активно используется Spring, поэтому я решил получать доступ к JBPM через него. Посмотрим как же этого добиться.

Мне необходимо работать со следующими операциями:
- Деплоить процесс или несколько процессов
- Запускать процессы
- Возобновлять процессы, находящиеся в ожидании.

Для этих целей я ввел два интерфейса: DeployService, ProcessService. Их код представлен ниже.

В реализации DeployService используется реализация JBPM интерфейса RepositoryService. А в ProcessService добавляется использование ExecutionService. Ниже приводится реализация этих интерфейсов.

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

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

Вот и все. Теперь я могу спокойно деплоить процессы с помощью

и запускать например так

Вот такая достаточно простая интеграция получилась.

Wicket первое знакомство

2010-03-31T10:58:00.000-07:00

Среди множества web-framework-ов мне встретился Wicket. Более детальное описание данного фреймворка, а также цикл статей, сравнивающих его с Tapestry впереди. В этой заметке я сделаю краткий обзор технологии.

Общая концепция wicket
Общая концепция схожа с Tapestry: страница формируется из шаблона страницы (MyPage.html), класса страницы (MyPage.java) и файла свойств (MyPage.properties). Шаблон страницы содержит обыкновенную html-разметку, в которую встраиваются wicket - компоненты. Достигается это добавлением специфичного атрибута wicket-id в обычные html теги. Класс страницы должен содержать все компоненты, указанные в шаблоне. Создаются они аналогично Swing приложению. Каждый должен быть явно создан и добавлен в страницу, в противном случае при попытке создания страницы в runtime wicket не найдет соответствия между шаблоном и классом страницы. Наконец, файл свойств необходим для локалилзации сообщений, выводимых на странице.

Пример обычной страницы приведен ниже:
Шаблон

Класс страницы:

Файл свойств

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

Обновление файла конфигурации без перезагрузки сервера.

2010-03-21T06:30:00.000-07:00

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

Для этих целей подходит удобная библиотека commons-configuration от apache. В ней есть различные интерфейсы позволяющие работать как с файлами свойств (*.properties), так и с xml файлами. Предположим, что мы храним справочную информацию в файле help.xml. Ниже приводится код, позволяющий подгружать актуальный файл при каждом обращении к нему.

Теперь каждый раз когда будет происходить обращение к файлу, будет проверяться время его последнего изменения и данные будут всегда актуальны.

Но это не все. Нужно чтобы этот код вызывался периодически, чтобы обновлять in-memory модель данных, которая строится на основе этого файла. Для достижения этой цели я использую job, spring и qwartz.

HelpLoader - класс, реализующий метод loadHelp. Остальной код - обвязка этого класса, позволяющая вызывать метод loadHelp каждые 50 секунд.

JBPM - часть 4 - язык описания процессов JPDL.

2009-08-18T05:29:00.000-07:00

jPDL – язык исполнения процессов с великолепными возможностями моделирования, прозрачной интеграцией с Java и великолепными возможностями управления заданиями. Цитата с сайта JPDL .

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

Действия, отвечающие за управление потоком исполнения процесса.

1 <process> - начальный тег описания процесса.

2 Действия, управляющие потоком исполнения:
2.1 <start> Указывает точку входа процесса. Она должна быть только одна и только один переход может указываться внутри нее.

2.2 <state> Действие, означающее ожидание вызова внешнего тригера, который будет предоставлен через JBPM API. Данное действие не содержит никаких атрибутов или внутренних элементов. Есть две разновидности этого типа: последовательность (state sequence) и выбор (state choice). Отличие в том, что в первом случае указывается лишь один transition внутри state, а во втором их может быть несколько. В зависимости от того, что вернет внешний тригер будет выбрана та или иная ветка исполнения.

Примеры обоих вариантов:
1) sequence of states

signalExecutionById(executionInA.getId()) - это как раз метод инициирующий вызов внешнего тригера.

2) state choice

Здесь указывается по какой ветке будет переход (строчка "accept").

2.3 <decision>
Имеет несколько исходящих переходов. Когда достигается данное действие, то автоматически вычисляется какой из переходов будет выбран для дальнейшего исполнения процесса.
Возможны три варианта использования этого действия:

2.3.1 Decision conditions.
В этом случае внутри каждого перехода указывается condition (условие). Выбирается тот переход для которого либо выполнено условие, указанное в нем, либо переход без условий.

content - параметр, передающийся в процесс при его запуске.

2.3.2 Decision expression
Аналогично предыдущему, но выражение вычисляется на уровне decision, результат вычисления - строка, сравнивается с возможными переходами.

2.3.3 Decision handler
Это Java класс, который реализует интерфейс DecisionHandler, где программно можно определить в какую сторону пойдет дальнейшее выполнение процесса.

2.4 concurrency
С помощью элементов fork и join можно добиться параллельного выполнения действий. В join могут заходить несколько переходов, что и дает параллельность.

2.5 <end>
Окончание исполнения. В общем случае при окончании ProcessInstance принудительно заканчиваются все параллельно выполняющиеся действия. Но можно указать, что окончиться должно только то "исполнение" execution, которое достигло конца, а остальные должны продолжиться. Для этого есть атрибут ends у тега end.

ends{processinstance|execution}
Так же возможны множественные end в конце процесса. Еще можно с помощью атрибута state типизировать окончания.

2.6 <task>
Создание задач для пользователей.

2.7 <sub-process>
JBPM позволяет определять общие процессы в отдельных файлах и запускать их из других процессов с помощью данного тега. В подпроцесс можно передавать параметры через механизм переменных.

2.8 <сustom>
Позволяет использовать пользовательский код. Классы, реализующие ExternalActivityBehaviour.

Я рассмотрел действия, отвечающие за управление потоком исполнения процесса. Так же есть ряд "автоматических" действий: java, script, hql, sql, mail.
Их я не буду рассматривать в этой статье, чтобы не перегружать ее. Вернусь к ним позднее. На этом краткий обзор языка jPDL закончен. В следующей статье разберу как интегрировать JBPM со Spring и Hibernate.

p.s. Примеры xml описаний взяты из официальной документации движка.

JBPM - часть 3 - Краткое описание запуска процессов в JBPM.

2009-08-18T04:59:00.000-07:00

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

Общее представление о деплое и запуске процессов.

Важны три момента:
1. Доступ к JBPM идет через сервисы. Заявляется, что это одно из основных отличий от предыдущей версии движка.
Доступ к сервисам из приложения можно получить используя ProcessEngine, который ThreadSafe и его можно использовать через все приложение. Создается следующим образом:

2. Deploy процессов в jbpm.
Это процесс сохранения описания процесса в БД, которую использует JBPM. Для этого используется RepositoryService, получаемый через ProcessEngine.

3. Запуск нового экземпляра процесса.
Экземпляр процесса (Process Instance) -это отдельный поток исполнения описания процесса, для конкретных данных.
Запускается он через вызов метода сервиса ExecutionService:

тут есть несколько способов запуска:

a) последняя версия процесса

b) Специфичная версия процесса

с) С пользовательским ключом

При старте процесса можно указать ключ, уникальный для этого описания процесса. Потом к запущенному экземпляру процесса можно будет получить доступ через этот ключ {process-key}.{execution-id}.

В качестве такого ключа удобно использовать id объекта, участвующего в процессе. В таком случае можно легко узнать состояние процесса в любой момент его исполнения.

JBPM - часть 2 - установка и настройка.

2009-08-14T05:57:00.000-07:00

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

Что понадобится для запуска.

Ant (да-да, не naven, что меня тоже очень удивило)
JBoss. JBPM может быть развернут и под Tomcat, но по умолчанию идет простая интеграция с JBoss. Для развертывания под Tomcat нужно чуть больше действий руками. (Для любопытных, в моих следующих статьях jbpm будет развернут как раз под Tomcat 6.)
СУБД. Я предпочел PostgreSQL. Можно воспользоваться и HSQLDB с которой поставляется JBPM.
Драйвер для выбранной СУБД
дистриубтив JBPM

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

1. Распаковать дистрибутив в выбранную директорию. После развертывания дистрибутива, мы увидим следующую структуру каталогов:

Если предположить, что мы просто хотим запустить тестовый пример, то этого достаточно. Но мы хотим создать среду для дальнейшей разработки нашего собственного
проекта. Поэтому наши дальнейшие действия будут отличаться от мануала к тестовым примерам.

2. Установить JBOSS. Просто распаковать архив в выбранную директорию.

3. Установить ant. (если у вас его еще нет.)

4. Установить соответствующую СУБД

5. Создать в СУБД пользователя jbpm

6. Под пользователем jbpm создать базу jbpmdb

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

8. Положить jdbc драйвер для СУБД в [jbpm home dir]/lib

9. Создать в директории [jbpm home dir]/jboss файл build.properties
Этот шаг требует пояснения. Дело в том, что некоторые умолчания, используемые при сборке, нас не устраивают. По умолчанию считается что jboss установлен в директорию [jbpm home dir]/jboss-5.0.0.GA, что версия сервера 5.0.0.GA и СУБД HSQLDB. Создавая такой файл, мы переопределяем эти свойства сборки:

10. Инсталировать JBPM в JBOSS.
Для этого нужно исполнить команду

11. Запустить JBOSS.

После выполнения вышеописанных действий, под JBOSS будет запущено приложение JBPM, которое будет доступно через jndi. В нашем приложении мы сможем использовать JBPM именно через доступ по jndi. Имеется в виду, что получение объекта ProcessEngine (входная точка для работы c JBPM), будет осуществляться через следующую конструкцию:

Стоит отметить, что вместо файла build.properties все параметры можно указывать в командной строке, но мне это кажется неудобным, поэтому был выбран иной способ.

Вот собственно и вся установка JBPM.

JBPM - часть 1 - process management engine от JBOSS.

2009-08-14T01:55:00.000-07:00

Аббревиатуру JBPM видели и слышали многие. До реальной работы с этой технологией у меня руки не доходили.
Но вот недавно вышла четвертая версия продукта и мне посчастливилось ее использовать.
Я начинаю цикл статей о JBPM 4. В этой я дам краткий обзор технологии.
В следующих материалах будут освещены вопросы создания приложения с использованием JBPM4, возможностей языка описания процессов JPDL, взаимодействия с JBPM через Spring.

JBPM - по своей сути является платформой, обеспечивающей исполнение процессов, описанных с использованием языков описания процессов.
Языков три: jPDL, BPEL и Pageflow.

jPDL - это собственная разработка JBOSS
BPEL - это стандарт описания процессов.
Pageflow понятно из названия, что это за процессы. Примером для последнего типа процессов может служить Tapestry.

На BPEL я останавливаться не буду, поскольку не использовал его.
JBPM позовляет автоматизировать исполнение процесса, представленного в виде xml описания(jPDL). Основные преимущества:

Гарантируется сохранение состояния процесса в его промежуточной точке.
Возможность асинхронного исполнения процессов.
Версионность описания процесса
Возможность использование листенеров на входе, выходе из узлов процесса и в других случаях.
Заведение в системе пользователей, назначение им заданий и уже готовый gui отображающий их для каждого пользователя.
Поддержка рассылки email сообщений о назначении пользователям заданий.
Интерфейс администратора, позволяющий отслеживать состояния запущенных процессов и тех, что уже исполнились.
Возможность использования скриптового языка jUEL.
Запуск как отдельным приложением, так и внутри вашего приложения.

Как видно плюсов у технологии достаточно много, поробуем их разобрать более подробно в последующих статьях. А что же насчет минусов?
Основное опасение разработчиков при использовании таких технологий как JBPM, OSWorkflow и т.п. состоит в том, что они считаются медленными.
Моя дальнейшая работа с JBPM позволила мне усомниться в этом. Результаты тестов, будут приведены в следующих статьях.

Начнем.

2009-08-14T00:56:00.000-07:00

Всем привет. В этом блоге я буду писать о различных технологиях, используемых в веб-разработке. Так же не буду избегать
текстов, связанных с общими вопросами программирования на языке Java, работы с БД, создания инфраструктуры разработки и прочих околоразработческих тем.