Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 12.0.1 » MobiLink - Server Administration » MobiLink server technology » Central administration of remote databases


Remote tasks

A remote task is the unit of work when performing central administration of remote databases. A remote task consists of the following:

  • One or more trigger mechanisms

  • Optional conditions

  • An ordered collection of commands

  • Other properties

Tasks are created by the administrator using the MobiLink 12 plug-in for Sybase Central. At design-time they are stored locally on the administrator's computer in the project. For a list of commands that can be used to build tasks, see Commands.

Generally, one task should not depend on the completion of another task. However, it is possible to create a task that depends on another by having one task write something to the remote database and having the condition of another task query that value.

Once the administrator is ready for Agents to receive a task, the administrator deploys the task. When deployed, a task is copied into the consolidated database. There are now two copies of the task: the deployed task in the consolidated database and the design-time task in the project. Deployed tasks may not be modified. However, the design-time task used to create them may be modified and deployed again (to create a second deployed task). Deployed tasks can be canceled, initiated (SIRT), reactivated and assigned to new recipients.

Once deployed, a task may be assigned to one or more Agents for execution. When assigned to an Agent, the task is downloaded to the Agent. The Agent then executes the task at an appropriate time and optionally uploads the results back to the consolidated database where they can be reviewed by an administrator using the MobiLink 12 plug-in for Sybase Central.

Tasks have the following attributes:

  • Name   A remote task has two names: one identifies the design-time version of the task stored in the project while the other identifies the task once it is deployed. Often the two names are the same.

    A task's design-time name is assigned when the task is created and must be unique among tasks in the project. A deployed task name is assigned when the task is deployed and this name must be unique among deployed tasks in the consolidated database.

  • Description   A description of the task can be entered and may contain any text you wish to associate with the task. The description is stored in the project and in the consolidated database (once the task is deployed), but is not sent to the Agent.

  • Trigger mechanisms   A remote task's trigger mechanisms determine when the Agent attempts to execute the task. A task may have more than one trigger mechanism. There are three supported trigger mechanisms:

    • Based on a schedule   The task is triggered at specific times or at specific time intervals. This option must be explicitly set for a task.

    • When received by an Agent   The task is triggered when it is received by the Agent, and will run only once. This option must be explicitly set for a task.

    • On demand   The task may be triggered at any time by a message from the server in a process called Server-Initiated Remote Task (SIRT). All tasks that are not configured to run only once support being triggered on demand.

  • Conditions   Before a task can be executed, all its conditions must be satisfied. If a task is triggered but all its conditions are not met, then the run attempt is considered a failure and the task must be triggered again before the conditions are reevaluated.

  • Remote schema name   A task can optionally be associated with a remote schema name. Tasks that require access to a remote database must be associated with a remote schema name. The remote schema name is used by the Agent to determine which of the databases the Agent needs to access when executing the task. Tasks must be associated with a remote schema name if they contain any of the following commands: create database, drop database, execute SQL or synchronize. A remote task must also be associated with a remote schema name if you want to use a SQL condition to determine if the task can run.

  • Commands   A task contains an ordered set of commands that carry out the work required for the task. The order in which the commands are specified defines the order in which the commands are executed within the task. It is important to be aware of the order of the commands because commands could be dependent on each other. See Commands.

  • Maximum number of retries   Each command has an on failure action that can be used to cause the task or the command to be retried if the command fails. This option lets you limit the number of retries allowed during a single run attempt.

  • Delay between retries   This option specifies the amount of time to wait after a command fails before attempting to retry the command or task. This delay may allow a transitory condition (such as a locked database table or a locked file) that caused the failure to pass before the command or task is reattempted. Retry delays are assumed to be "short" periods of time. A task condition is not re-evaluated between retries.

  • Maximum running time   It is possible that a task when executed, does not behave as the administrator intended. An OS call could hang; an attempt to synchronize could be very slow—a SQL statement could be blocked on another connection using the database. Setting a maximum running time for a task lets you limit how long the task may run. If the maximum running time is reached, the task is terminated (the actual time at which the task is terminated depends on the ability to interrupt the operation). The status for the task is set to reflect the timeout and the task is not retried until it is triggered again. If a command in a task fails and the task or command needs to be retried, the maximum running time is reset after the delay. So, the maximum running time is considered to be per attempted task execution or retry. It does not include the aggregate time of all retries and it does not include Prompt commands.

  • Schema change   Schema change tasks change the schema of a remote database. If the task succeeds, the remote schema name of the remote database is also updated. Schema change tasks are always high priority tasks and they report their status on completion.

  • High priority   High priority tasks are always triggered when received by an Agent and executed as soon as any currently executing tasks are complete. They may not be executed based on a schedule and they may not have any conditions on their execution. A task marked high priority is only executed when there are no other tasks being executed to ensure that no other task interferes with the execution of a high priority task.

  • Status reporting   Status reporting options on a task allow you to specify when and if results are reported back to the consolidated database, both when the task completes successfully and when it fails. The available options are:

    • Send status only   Task results are not reported. However, information about the number of task successes or failures is maintained and reported.

    • Return results the next time the Agent synchronizes the agent database   Task results and status are maintained and reported the next time the Agent synchronizes the agent database.

    • Return results immediately when task execution completes   Task results and status are reported as soon as the task completes.

  • Random delay interval   If a given task sends results to the MobiLink server after execution or causes a remote database to synchronize with the server, and it is triggered simultaneously across a large number of remotes, then setting a random delay for the task uniformly distributes the synchronization workload for the server over a configurable period of time.

    A remote task can have a random delay interval, which is an interval N, in seconds, with which each agent generates a random number of seconds in [0, N) to delay each task execution. If the task is a scheduled task, the random delay is generated before the first task execution, and used for each execution. The task is executed at the scheduled times, offset by the random delay. This ensures that the deltas of the task execution times are consistent with the schedule.

    It is not recommended that the random delay interval be larger than smallest delta time of a scheduled task. If the task is an on demand task, meaning it is initiated by the server, the random delay is generated and used to delay the execution each time the task is initiated. If the task is a run on receipt task, the random delay is generated and used to delay the execution at the first and only time the task is executed.

 Remote task logic
 Creating a remote task
 Editing a remote task
 Deploying a remote task

Working with deployed remote tasks
Server-initiated remote tasks (SIRT)
Variables in parameters
System procedures