Dear Customers,

We have released Aspose.Report 1.1.2

Added: A new dialog in visual designer to allow user create the database connection string.
Added: Enhancement to visual designer for ensure user input multiple lines of value to any report parameter.

Fixed: a bug about the unstallation of old version will remove the dynamic data item types user input inside the visual designer.

Dear Customers,

We have released Aspose.Report1.0.0.  The following is its brief introduction.

As we know, most of business reports are not just based on a static SQL script, they will be varied by different situation such as field column or filter, our RDL element class model allow user to create their own data type and bind the data with our existed report element type. The following is the sample RDL script.

 <?xml version="1.0"?>
 <report name="TestDataBinding" startaction="define_data">
   <reportparameter id="sql.table.name" value="product" />
   <reportaction name="define_data" nextaction="generate_sql">
      <dataitemset id="sql.fields">
         <sqlfield id="sql.fields.1" field="category_name" alias="cat" />
         <sqlfield id="sql.fields.2" field="brand_name" alias="brand" />
         <sqlfield id="sql.fields.3" field="upc_id" alias="UPC" />
      </dataitemset>
   </reportaction>


   <reportaction name="generate_sql" nextaction="format_report">
      <sqlitem root="true">
         <sqlitem begin="select ">
            <reportparameter id="sql.comma" value="" />
            <foreach item="DataItems" variable="sql.fields.counter">
               <dataitems refid="sql.fields" />
               <sqlitem text="${sql.comma}" />
               <sqlitem>
                  <binding sourceid="sql.fields" sourceprop="field" targetprop="text" index="${sql.fields.counter}" />
               </sqlitem>
               <sqlitem text=" as " />
               <sqlitem>
                  <binding sourceid="sql.fields" sourceprop="alias" targetprop="text" index="${sql.fields.counter}" />
               </sqlitem>
               <reportparameter id="sql.comma" value=", " />
            </foreach>
         </sqlitem>
         <sqlitem text="from ${sql.table.name}" newline="true" />
         <sqlitem text=" order by 1" />
      </sqlitem>
   </reportaction>


   <reportaction name="format_report">
      <reportitem label="${sql.table.name}">
         <foreach item="DataItems" variable="sql.fields.counter">
            <dataitems refid="sql.fields" />
            <reportitem>
               <binding sourceid="sql.fields" sourceprop="alias" targetprop="label" index="${sql.fields.counter}" />
            </reportitem>
         </foreach>
      </reportitem>
   </reportaction>
 </report>

And here is log output.

    SqlItem output


        select category_name as cat, brand_name as brand, upc_id as UPC


        from product order by 1


      ReportItem output


         left:0; top:0; width:0; height:0 - (0)brand


         left:0; top:0; width:0; height:0 - (0)UPC


         left:0; top:0; width:0; height:0 - (0)product

Instead of specifiying the customized data types in DataItemSet inside the RDL script, the framework also provide the development API extension to allow developers to write their own functions that could load their own data types into DataItemSet from the database or file and compile the data types and functions into a standalone library.

 <dataitemset id="sql.fields" loadfunc="${sqlfield::insert-fields()}" />

Our RDL element class model provide the support for embedding a RDL script file into another RDL script file, user will benefit from it by sharing the reporting logic among different reports, such as a set of RDL to retrieve the definition from user data dictionary or define the report layout style. The following is the sample RDL script.
 <?xml version="1.0"?>
 <report name="TestNestedReport" startaction="gather_data" >
   <reportparameter id="global.var1" value="test_subreport1" />
   <reportparameter id="global.var2" value="test_subreport2" />


   <reportaction name="gather_data" nextaction="format_report">
     <rdl startaction="subreport2">
            <reportfiles>
                <include name="E:\\reporttools\\data\\SubNestedReport1.RDL" />
            </reportfiles>
        </rdl>
   </reportaction>


   <reportaction name="format_report">
     <log message="format_report" level="Debug" />
   </reportaction>
 </report>

The following is RDL script used by one of unit test cases.

 <?xml version="1.0"?>
 <report name="Simple" startaction="prepare_query"  librarydir="E:\reporttools\src\Aspose\ReportTools\ReportTools.RDLElement\bin\Debug">
   <variable name="var_action_1" value="gather_data" />
   <variable name="var_action_2" value="format_report" />
   <reportaction name="prepare_query" nextaction="check_sql" description="generate the Sql script for reports">
      <log message="generate the SQL for report query!" level="Debug" />
 <!-- Putting the RDL elements that are used for specifying or assembling the SQL script here -->
      <variable name="action_result" value="good" />
      <if condition="${action_result=='bad'}">
         <variable name="var_action_1" value="done" />
      </if>
   </reportaction>
   <reportaction name="check_sql" nextaction="${var_action_1}">
      <log message="the SQL is ${action_result}, so next action is ${var_action_1}!" level="Debug" />
   </reportaction>
   <reportaction name="gather_data" nextaction="${var_action_2}">
      <log message="gather the data for report, its next action is ${var_action_2}!" level="Debug" />
 <!-- Putting the RDL elements that are used for retrieving the data here -->
   </reportaction>
   <reportaction name="format_report" nextaction="done">
      <log message="format report!" level="Debug" />
 <!-- Putting the RDL elements that are used for specifying the output type and layout here-->
   </reportaction>
   <reportaction name="done">
      <log message="Done!" level="Debug" />
   </reportaction>
 </report>

And here is the log information produced by this test case.

               First action specified: prepare_query 
               prepare_query:
                     [log] generate the SQL for report query!


               check_sql:
                     [log] The SQL is good, so next action is gather_data!


               gather_data:
                    [log] gather the data for report, its next action is format_report!
 .
               format_report:
                     [log] format report!


               done:
                     [log] Done!

We could get some feels about the RDL element types from the sample above. There are five RDL element types inside this RDL snippet that are report, reportaction, variable, if, and log, every element type has respective attributes and functionality, such as reportaction and if are mainly used for controlling the procedural flow, variable is used for specifying the new macro variables and assigning the value to existed variables, log is used for writing the log

The following is the module list for upcoming report tools, the first release will include report build engine, visual report designer and data gather interface.

• Report build engine.

The Report build engine could create and format a report based on a RDL (report definition language) script, RDL is an industry standard and a kind of extensible script, the different development tools vendor could add their own predefined syntax into it. Here is the brief introduction about which feature our RDL script will support.

1. The definition of general report layout - such as the height of report header, the count of report column, etc.
2. The definition of report data source - such as a SQL for retrieving data from database or a Tab delimited text file, the Report build engine will retrieve the data based on SQL by invoking the data gather interface.
3. The definition of some simple procedural flow logic - such as loop and branch (if/else) by which the user could customize some complex reports that can be varied according to some specific situation at the reports building stage.
4. The definition of some macro variables - It has two purposes, one is that it can work with the definition of procedural flow logic to handle the complex reports; another is that its value could be replaced with some text contents at the reports building stage.
5. The definition of security validation - It is used to verify if the contents inside the reports can be retrieved and viewed by specified users or groups, the contents could be entire report body, or some report columns, or some report cells only. The Report build engine will validate the security by invoking the report security interface when it encounters the definition of security validation.
6. The definition of report output type - it is used to specify which reports output format the report build engine will generate, such as Excel, Word or PDF.

• Visual report designer

The visual report designer is a GUI tools that allow the report analysts or developers to design and define the report template by drag and drop visually. It includes the report design GUI and preview GUI, the report template will be save as RDL script for Report build engine using.

•  Data gather interface

The data gather interface is based on ADO.NET, it can retrieve the data from various database according the connection string and SQL script, and store the data into local disk for the Report build engine use.

• Report security interface

The report security interface includes a set of APIs that are used to verify if specific users or groups have rights to retrieve and view the data. The report security interface provides the support of development extension, so the client could integrate it with their existing authorization system.

• Visual query builder

The visual query builder is provided for building the queries visually. It allows users to create and edit queries without knowledge of SQL, prepare and execute queries, and view the results of the execution. It will be integrated with visual report designer.

• Domain object interface

The domain object interface is provided for simplifying and speeding up the reports designing process, and minimizing the development effort.

The domain object interface includes some APIs to import and reference the domain objects marshaled by the predefined web service; the property of these domain objects will be referenced as the definition of macro variables inside the RDL script.

The domain object interface also includes a visual GUI integrated with visual report designer.

The users will benefit from this feature by separating the work between the report analysts and backend developers, it means that backend developers can boil down complex server-side database behaviors into simple and easy-to-use business elements that report analysts can easily incorporate into their reports with the visual report design tools. For instance, a cross-tab report need some rows of products in the table as the report header, and the products name and count is varied by different situation, the developers could write a web service to retrieve these product list by passing some parameter, then report analysts could use the visual GUI to reference this web service and specify the parameter as macro variables. The report build engine will invoke this web service to get the product list at the reports building stage. This products web service can be reused by other reports.