Интеграция Crystal Reports с приложением J2EE: анализ практического примера

Оглавление

Введение

Мы выбрали Java-компонент генерации отчетов для Crystal Reports, потому что этот компонент соответствует всем нашим требованиям. Кроме того, он является проверенным, ведущим в своей области продуктом, для которого существует целый спектр дополнительных инструментов. Это было важным аргументом, поскольку мы хотели, чтобы наше решение для генерации отчетов могло расти по мере расширения требований к TWB.

Сначала мы создавали отчеты в TWB при помощи серверных страниц JSP, однако такой подход оказался неприемлемым по временным затратам, особенно в случае сложных отчетов, поэтому мы стали искать Java-решение для генерации отчетов в рамках web-приложений. Наши основные требования были таковы: решение должно позволять легко и быстро создавать и редактировать отчеты и с минимальными трудозатратами интегрироваться с платформой J2EE.

Рисунок 1. Task Workbench отображает задачи сотрудников и количество часов, потраченное на каждую задачу.

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

Task Workbench - это средство управления рабочим процессом, которое в реальном времени предоставляет информацию о проектах и ежедневных операциях. Это сетевое приложение, которое использует JSP на презентационном уровне и EJB на уровне бизнес-логики. Используется принцип сохранения состояния, управляемого контейнером (Container-Managed Persistence - CMP) при помощи корпоративных компонент с данными (Enterprise JavaBeans - EJB), отображенных на реляционную базу данных Oracle.

Здесь мы описываем свой опыт интеграции Crystal Reports с J2EE приложением Task Workbench (TWB). Цель этой статьи - дать представление о преимуществах и недостатках использования Crystal Reports в контексте приложения на платформе J2EE.

В первом разделе кратко обсуждается исходный способ генерации отчета при помощи написанного вручную кода JSP, а также описаны проблемы, с которыми мы столкнулись при таком подходе. В следующем разделе объясняется, почему мы выбрали Crystal Java Reporting Component для генерации отчетов. Остальная часть статьи посвящена тому, как мы интегрировали Crystal Reports с TWB и более подробному обсуждению "за" и "против" использования Crystal Reports.

Начальная реализация системы генерации отчетов

Более ранние версии TWB проводили генерацию отчетов при помощи написанного вручную кода JSP. В большинстве случаев по причинам поддержания необходимой производительности для получения данных и непосредственного подключения к СУБД использовался интерфейс JDBC. Дополнительным преимуществом такого способа генерации отчетов было наличие запросов от предыдущего приложения, и эти сложные запросы уже были проверены на правильность.

По ряду причин такой подход быстро стал проблематичным.

  • Оптимизация запросов была затруднена вследствие того, что запросы приходилось динамически менять на основании многочисленных настроек отчетов.
  • Трудозатраты для отчетов с группированными данными оказались неприемлемыми.
  • У нас не было практичного способа составлять прототипы отчетов на случай неясных или меняющихся требований. Это не способствовало экспериментированию и привело к тому, что некоторые отчеты не вполне соответствовали требованиям заказчика.
  • Техническое обслуживание стало занимать очень много времени, по мере того как менялась схема, и вводились новые функции.
  • Настройка выходных параметров отчетов согласно конкретным требованиям (например, для печати) занимала много времени.

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

Из-за этих проблем стало очевидно, что нам требуется гораздо лучшее решение для приложений генерации отчетов. Нам надо было найти способ составлять более подробные отчеты с меньшими затратами. За этим решением мы обратились к системе Crystal Reports.

Выбор решения для генерации отчетов

Трудности, с которыми мы столкнулись при работе с JSP в TWB, заставили нас искать лучшие решения для генерации отчетов. Согласно нашим требованиям, такое решение должно обладать следующими характеристиками:

  • иметь визуальный редактор отчетов, позволяющий быстро и легко создавать и изменять отчеты;
  • генерировать отчеты презентационного качества как на экране, так и при распечатывании;
  • иметь возможность генерировать групповые отчеты с графиками;
  • получать данные отчетов через экземпляр javax.sql.DataSource или JDBC-соединение;
  • быть полностью написанным на Java.

Мы рассматривали другие пути с использованием открытых исходных текстов, такие как Jasper Reports. Тем не менее, мы убедились, что ни один из таких вариантов не соответствовал нашим основным требованиям к визуальному редактору отчетов, и мы сочли маловероятным, что они способны обеспечить достаточно совершенные решения без большого объема дополнительной работы. Мы отдали предпочтение решению, основанному на Crystal Reports, потому что мы уже оценили эффективность этой системы при работе над другими проектами.

Существует три класса решений генерации отчетов от Crystal: Java Reporting Component, Report Application Server (RAS), и Crystal Enterprise. Java Reporting Component предоставляет простое, полностью основанное на Java решение для просмотра отчетов в случаях, когда низка вероятность одновременной работы с отчетом и не требуются возможности для управления отчетами. RAS обеспечивает базовый набор сервисов для локальной и удаленной обработки, просмотра и изменения отчетов. Так как обработка отчета выполняется по требованию, RAS лучше всего подходит для небольших наборов данных и небольшого количества одновременно работающих пользователей. Crystal Enterprise - это набор продуктов с возможностями, рассчитанными на поддержку больших систем с более серьезными требованиями. Основные возможности Crystal Enterprise включают управление загрузкой (кластеризация, планирование отчетов и т.д.), доступность (отказоустойчивость) и защиту на уровне строк и столбцов.

Мы выбрали Crystal Java Reporting Component для TWB, потому что это решение соответствовало всем нашим требованиям, кроме того, по нашим прогнозам количество пользователей, одновременно работающих с отчетом, должно было быть невелико. Нам также не были нужны расширенные интерактивные возможности для работы с отчетами, поскольку пользователям достаточно было иметь только основные возможности просмотра и печати отчетов.

Реализация

Crystal Java Reporting Component была встроена в TWB с намерением достичь двух основных целей. Первая состояла в том, чтобы разработка предусматривала минимальные трудозатраты для добавления новых и поддержки существующих отчетов. Вторая состояла в том, чтобы можно было достаточно просто осуществить переход к более совершенному решению для составления отчетов Crystal, такому как Crystal Enterprise, обеспечив таким образом масштабируемость системы.

Crystal Java Reporting Component имеет библиотеку JSP дескрипторов, которая предоставляет простой способ отображения основных отчетов, а в случаях, когда требуются дополнительные функции, обеспечивает прямой доступ к API. Мы решили применить JSP дескриптор собственной разработки, который использует Crystal Reporting Component для отображения отчетов. Такой подход дал нам возможность настраивать внешний вид отчетов и задавать их параметры, не усложняя дизайн и техническое обслуживание системы.

Простоту такого подхода иллюстрирует тот факт, что единственный Java код, использованный в JSP - это простой метод, вызывающий класс фабрики (factory class) для получения экземпляра отчета, который следует отобразить на странице. Рисунок 2: simple_banked_time_report.jsp является типичным примером JSP, который может использоваться для запроса отчета. Эта форма передает необходимые параметры view_report.jsp (Рисунок 3).

Рисунок 2. Simple_banked_time_report.jsp, пример простой формы, которая может использоваться для отображения отчета.

Рисунок 3. View_report.jsp, JSP, использующийся для отображения отчета.

Класс ReportFactory создает экземпляр отчета, используя содержащиеся в запросе параметры для определения типа создаваемого отчета и создания параметров отчета (см. Рисунок 4). При таком подходе вся деловая логика, характерная для отдельного отчета, целиком содержится в одном методе. Методы фабрики для отчетов более сложных типов лучше всего реализуются в подклассе ReportFactory, после чего ReportFactory может передавать полномочия подклассу при создании отчета такого типа.



Рисунок 4. ReportFactory.java создает экземпляр отчета на основе параметров, переданных из формы.

Класс SimpleReportViewerTag (Рисунок 5) визуализирует отчет. Это класс использует Crystal Java Reporting Component API для выполнения изображения отчета. Данный класс имеет понятный принцип действия: он создает экземпляр CrystalReportViewer, задает данные соединения с базой данных и параметры, которые требуются для отчета, а затем отображает отчет. Соответствующий TLD, simplereportviewer.tld, показан на Рисунке 6. Такой подход характеризует прозрачность и простота технического обслуживания, так как при таком принципе вся логика для каждого отчета расположена в одном месте.



Рисунок 5 . SimpleReportViewerTag.java - применение специально настроенного JSP тэга для отображения отчета.

Рисунок 6: Simplereportviewer.tld - TLD для расширения дескриптора SimpleReportViewer.

Поскольку TWB позволяет менеджерам проектов только просматривать отчеты, существующие в TWB механизмы контроля доступа были достаточны для контроля доступа к отчетам. Предполагается, что будущая версия TWB может потребовать более тонкого контроля доступа - например, пользователям может быть запрещен просмотр определенных проектов в отчете. Для обеспечения контроля доступа такого уровня мы использовали бы функции защиты Crystal Enterprise.

Оценка реализации

Наша реализация отчетов, в которой совместно используются Crystal Reports и Crystal Java Reporting Component, имела ряд преимуществ и несколько недостатков по сравнению с нашей предыдущей JSP-реализацией.

Самым большим преимуществом была скорость и простота создания визуально привлекательных отчетов. Одним из важных факторов, который определяет скорость создания отчетов, является то, что визуальный редактор Crystal Reports позволяет разрабатывать и редактировать отчеты без необходимости конструировать и распространять TWB. Дополнительное преимущество состоит в том, что простота создания и изменения отчетов означает для разработчика возможность работать, не имея опыта в J2EE, а это значит, что с отчетами могут работать более широкие коллективы разработчиков.

Рисунок 7. Пример интеграции Crystal Report с Task Workbench.

Благодаря Crystal API интеграция отчетов в web-приложение стала очень простой. Использование специального JSP дескриптора сделало ее еще проще. Для отображения отчета теперь требуется совсем небольшое количество кода. Внесение изменений в отчет теперь выполняется почти тривиально. Большое количество времени оказалось сэкономлено также благодаря тому, что нам не пришлось писать код для поддержки таких функций, как печать, экспортирование отчетов, настройка запросов и т.д.

Сравнение трудозатрат по внедрению начального подхода с использованием ручного кодирования JSP и аналогичной разработки с использованием Crystal Reports приведено в Таблице 1.

Как отмечено в данном документе, одна из причин, почему мы выбрали технологию Crystal, состояла в том, что Crystal Decisions (недавно приобретенная компанией Business Objects) предлагает набор средств для решения проблем масштабируемости, в особенности в пакете приложений Crystal Enterprise. Рабочие характеристики, которые наблюдались при использовании Crystal Java Reporting Component, были адекватными нашим текущим требованиям, но при более высокой загрузке нам придется перейти к более мощному решению Crystal. Это изменение будет очень простым благодаря выбранному нами способу интеграции Crystal Reports с TWB. По сути дела, единственные изменения, которые потребуются - это корректировка SimpleReportViewerTag для работы с источником отчетов Crystal RAS (или Crystal Enterprise) и изменение пути к самим отчетам в классе ReportFactory.

Задача Начальный JSP Crystal Reports
Однократнаяустановка/освоение (предполагает знание JSP/java) 3 дня (JDBC, запросы) 4 дня (продукт, интеграция)
Начальная разработка отчетов и реализация 4 дня (страницы ввода и вывода)10 дней (создание и оптимизация запросов,организация возвращаемых данных в соответствии с форматом вывода) 2 дня (страницы ввода - модификация уже существующих) 1 день (Crystal Reports Designer)
Перевод отчетов в формат CSV 8 дней (сводка, созданиеиерархии CSV) 1 день
Интеграция/тестирование/техническое обслуживание 5 дней (введение в подпроекты, группы проектов) 1 день
Всего 30 дней 9 дней

Таблица 1 . Сравнение трудозатрат на реализацию в TWB ручного кодирования JSP и Crystal Reports.

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

Crystal Reports соединяется с базой данных непосредственно при помощи SQL через JDBC. Это обеспечивает более качественную работу отчетов, но ценой зависимости отчетов от схемы базы данных, которая автоматически генерируется и обновляется, когда создаются компоненты CMP (CMP entity beans). Разработчики, ответственные за компоненты CMP, должны помнить об этом при внесении изменений. Использование базы данных непосредственно в контексте приложения EJB может повлечь проблемы, связанные с одновременной работой, поэтому следует проследить за тем, чтобы настройка EJB-контейнера допускала совместный доступ.

Несмотря на отмеченные недостатки, использование Crystal Reports оказалось гораздо лучшим подходом к созданию отчетов для TWB благодаря огромной экономии времени как на стадии реализации, так и на стадии технического обслуживания. Подводя итог, можно сказать, что интеграция Crystal Reports с TWB дала нам возможность достичь превосходной функциональности составления отчетов и создать пространство для будущих модификаций в случае расширения требований - и все это за часть того времени, которое потребовалось на реализацию решения с написанным вручную кодом JSP.

Резюме

Компонента для составления Java-отчетов Crystal Java Reporting Component вполне удовлетворяет требованиям, которые мы предъявляем к совершенному решению для составления отчетов на Java: простота в интеграции с J2EE приложением и генерация высококачественных, легко создаваемых отчетов. Наш способ интеграции с использованием специального JSP дескриптора с классом фабрики обеспечил очень простой способ интеграции Crystal Reports с TWB. Основным недостатком использования Crystal Reports является отсутствие переносимости отдельных отчетов, но масштаб выигрыша в продуктивности, который мы получили, с лихвой окупает этот недостаток.

 


Страница сайта http://www.interface.ru
Оригинал находится по адресу http://www.interface.ru/home.asp?artId=928