Earlier this year we started the Report Builder 7.0.3 Beta, and the user productivity improvements introduced in managing, scheduling, and exporting reports are on track for general availability with IBM Engineering 7.0.3 later this year. Now, we are adding another reporting beta, this time with the goal of improving the scalability of the Jazz® Reporting Service (JRS) Lifecycle Query Engine (LQE) and at the same time requiring less system resources for LQE’s data store. LQE used Apache Jena to store the engineering lifecycle data for reporting with Report Builder and Engineering Insights since its inception. Apache Jena served us well, however, as a file-based data store, it has scaling limitations, and it requires significant system resources, especially RAM. Customers with many projects and applications are reaching the limits Apache Jena can comfortably offer. So the JRS team is working to replace Apache Jena in a way that is incremental, measured, predictable, and consumable for IBM Engineering admins and practitioners.

The LQE performs several activities to build and make available its engineering knowledge graph:

1. Periodically read the OSLC Tracked Resource Set (TRS) feed of each application (DOORS Next, Workflow Management, Test Management, etc.) to gather the initial set of resources from each application, as well as changes over time.
2. Fetch any new or changed resources from the application.
3. Store the resources in the LQE data store.
4. Calculate a unified type system metamodel for all sources and data.
5. Accept queries from Report Builder, Engineering Insights, or other clients and provide the requested data from the LQE data store.

JRS 7.0.3 M36 is introducing as beta, the ability to use a relational database as the LQE data store, part of the activity (3), alongside the existing LQE Apache Jena (LQE Jena) data store. When this capability is configured and you author a report, you can switch between the SPARQL based query (LQE Jena) and the SQL query (LQE rs). You can also run a comparison on the report which as a result shows the difference in elapsed time and any result differences.

The Lifecycle Query Engine relational store (LQE rs) beta solution offers two deployment topologies:

• Topology 1 employs two LQEs, one each for LQE Jena and LQE rs. This is the preferred topology since it provides separation between LQEs and it provides the most accurate report query timings. On the other hand, it is a bit more complex to install and it requires an additional server.

• Topology 2 places LQE Jena and LQE rs on the same server. In this case, timing results may not be the most representative since queries against the data stores can compete for resources on a busy LQE (updating data for both data stores as well as serving queries). On the other hand, it is a simpler installation process.

In addition to understanding the topology options, LQE rs administrators should review LQE rs system requirements, installing and enabling LQE rs, and limitations of the LQE rs. We have also prepared an LQE rs performance report with the results of the performance testing, as well as LQE rs database sizing, both must be read if you are planning to take advantage of LQE rs.

Reporting users should also review the limitations of the LQE rs and be aware of a couple of details:

• Reports created using the Report Builder UI are automatically converted when the user changes query language from SPARQL to SQL if reports do not use custom expressions or advanced queries. You select query language under Choose a report type. After this change, a report is ready to be run against LQE rs.

• If your report is using custom expressions or an advanced query, then you will need to make some adjustments. We recommend adding the relevant SQL statement in addition to the SPARQL so that you can run the report both ways. Eventually, once you are happy with the SQL, you can remove the SPARQL. You can read more on this topic in working with LQE rs reports.

You might ask yourself: How would I know whether a report’s results are the same using SQL and SPARQL? To answer this question we provide an option to Compare query results. Compare query results first runs the SPARQL based version of the report against the Apache Jena store, then it runs the same report with a SQL query against the relational store. Then it compares SPARQL and SQL results row by row. The comparison summary includes information on whether SPARQL and SQL queries matched, the run time of each query and if there are results differences, the list of the result differences. In the event that the Compare query results show differences, you can download the detailed list of differences. To learn more, I suggest reading about how to check or prepare a report for query results comparison from LQE relational store.

You can post LQE rs questions on the jazz.net forum by setting JRS and LQE tags. In case you believe you found a defect, you can create a defect work item by using the following steps:

• Click the link to create a JRS defect
• Set Found In to 7.0.3
• Set How Found to LQE rs beta
• Set Filed Against to Lifecycle Query Engine
• Add title, a detailed description of how JRS developers can reproduce your encountered LQE rs issue.

The JRS team is highly invested in developing this functionality and we welcome your feedback on how to further improve LQE rs. You can share your suggestions by clicking the Share feedback link directly or you can find the same link under Report Builder LQE rs beta icon. As always, we are here to help you, so don’t hesitate to reach out.

Fariz Saracevic
IBM Engineering Reporting (JRS, PUB, ENI) Product Management.