The JReport Server product is a combination of several software components.
The Java API is at the heart of the JReport Server functionality but it is the higher level components that provide immediate value and use.
JReport Server provides a large set of JSP-based web pages that are ready for production. These provide standard operations that most applications need.
When these JSP pages are deployed to the web site, a visitor can access a web page that lists the set of reports available to them. From there they can schedule and run reports, including entering parameters that control the purpose and scope of the report. They can use this web application to view the results, or direct the reports to a PDF file, an email, or a variety of destinations.
These pages are available immediately. Full report functionality is available through these interactive web interface without writing any Java code or knowing anything about the low level Java API.
These pages are written by Jinfonet engineers using the JReport Server Java API. Since they are JSP pages with visible source, they can be studied for ways of using the Java API or they can be refactored for a local variation of the web page. Using the CSS files and images it is also very easy to private label the application.
Providing these JReport Server web pages in your application is as easy as adding links that lead to the JSP pages. The JSP code can be customized as needed to fit into the design of the application so that they appear seamlessly as part of the whole.
Any web server technology can be used to build an application that includes these JReport Server web pages, including .NET and static HTML.
JReport Server also provides a set of compiled servlets that perform commonly needed actions related to running and scheduling reports, and viewing results. These services are requested via HTTP requests, with a set of parameters in the URL that define and control the requested service. They are called with parameters that completely define their service so it is possible to use them as helper operations behind an interactive web page that gathers information from a visitor and posts to the servlet URL, with parameters telling the servlet what to do with any resulting output.
Accessing these components of JReport is done by building and sending an HTTP request to the web server with a URL that points to the servlet. This can be done by a desktop program that interacts with a user to build up the needed parameters. A front end for the servlets could be a static HTML web page that provides a form for a user to fill in with the needed parameters before doing a submit to the URL. The web application can dynamically build appropriate links and put them into a menu or other page link. Any type web technology, including .NET can be used to build up an appropriate URL to call up the action of the servlets. Running the servlets does not depend on using Java.
There are examples of how the servlets are called in the sample file TestURL.html which is located in <instal_root>\help\samples\URLSamples
.
JReport Server provides a library of Java classes that can be used by a Java program. This is the Java API, which gives the most complete and versatile way to access JReport functionality. In later architectural illustrations, this may be labeled JReport Server API.
An application developer can extend their application to provide report functionality by writing custom code to call the JReport Server Java API to perform any operations needed. This is the key aspect of JReport Server that makes it appealing for application developers who need reporting functionality resident within the same web server.
Looking at the Javadocs for the Java API is intimidating. There are hundreds of classes and thousands of methods.
A later section gives a high-level tour of the Java API, organized by functional area. This will introduce the Java API so it is easier to understand. It will explain how the classes are organized to provide specific types of functionality.
A developer only needs to understand the working set of classes and methods that relate to a particular application need. A developer does not need to know about every class or method documented in the Java API Javadocs.