Use reports through WebService

Because the data in WebService is packaged in XML documents, the actual data volume transmitted by WebService is greater than the actual amount of information. In addition, WebService uses HTTP, which is a relatively inefficient connection method, so it runs slowly. However, it is an international standard and a good way to exchange data across platforms. Therefore, it is widely used with support from software vendors, large and small.

I believe there are many application systems. The basic structure is the C/S system. However, at this time, the application system no longer directly connects to the database, but uses WebService to download DataSet from a Web server to access data. This has many advantages,
1. Secure. The client does not need to store sensitive information such as database connection strings.
2. Second, it is easy to deploy. You do not need to install various database client APIs on the client, and do not need to perform various configurations.
3. Optimize database access. At this time, only the server program connects directly to the database, and the client does not connect to the database. Therefore, the server program can be assured to optimize the database.
4. High scalability. Many modifications to such a system are limited to server programs and can be easily converted to a pure B/S system.

In view of this, we are also catching up with fashion, and want my reporting tools to support this WebService method.

The principle of this WebService is very simple. The process is as follows:
1. The report designer or the report engine running on the client loads the Report Template and fills in the report parameters. Then it is converted into a binary data.
2. Send the binary data to the server page and wait for a response.
3. The server page accepts binary data and calls the report engine to parse the Report Template and its parameters.
4. The Report Engine connects to the database, executes reports, generates report documents, and converts the report documents into binary data.
5. The server page returns the binary data to the client as an HTTP response.
6. The client program accepts the binary data, calls the report engine to parse and generate report documents, and then you can view or print it.

At first, I didn't use the standard WebService method to implement it. I am quite familiar with it. I have never used WebService in my previous development. However, I have some basic knowledge about HTTP and XML, after reading several articles about WebService, I think that the principles and basic processes of WebService are understood. I personally think that all Web servers are WebServices, in the past, only a relatively extensive HTML document was passed, and the recipient was a browser. Now it is only used to deliver rigorous XML documents. The receiver is a variety of apps that are smarter than browsers.

After customizing WebService, the client calls the Report Engine and converts the report template document filled with parameters into a byte array. Considering that other data may need to be appended in the future, add an XML shell to the data and then use System. net. httpWebRequest connects to the specified server page address, uses the POST method to send to the server page, and then waits for a response.
A new ASPX page is created on the Web server. The content of the ASPX file is deleted and only the first row is retained. Then use this in the Page_Load function of the page. request. inputStream is used to load XML documents, parse binary data, use the report engine to parse the report template, and connect to the database to execute the report template to generate the report document object, convert the report document object to binary data, and then use this. resonse. binaryWrite is written to the output stream.
After the client receives all the HTTP responses, it uses the report engine to parse the byte arrays into report documents, and then you can view and preview them.

The program was quickly written out and tested on my machine. However, running on some machines failed. It may be because of the incorrect XML file encoding format caused by IIS configuration, it seems that the custom is somewhat unreliable. Decide to use the standard WebService.

I found some simple examples of using WebService in VS. NET. I tried it and found it easy to use WebService in VS. NET. Insert an asmx file into the Web project and write the following code:

[System. Web. Services. WebMethod]
Public byte [] ExecuteReport (byte [] bs)
{
Using (System. Data. OleDb. OleDbConnection conn = new System. Data. OleDb. OleDbConnection ())
{
Conn. connectionString = "Provider = Microsoft. jet. OLEDB.4.0; Data Source = "+ System. IO. path. combine (this. server. mapPath (". ")," demomdb. mdb ");
Conn. Open ();
XDesigner. Report. ReportBuilder builder = new XDesigner. Report. ReportBuilder ();
Builder. DBConnection = conn;
If (builder. Load (bs ))
{
Builder. RefreshContent ();
Return builder. SaveReportBinary ();
}
}
Return null;
}

Type XDesigner. Report. ReportBuilder is an interface of the Report Engine for loading and executing Report Templates and generating Report documents.

So the server program is finished.

The client generates an interface mapped to ExecuteReport by adding a Web reference. Then, the application can use this ing interface to call WebService.

However, adding a client program to Web references is still quite troublesome, and the report designer should be able to run independently. Therefore, we can try to remove this Web reference.

Using Windows resource manager, I found the code file automatically generated when VS. NET IDE adds Web references. The code is changed as follows:

[System. Diagnostics. DebuggerStepThroughAttribute ()]
[System. ComponentModel. DesignerCategoryAttribute ("code")]
[System. Web. Services. WebServiceBindingAttribute (Name = "XReportServiceSoap", Namespace = "http://tempuri.org/")]
Public class InnerXReportService: System. Web. Services. Protocols. SoapHttpClientProtocol
{
/// <Remarks/>
Public InnerXReportService ()
{
This. Url = "http: // localhost/asp.net/report.asmx ";
}
/// <Remarks/>
[System. web. services. protocols. soapdocumentmethodattrispace ("http://tempuri.org/ExecuteReport", RequestNamespace = "http://tempuri.org/", ResponseNamespace = "http://tempuri.org/", Use = System. web. services. description. soapBindingUse. literal, ParameterStyle = System. web. services. protocols. soapParameterStyle. wrapped)]
[Return: System. Xml. Serialization. XmlElementAttribute (DataType = "base64Binary")]
Public System. Byte [] ExecuteReport ([System. Xml. Serialization. XmlElementAttribute (ype = "base64Binary")] System. Byte [] bs)
{
Object [] results = this. Invoke ("ExecuteReport", new object [] {
Bs });
Return (System. Byte []) (results [0]);
}
/// <Remarks/>
Public System. IAsyncResult BeginExecuteReport (System. Byte [] bs, System. AsyncCallback callback, object asyncState)
{
Return this. BeginInvoke ("ExecuteReport", new object [] {
Bs}, callback, asyncState );
}

/// <Remarks/>
Public System. Byte [] EndExecuteReport (System. IAsyncResult asyncResult)
{
Object [] results = this. EndInvoke (asyncResult );
Return (System. Byte []) (results [0]);
}
} // Public class InnerXReportService: System. Web. Services. Protocols. SoapHttpClientProtocol

Add this class to the client program and delete the Web reference. Then, the client uses this custom WebService client to call WebService. The result was accidentally succeeded.

All right, it's time to complete the exploration and package.

The encapsulation target is that the interface is simple and easy to use, and the program can easily switch back and forth between the direct connection mode of the database and the WebService mode. Therefore, I came up with the idea of XDesigner. Report. ReportBuilder. ReportBuilder uses a direct connection to the database to execute reports. If the WebService method is strongly added to the report, it is not sweet because the processing process of the two modes is too different. Therefore, a new class is derived from this class, and the report generation process is reloaded. But the interface remains unchanged, so that the client program can easily switch back in these two modes.

Therefore, a WebServiceClient object is derived based on ReportBuilder. The ServerURL attribute is added to specify the WebService page address, and the Refresh function is reloaded to call WebService to generate reports.

The demo program XReportWinFormDemo provided by this table tool demonstrates how to use WebService to execute reports. The report designer also supports WebService to preview reports.

The report designer supports the WebService method to preview reports. The XReport Report Engine supports extended programming of data sources, and the built-in report engine of the report designer cannot be extended. Therefore, when the application uses extended programming of data sources in the WebService server program, the report designer can use the extended programming capability by calling WebService. Yes. The report designer can work closely with the application system to prepare report templates. This topic will be published later.

XDesigner software Studio (http://www.xdesigner.cn) 2006-10-23