Інтеграція 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, змусили нас шукати кращі рішення для генерації звітів. Згідно нашим вимогам, таке рішення має володіти такими характеристиками:



Ми розглядали інші шляхи з використанням відкритих вихідних текстів, такі як 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 є відсутність переносимості окремих звітів, але масштаб виграшу в продуктивності, який ми отримали, з лишком окупає цей недолік.


 

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*