MicroStrategy ONE
Task Class
Task interface. To help you implement such a Java class efficiently, a description of the Task class hierarchy is provided below. In addition, there is a separate topic that explains how to register the task with the Task Registry and another that provides a detailed explanation of how to construct a sample Java class that creates a task.
The Task interface is shown below.
It is important to note that a Java class that implements the Task interface does not define its ID. That is done when the task is registered. This gives the person configuring the list of tasks the ability to select unique names for all tasks.
Most of the methods in the Task interface are self-explanatory—for example, getID, setID, destroy, newRequest, and ProcessRequest. The getMetadata method, which returns information about the task as a TaskMetadata object, requires explanation.
As explained below, the following base classes make the construction of the TaskMetadata object very simple.
The AbstractBaseTask class provides default implementations for almost all of the methods used to create a task.
-
The constructor takes a String that defines the description of the task. This information is used to construct a new TaskMetadata object (which is returned in getMetadata).
To maintain the stateless nature of your task, you should define all of your task metadata in the constructor of your class.
-
There are empty, default implementations for init and destroy. If your task requires any one-time initialization, it should be done inside the init method. You can free up any persistent resources in the destroy method.
-
The getID and setID methods are implemented.
-
The newRequestContext method returns an instance of a BaseTaskRequestContext. If your task requires more per-request data to be maintained, you can override the newRequestContext method.
-
The addParameterMetadata method takes a parameter name, a parameter description, a Boolean value that indicates whether the parameter is required, and a default value (as a String). This method is used to further populate the TaskMetadata object.
-
To add common MicroStrategy task parameters to your task, you can call one of the various addXyzParam methods (addMaxWaitParam, addSessionIDParam, and so on).
After your metadata is defined (in your constructor), you must implement the processRequest method. The AbstractBaseTask class cannot provide much assistance in this. This class does provide one method (checkForRequiredParameters) that can check whether all required parameters are present or not. It should be called early in the processRequest method implementation. If any required parameters are absent, an exception is raised and ends your processRequest method.
The context object, called BaseTaskRequestContext, provides the methods shown below:
The key features of this context object are that it provides the task with:
-
A ContainerServices instance, using the getContainerServices and setContainerServices methods.
-
A RequestKeys instance, using the getRequestKeys and setRequestKeys methods.
-
A way to retrieve a WebIServerSession instance, using the getWebIServerSession and setWebIServerSessions methods.
To retrieve a WebIServerSession object, simply supply the name of your SessionState task parameter (if present) and the SessionID task parameter (if present). If your task does not expose one of these parameters, simply supply null. The getWebIServerSession method looks for the value of these task parameters and uses them to create a new WebIServerSession instance and store it in the context. If one was already computed, it is returned.
If your task uses the Web Blocks infrastructure for constructing content, then getRootBlock can be used to obtain the root Web Block used. If one already exists, it is returned. Similarly, to return any other internal blocks, you can use the getBlock method.
If your task requires additional data that is typically associated with the MicroStrategy Web application— such as message bundles, preferences, and so on— then your task should extend the AbstractAppTask class.
This class simply returns a different TaskRequestContext object called AppTaskRequestContext.
If your task extends AbstractAppTask, then the TaskRequestContext object you are supplied with can be downcast to AppTaskRequestContext. This gives you direct access to an AppContext object (which contains many types of objects) as well as a StyleCatalog.
There is one other specialized subclass of AbstractAppTask. It is called BeanTask, and it is the base class for bean-based tasks. AggregatingTaskFactory is the main TaskFactory for the TaskProcessor. Besides specifying a registry of tasks (which are invoked through reflection), you can specify other TaskFactory classes. One such TaskFactory is BeanTaskFactory. Unlike AggregatingTaskFactory, it instantiates tasks that are expressed in XML files. When BeanTaskFactory starts up, it reads a directory specified in the microstrategy.xml file. The name of the directory to read is specified in the beanTaskDir initialization parameter. This directory is scanned for XML files that conform to the bean-based task XML specification. All tasks defined in this way are treated exactly as tasks written as Java classes.