Advanced Reporting in Lombardi

Lombardi provides two flavors for Reporting. Adhoc Reporting let developers create quick charts and graphs in no time, without coding and with minimal configurations. The other flavor is custom reporting which is quite flexible with one or more SQL queries and data transformation logic with filtering of data.

Lombardi documentation provides enough information about creating Adhoc and custom reports. This article is aimed at creating better custom and advanced reports using Lombardi and this is not a tutorial or a guide to create reports. Please browse Lombardi documentation for user guides to create reports. Before getting into Lombardi custom reports, it is imperative for an analyst to understand the Lombardi Performance Data Warehouse Architecture and key concepts in performance reporting.

Basically, reports are just representation of business data, and Lombardi creates reports using business data which are tracked in the business process. Tracing business data is a key concept and in Lombardi business data can be either auto-tracked or it can be manually tracked with tracking events.



Tracking business data manually with tracking events offers several advantages. A tracking group needs to be created for manual tracking, which is used to group similar business data in a business process. From the business process, business data is fed into the tracking group using tracking events. Please see ‘Start tracking GDP’ as tracking event in the above business process diagram. So a tracking event essentially captures business data which needs to be tracked and sends it to the Performance Warehouse DB. In technical terms, a tracking group translates to a database view in Lombardi Performance Warehouse DB. The same is the case for auto-tracked business data, but Lombardi captures auto-tracked events during the start and end of each activity, deteriorating the overall performance of the BPM system. But in manual tracking, tracking events can be placed in business process exactly at an activity where tracking is essential, thereby reducing the round trips between Performance Warehouse server and Process server.

Lombardi comes with default tracking groups such as PROCESSFLOWS, SLASTATUS and SLATHRESHOLDTRAVERSALS. With default tracking groups, reports on SLA’s and violations can be easily created.

In custom reporting, a SQL query needs to be plugged into a chart as data source. The below link has variety of techniques to formulate an SQL query for analysis and reporting. http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/analysis.htm The SQL query needs to be framed with aggregate functions for data columns with a GROUP BY clause as a must. Along with the query, data transformation logic has to be plugged into the data source as well. Lombardi provides around 7 in-house built report transformation services. Analysts can write their own data transformation logic by developing report transformation which parses the data which is fed from the SQL query and then inputs them to a Lombardi JavaScript function addDataToSeries(seriesValue, labelValue, displayValue).

Having created a data source, it’s time to build a chart. Lombardi comes to rescue with 9 default chart layouts defined in Lombardi system toolkit. The input for charts is data source. The data source along with its embedded report transformation logic converts the data into chart. Custom chart layouts can be defined using Chart Definition Language (CDL). Existing Lombardi chart layouts can be altered by replicating their CDL and altering the chart properties.

Finally, one or more charts can be embedded as pages (HTML) and can be published as scoreboards. Below are some of chart samples generated using Lombardi.





Adam Deane had an interesting point to make about business data being not used in BPM Reporting capabilities. Fortunately, Lombardi just does that. Lombardi captures process business data and generates reports out of it. Process business data is captured in performance DB as relational data unlike in process server where process data is persisted as CLOBs and BLOBs.