While describing LogiXML's Logi Info, Brian Cox stated "there is still room for improvement on the development end of things." If LogiXML is listening or if my developer peers wish to understand some of the risks, I will describe a few challenges I experienced.

Logi Info Studio is the developers' tool for creating LogiXML's Logi Info reports. Since I am working with Logi Info Studio on one project and Microsoft's Business Intelligence Development Studio (BIDS) (i.e., the developers' tool for creating SQL Server Reporting Services reports) on another project, comparing the two products is natural for me. Examples and descriptions from each developer interface are included.

Element Name Proofing

Consider this simple query using the SQL Server AdventureWorks2008R2 database.

 SELECT JobCandidateID, [Name.Prefix] + ' ' + [Name.FIRST] + ' ' + [Name.LAST] AS CandidateName FROM HumanResources.vJobCandidate 
 

The BIDS developer could either drag CandidateName from the Data Source or type in the data element name. Since Logi Info Studio has no drag & drop functionality, the Logi Info Studio developer types in the data element name. What happens if the developer types in Candidatename (notice the lower case ‘n' in name) in both BIDS and Logi Info Studio?

In BIDS, the developer sees the red underscore signifying a problem with the expression. Even if the developer forced the expression window to close, the report would fail in the previewer of the development environment. There is very little chance of this typographical error slipping through on a production report.

BIDS Expression Window

In Logi Info Studio, the developer sees no indication of any problem. The developer could save and deploy the report with no apparent issue. The tester could execute the report with no error or warning. If an incorrect data element name is used, the Logi Info report simply leaves the field blank without any suggestion that a problem exists. If that data element is sparsely populated, it could take some time before anyone recognizes the defect.

Logi Info Studio Expression Window

Formatting Exports to Excel

Both SQL Server Reporting Services (SSRS) and Logi Info reports can export results to Excel. With SSRS, the developer does not need to do anything special to export a report to Excel. Excel is just one export format which an end user can choose. Even with no custom coding, most SSRS layouts including drill-ups/downs, drill-throughs, colors, data formats, etc. render cleanly to Excel.

In Logi Info Studio, the developer must add an Excel Column Format element to every data cell on the report to ensure the report renders properly in Excel. Data could be numeric at the source and formatted as numeric in the report, but if the developer does not add the proper Excel Column Format element to each report cell as shown in the screen print below, the resulting Excel spreadsheet presents the data as text. In that case, an end-user selecting part of an Excel spreadsheet to sum those values could miss a portion of that selection because some of those values are inadvertently formatted as text even though the values look like numbers.

Excel Column Format Elements

Sort Data Type

Logi Info Studio's Group Filter element shows the same sort of flexibility exhibited by the Excel Column Format. Data could be numeric at the source and in the report cell, but that data could be sorted as text within the Group Filter element. In fact, Group Filter's default behavior is to sort everything as text unless the developer explicitly sets the data type to something other than text within each Group Filter element as shown in the screen print below. The resulting difference is ‘10' appears before ‘2' with default sorting, but 2 appears before 10 when sorting as numeric. Unless the test environment includes numeric values of different lengths, no tester would recognize the problem.

Group Filter Element

BIDS' default sorting is based on the type of the data being sorted. If a BIDS developer wants to sort numeric data as a text value, the developer must explicitly create a new sort expression. As with the data name error example, it would be difficult for a data type sorting error to slip unnoticed into a production report.

Safety Net

Flexibility is one factor I consider when selecting a business intelligence tool. Likelihood for success is the more important factor I consider. What is my likelihood for successfully meeting the business needs? Unless I meet those business needs, I fail.

Logi Info Studio is an extremely flexible tool. In the hands of an experienced developer, the results can be quite impressive. In the hands of a less experienced developer or even a developer who is tired and rushed, Logi Info Studio lacks the sorts of safety nets business intelligence developers have learned to expect. Of course professional developers and testers need to be detail-oriented, conscientious and aware of their tools. To become a favored business intelligence tool, vendors need to include some developer-friendly safety nets to improve the likelihood for success. Without those sorts of expected features, developers and testers face the wrath of business stakeholders as time to market or production defects suffer.

With Logi Info Studio, there is still room for improvement on the development end of things.