Server Deployment Principles

1. Concept of web application

When you open the decision-making platform in the local designer, you can see that the URL of the platform begins with http://localhost:8075/webroot/decision/. If you share the link with others, they cannot view your local decision-making platform. And if you access the URL after closing the designer, you can neither view the decision-making platform.

In this case, a local report project provides web page materials (i.e., reports) rather than a real web application, because you cannot access these reports via the web whenever and wherever possible.

If you access an online demo (which is in nature also a decision-making platform), you may find that the URL begins with https://endemo.finereport.com/webroot/decision/. By entering the link in a browser, others can also access the online demo.

An online demo is a web application, as people can access it via the web anywhere at any time.

The content of both a local report project and an online demo is created based on FineReport and the only difference is that an online demo, by means of a web server, maps a report project to a URL that can be accessed via the web.  The process of turning a local project into a web application is called “deployment”.

2. Rationale of deployment

Steps of deployment will be detailed in other articles in this section. Recommended web servers include Tomcat, WebLogic and Jboss. This article focuses on why deployment can turn a local report project into a web application.

The figure below shows how a deployed report project works:

①: Enter a URL in the browser. Suppose the URL is a request to view a specific report in the report project

②: A web server receives the request from the browser and then judges the request. As reports involve fetching data from databases, with dynamic effects such as query and linkage, so they are in essence “dynamic resources”. However, a web server cannot directly handle and return dynamic resources (but it can directly handle and return “static resources”), so it forwards the request to the Servlet (Server Applet) container inside it, which then handles dynamic resources.

③-⑤: Servlet is a series of JAR packages developed independently by FineReport. JAR packages handle a series of operations required to generate report pages, including fetching data from databases, generating parameters to implement queries, generating charts to display data, etc.

⑥: After Servlet handles the request, accessible report pages are returned to the Servlet container.

⑦: The Servlet container returns accessible report pages to the browser, so that users can ultimately view the reports.

The following two conclusions can be drawn from the steps above:

1: A web server (including the Sevlet container inside it) receives a request (i.e., the URL) and responds to the request (i.e., show the report content).

2: FineReport handles requests from users. To be specific, it converts report logic into report pages that can be accessed by users, based on a template designed by the report developer (the template is essentially logic that stores a report).

Therefore, a web server is needed to display the reports designed in FineReport to others.

In fact, FineReport is equipped with built-in Tomcat. If you open the FineReport installation folder, you will find a folder named server, which stores in-built Tomcat profiles. The in-built Tomcat enables you to preview each report page via a URL beginning with localhost:8075.

However, this in-built Tomcat disables others to access a local report project on their own devices. You have to find a server (which refers to hardware, e.g., a Linux server or your PC) to configure a web server (which refers to software, e.g., Tomcat) and then place files in the report project into the web server. When the web server begins to work, the report project becomes a web application in its real sense. Of course, if you already have a web server, you can place files in the report project directly into the web server.

Here, two methods of deployment are mentioned: one is to configure a web server from nothing, which is known as independent deployment; the other is putting files in the report project into an existing web server, namely embedded deployment. You may choose either method as the case may be.

1. Background

After a web application is deployed in FineReport, users need to log in the decision-making platform with username and password. But an enterprise often has a number of business systems, such as CRM, OA and MES, so it will be tedious for users to re-enter the username and password when logging in each system.

The aim of integration is to allow all business systems to share an account system, so that after users log in one of these systems, they can directly access other systems as long as the login status has not expired, saving the trouble of repeating login. Hence, integration is realized through single sign-on (SSO).

2. Rationale of SSO

SSO can be realized based on a number of protocols, such as HTTP, oAuth and CAS. FineReport has developed a login/logout API based on HTTP, which can be called by modifying the front-end code of an existing system, so as to enable simple SSO. By contrast, oAuth- and CAS-based SSO is more complicated, but more helpful to the security of the account system. oAuth licenses logging in the decision-making platform as a service to third-party applications (e.g., other business systems); rather than get the content of the account system, such third-party applications will be licensed to log in the decision-making platform. CAS builds a central account authentication platform which offers a unified place for user authentication of all business systems, with the core still lying in authentication through FineReport’s login/logout API.

Taking the API provided by FineReport for example, we introduce the rationale of SSO below.

Suppose there are two systems: one is a report built on FineReport and the other is a different business system. The figure below exhibits the process that users access to both systems by logging in only once. To further understand the process, you have to get to know the basic concepts of session, token and cookie:

Session: if a user is successfully authenticated, the server will generate a session for the user, which you can construe as being used to store information on the user’s login status. After the session is generated, the server will return a sessionid, which is used to find the session corresponding to the user, to the browser. Each time the user accesses a system, the token will be verified. If the result indicates that the login has not expired, then the session corresponding to the user is found through the sessionid, the session remains and the user is allowed to visit the page; if the result shows expired login, then the session corresponding to the user is deleted from the server according to the sessionid and the user has to re-enter the username and password for authentication the next time he accesses the system.

Token: if a user is successfully authenticated, the server will return a token to the browser, which you can construe as encrypted user information that records the time when login is expired. The browser will store the token in the cookie; each time the user accesses a system, the server will first decrypt and then verify the token.

Cookie: stores token and sessionid in the browser.