Solution Development Guide

SOLUTION PACKS AND REPORTS

One of the most common types of content that people put in their Solution Packs is Reports and, correspondingly, handling Reports is a little more complex than other content types. First of all, Sentinel has gone through a couple iterations of its back-end report generation engine, and second, the Sentinel platform has gone through some variations on how events are stored. This section will cover some of the details.

Sentinel Reporting Platforms

Up through Sentinel 6.1, Sentinel used Crystal Reports (which became Business Objects, which became SAP) as its back-end reporting engine. In this environment, reports were created using Crystal's designer and were then hosted by a standalone Crystal Report Server. There was some lightweight integration between Sentinel and the Crystal server, mostly just to ensure that reports could be accessed and executed from directly within the Sentinel UI.

With Sentinel Log Manager and Sentinel 6.1 Rapid Deployment, however, the reporting engine was converted to the Jasper Report Engine, which conferred a number of additional benefits. Reports could now be stored, executed, and the results displayed directly within the Sentinel UI, for example, and Jasper's open report format also allowed for many custom report extensions such as query injection, Sentinel-driven report permissions, and so on.

Along with the evolution of the reporting engine has come an evolution in the event storage backend for Sentinel. Older Sentinel versions stored events in a database (various kinds, including SQL Server, Oracle, and Postgres), whereas now Sentinel Log Manager and Sentinel 7 store events in Lucene-indexed files. But even current Sentinel platforms store configuration data and event context in the database, and Sentinel 7 has additionally introduced the concept of Report Data Definitions which can export filtered and/or summmarized datasets from the filestore to the database. Since reports need to query against the appropriate data store, this introduces another variable into how reports are constructed.

Last but not least, Sentinel's basic Event Schema has had some additions and modifications over time, and as a result some reports may have to be careful about what fields they query for on a given platform.

Cross-platform Reporting

So how does all this fit into the Solution Pack framework? First, be assured that all the complexity of the above reporting discussion is fully supported by the Solution Pack framework. Second, note that each particular report self-declares what platform(s) it will run on, and this is something that is set up at the time the report is created. Essentially, you will be prompted for the type of data you wish to display on the report, and based on that an appropriate template (pre-configured for the relevant platform(s)) will be selected and copied as the basis of your new report.

If you only work with a single Sentinel platform, then this is relatively simple: just create each report as needed for your platform. If you intend for your Solution Pack to support multiple Sentinel platforms, however, you may end up needing to create different clones of the same report for each platform, and just change things specifically to work with each platform. The Solution Pack can include multiple "variants" of the same report, and the platform support declarations will ensure that only the appropriate reports are deployed to a specific Sentinel platform.

Solution Pack Report Links

The other hurdle that one faces when working with Solution Packs is to keep Report plug-ins in sync. Without the SDK, any changes to any report require one to make said changes in iReport, save the changes, build the new report (and presumably test it), then start up Solution Manager, delete the existing Report in the target control, and re-add the new report version. When you're working with 10s of reports in a single Pack, this can get somewhat onerous.

Our solution to this is to use Solution Pack Report Links instead of the final Report output when placing a Report in a Solution Pack. The way this works is:

Design and code your report as normal.
Instead of running normal build, right-click on the Report in the SDK and select Create a Solution Pack Report Link. The output will look like a normal Report plug-in, but in fact is a minimal ZIP file that only contains relevant metadata.
Add the Report Link to your Solution Pack in the desired target control.

Once you've done this, any rebuilds of the Solution Pack will automatically cause the SDK to go find the source for your Report in the repository, build the latest version, and replace the Report Link in the Pack with that new build of the Report. This will help ensure that you are always pulling the latest copies of your reports into the Pack. The only scenario where you have to re-do the Report Link is if you change the name, template version, or supported platforms of the Report.

Forward to Additional Information
Back up to Develop to Sentinel