There are mainly two parts of report development: one is report data preparation, processing the original data into the workable result set of reports, which is usually implemented by using SQL, stored procedures, Java, etc. ; the other is report data presentation, presenting the processed data in the form of chart, which is often realized with reporting tools.

 

As the growth of reporting tools, the efficiency of presenting report data with reporting tools has been very high. Reporting tools like RaqReport can be used to quickly implement even the complicated reports, and the average report developers are capable of using them, so the development cost is already very low due to the bonus brought about by the prevailing reporting tools.

 

Nowadays, the development cost of reports are mostly focused on data preparation. The more complex a report is, the more it will cost. Ordinary report developers are not qualified to handle the complex SQL and stored procedures which are usually passed on to those advanced database technicians like DBA. Therefore the development cost can be very high because of the long-term coding and high-cost staff.

 

The same problem is also notable when we use Java to prepare the report data. Then average report developers are unable to code in Java, so application programmers are needed, which still costs too much. Also, the Java code is generally deployed together with the main program, then the maintenance of report requires the main program operation and maintenance staff involved, further increasing the operation and maintenance cost of reports even more. What’s more, with the popularity of framework technologies such as the separation of front-end and back-end and microservices, this problem is even exacerbated since more and more data preparations are moved in Java.

 

So how to reduce the cost of report data preparation so as to reduce the overall cost of report development?

 

We can refer to the developing process of report data presentation, the emerging reporting tools improving the low-efficiency of earlier-age hard-coded reports (in Java). The instrumentalization of report development is the key to these problems, so report data preparation needs to be instrumentalized as well!

 

esProc SPL is exactly such a computational tool specializes in report data preparation, which is completely open source, free and dependable. With the help of SPL, the concise syntax of esProc, ordinary report developers are capable of preparing report data rapidly. It can also instrumentalize the preparation of report data, and further instrumentalize the entire report development process with reporting tools (the presentation of data), thereby reducing the cost of report development.

 

The reason why esProc SPL can promote the efficiency of data preparation and lessen the developmental cost lies in the following aspects.

 

The agile syntax of SPL

 

The syntax of SPL has more advantages over Java and SQL, which follows nature thinking and codes step by step to complete complex calculations. There are abundant functions for structured data calculation and concise algorithms for data processing in SPL.

 

For example, query the growth amount and sales of each first month compared to the same month of the previous quarter (some months may have no data). The SPL script is as:

 

	A
1	=db.query(“select * from sales”).align@1([1,4,7,10],smonth)
2	=A1.new(#:month,amount,amount-amount[-1]:growth)

 

The simplicity of SPL not only improves the development efficiency, but also lowers the threshold of usage, i.e. the average report developers is able to master it, which costs even less than employing DBA and professional application programmers.

 

The supporting of multiple data sources

 

esProc SPL supports multiple data sources (RDB, NoSQL, Json, CSV, HDFS, RESTful, etc.) and also enables mixed computation across data sources. Try to imagine that the data no longer need to be ETLed from data source to database during report development, naturally then, the development efficiency is improved and the development cost is decreased.

 

Hot switching

 

The interpreted execution of SPL supports hot switching. Previously, the complex reports depend on stored procedures or Java which both need to be complied first to take effect. It is very inconvenient not to support hot switching or hot deployment for those frequently changing reports. However, we can easily implement hot deployment with SPL and further reduce the operation and maintenance cost of report development.

 

In terms of integration in reporting tools, esProc SPL can be used as an embedded JDBC driver integrated with the reporting tools which access the SPL calculations via JDBC in the same way as accessing a database.

 

The instrumentalization of report data preparation (esProc) + the instrumentalization of report data presentation (reporting tools) = extremely low report development cost!