Batch report generation involves first specifying a condition that needs to be satisfied and then an action that must be carried out when the action is satisfied. Using the Enterprise Manager it is possible to use the Scheduler in conjunction with the built-in condition and action classes.
The built-in conditions include several time-based conditions: daily, weekly, monthly, a day in a week in a month (e.g. 1st Sunday in March), a day in a week in a year (e.g. 20th Wednesday of the year) and an exact date and time.
The built-in actions support creating reports and delivering the output to printers, sending emails, saving in an archive, and generating PDF files.
In addition to these default conditions and actions, it is possible to use the API to implement scheduled reports for conditions and actions beyond the defaults.
It is possible to define custom schedule conditions by using the schedule API. The user-defined conditions cannot be entered directly on the Enterprise Manager, but must be created programmatically.
A user-defined condition must implement the UserCondition interface. There are a few methods in the interface: check(), getRetryTime(). Both methods take a current time parameter. The current time parameter specifies the logical current time.
Its value may be different from the actual system time returned by System.currentTimeMillis() and is used for the 'what if' analysis by the scheduler. Both routines should use the passed value as the current time.
The getRetryTime() is called by the scheduler to determine the time this condition needs to be checked. This method is called at the scheduler start up time and also after a check() call returns false. If a task has more than one condition, the task will be retried at the latest retry time of all the conditions. If the getRetryTime() returns a –1, the condition is abandoned.
The check() method can be called anytime after the retry time. It should check the condition criteria and returns true if all the criteria are satisfied and false otherwise. It is up to the user defined class to perform any checking in the check() method.
The following example defines a user-defined condition that checks the existence of a file.
import inetsoft.sree.schedule.*; import inetsoft.sree.*; import java.io.*; public class FileCondition implements UserCondition { public String getLabel() { return "File Check"; } public RepletRequest getRepletRequest() { return this.request; } public void setRepletRequest(RepletRequest request) { this.request = request; } public long getRetryTime(long now) { // if the file name property is not defined by user if(filename == null) { return –1; } return now + 600000; // retry in 10 minutes } // check if the file exists public boolean check(long now) { return (new File(filename)).exists(); } String filename = SreeEnv.getProperty("extra.datafile"); RepletRequest request = null; };
Like user-defined conditions, an application can also define its own actions. One important difference between user-defined conditions and actions is that the user-defined actions can be entered and configured in the Enterprise Manager, while user defined conditions must be added programmatically.
A user-defined action class must implement the UserAction interface. There are three methods in the interface. The run() method is the main routine for performing the action. The other two methods, setRepletRequest() and getRepletRequest(), deal with the parameters for the user action.
A set of parameter values can be configured when a user action is created in the GUI. The parameters are loaded and passed to the user action through the setRepletRequest() method. This allows a user defined action class to be parameterized in the same way as the default actions.
The DefaultUserAction class provides a default implementation of the UserAction interface. The subclass of DefaultUserAction only needs to define the run() method. As with conditions, the equals() method should also be implemented.
import inetsoft.sree.schedule.*; public class MyAction extends DefaultUserAction { public void run(Principal principal) throws Throwable { // perform action … } }
Style Intelligence is shipped with an enhanced template designer, which includes functionality for creating interactive forms.
A report is viewed using the standard Letter size (8.5x11 inches) in portrait orientation, which must be specified by the replet when a report is generated, if a different size is to be used.
A servlet instance can be accessed using the ServletRepository class when a replet intended to be run only in Web environments needs to access the servlet environment, such as the servlet context or configuration parameters.
When a replet is running inside a servlet, the HTTP request and response objects are accessible as special parameters in the replet request.
Batch report generation involves first specifying a condition that needs to be satisfied and then an action that must be carried out when the condition is satisfied. Using the Enterprise Manager it is possible to use the Scheduler in conjunction with the built-in condition and action classes.
InetSoft Enterprise products are a powerful collection of server reporting components. For most reporting needs, our software can be used directly as a complete distributed reporting tool. The simplicity of its administration and configuration makes it very easy to deploy and manage. For more sophisticated applications, the InetSoft server components can be integrated into the application front-end and back-end and function as an integrated part of the application.
Simplicity and flexibility is the main design goal of InetSoft Enterprise products. The API is simple to use, yet flexible for instances when more power is needed. We also try to eliminate the need for dependency on a heavy weight database system. All persistent server component data is stored in plain text files. This makes maintenance and modification of the system extremely easy.
Copyright © 2024, InetSoft Technology Corp.
