If ExtraView Corporation is hosting your installation, you do not have direct access to the file system of the server to configure, alter or use this feature without contacting ExtraView support.
This administration section allows the control of tasks that are connected to ExtraView. These tasks control important features, and run in the background of the server. Not all tasks should be configured for all installations. When you enter the default ExtraView setup, you will see a screen similar to this:
Managing tasks
Note the Show non-local nodes prompt on the screen. If you are running in a clustered system, clicking this will show you all the tasks running on all nodes.
The task management utility runs as an interactive administrative utility controlled by the CF_MANAGE_TASKS security permission key.
This utility displays a list of tasks currently defined. New tasks (adding an existing task object to a node, for example) can be added, and existing tasks may be edited. The task management utility allows the administrator to create/modify and delete background tasks that may run in any node clustered on the ExtraView database. The standard tasks are automatically cloned and started as necessary when a new node joins the application server cluster.
This document makes no attempt to describe how to create your own tasks that can be managed by ExtraView. At some future time this interface will be documented and opened for customer use.
The tasks managed by ExtraView are detailed in the following sections:
This is an internal task which should not be altered by the administrator. It must be running for ExtraView to function correctly. This task manages the internal ExtraView sessions that are created by users as they perform their work inside ExtraView. For example, sessions are created when users add or update issues or when they run reports. This task is responsible for cleaning up sessions which are left behind when users do not "clean up" after performing a task. This improved memory utilization on the server. For example a user may simply close their browser without updating an issue on the screen, and after some time the session monitor task will recognize that this has happened and will remove the session objects associated with the browser window.
This is an internal task which should not be altered by the administrator. It is the overall control for the task manager. It is part of the integral working of ExtraView and should not be altered by the administrator. The task control task on any node ID is special, as this task is used to control all other tasks that run under task management. It must be running for ExtraView to function correctly. Therefore, if the task control task is not running on a node, there can be no changes to other task states on that node.
There must be a task control task configured on each node where background tasks run and can be modified. There is no reason for the administrator to alter the default properties of this task. Doing so may result in other tasks not executing correctly, or not executing at all.
This is an internal task which should not be altered by the administrator. This task is responsible for ensuring the correct handling of metadata exports performed by an administrator. There is no reason to alter the default properties of this task.
This is an internal task which should not be altered by the administrator. This task is responsible for ensuring the correct handling of metadata exports performed by an administrator. There is no reason to alter the default properties of this task.
This task is responsible for handing off outgoing email notifications created within ExtraView, to your company's email server. It keeps a log of all activity and removes the email text from the server once it has been successfully sent. If there was a problem sending email to the email server, then the email text is left on the server. In many instances the email will be sent once the problem is resolved.
This is the task that routinely scans newly entered issue text to be indexed for use by the Quickfind search engine. This task is not required if Quickfind is not turned on within ExtraView.
This task initiates the escalation mechanism which automatically updates issues and notifies users according to criteria that is defined by the administrator. When installing ExtraView you should add this task to be started automatically by ExtraView. The default poll interval is 2 minutes (120 seconds). This task does not require further configuration.
Note that the task runs using the ADMIN user account. When configuring the escalation task, you should also ensure that the date format selected for the ADMIN user account includes a time component. If this is not done, the escalation task will not run correctly.
This task controls the functioning of the EVMail utility that interfaces and imports incoming email to Extraview. This enables the creating of new issues or the updating of existing issues within your ExtraView system, from incoming email to an email address that you use for this purpose. First you create the task, and then you configure the task.
To create a new EVMail task on the current node, add the task and select a poll interval of 30 seconds or so, with START_NOW as the start option. This sets the frequency with which EVMail checks for new incoming emails.
The Report Scheduler Task must be running in order to deliver scheduled reports that users create for email delivery. You should create this task so that it starts at boot time. The default is that this task will execute every two minutes, but this time can be adjusted to accommodate your specific requirements.
This task should only be configured when you are connecting your installation to an LDAP server. It is optional to run this task. When it is running, it will synchronize the LDAP server data that is required within ExtraView on a periodic basis. This avoids ExtraView reaching out to the LDAP server for user information as it is required, and uses the information previously read into ExtraView. This task should be configured in preference to the LDAP Synchronize Task.
This task should only be configured when you are connecting your installation to an LDAP server. It is optional to run this task. When it is running, it will synchronize all the LDAP server data to ExtraView on a periodic basis. It is preferable to use the LDAP Background Task.
This task only needs to be configured and started if you are pre-caching layouts at the time of starting the system server. This is useful on systems with complex or very large layouts. See the page here for more details. Note that you should configure the poll time to zero so the task only runs once at system startup, and does not run continually.
If you have a cluster of application servers supporting your ExtraView environment, there are some important points to be aware. Principally, some tasks should be run on all nodes of the cluster, and some should not be run on all nodes of the cluster. We suggest you configure a clustered environment in the following way:
Overall, only a single Batchmail task should be polling the email directory folder. If you have multiple separate physical locations for this folder, you need multiple Batchmail tasks, one for each location
In the case where the load-balancing algorithm does not send any users to the node where your managed tasks are running, the EVMail and escalation tasks will not operate.
Simply starting the application server does not initialize the ExtraView application, and thus if nobody signs onto your installation, no tasks will start up. This is not simply a load-balancing issue - if your system is rebooted and restarted, and nobody signs on, the application is not initialized and the tasks are not started up. For correct operation, all nodes of the cluster should be started.
One way to make sure that your site is initialized when the application server is restarted is to configuring a monitoring tool such as Nagios, and to use the ExtraView get_heartbeat API call against each individual node on a scheduled basis - this will ensure that if an application server is restarted for any reason, then the API call will "touch" each node, and start all the copies of ExtraView in the load-balanced installation.
Tasks are often reliant on programs running external to ExtraView. When an external program fails, the ExtraView task can fail. The task may be able to recover when the external program is restarted. When a task is seen to be in an error state, email is sent to the ExtraView administrator. If ExtraView is able to recover from the error, then another email is sent to inform the administrator of the recovery.
These are used to create tasks for specific purposes within an installation. Knowledge of user custom coding is required to set up and use these tasks. Please contact ExtraView Support if you believe you have a requirement for a customized task.
