基本概念¶
两种主要的对象 Task Manager 是 configurations 和 batches . 任务管理器还允许创建 Templates 对于配置。
配置¶
配置是任务管理器中的中心对象。配置通常链接到数据对象（如地理服务器层），并作为与此数据对象相关的任务和批处理的入口点。
配置具有唯一的名称、说明和工作区。它包含三组对象：
Attributes：属性包含有关此配置的信息，可在此配置的不同任务之间共享。属性有名称和值。每个属性都与至少一个任务参数相关联（见下文）。属性从其关联的参数继承其验证属性，例如其接受的值以及是否需要它。Tasks: Each task configures an operation that can be executed on this configuration. Each task has a name that is unique within the configuration, a type and a list of parameters with each a name and a value. The full name of a task is donated as configuration-name/task-name (which serves as a unique identifier for the task). The task's type is chosen from a list of available task types 它定义不同类型的操作（例如：复制数据库表、发布一个层…），并期望一个参数列表，每个参数都有一个名称和类型。参数可能是必需的，也可能不是必需的。参数类型定义参数的接受值。当接受值的列表依赖于另一个参数的值（例如：数据库中的表）时，参数类型是依赖类型。参数值可以是文本，也可以是对表单属性的引用${{attribute-name}}.Batches.
批¶
批处理由一系列有序的任务组成，这些任务可以按需运行，也可以按计划在特定时间重复运行。有两种批次：
Configuration batches：这些是属于配置的批处理。此批中的所有任务都是属于同一配置的任务。Independent batches：这些批不属于配置。它们可能包含来自任何现有配置的任务。
批处理具有名称、说明和工作区。批次的名称在其配置或所有独立批次中必须是唯一的。批次的全名表示为 [[configuration-name:]batch-name] 作为批处理的唯一标识符。
名称以a开头的配置批 @, are hidden from the general batch overview and are only accessible from their configuration. Hidden batch names may be reserved for special functions. At this point, there is only one such case (see Initializing templates ）
如果满足以下条件，则可以手动运行批处理：
任务列表非空；
操作用户具有这样做的安全权限（请参见 Security ）
如果满足以下条件，批将在其计划时间自动运行：
任务列表非空；
批量启用；
批处理的频率配置不是
NEVER；批处理是独立的或其配置已完成，即验证无误（在某些情况下，配置可能在验证前保存，请参阅 Initializing templates ）
运行批处理¶
批处理分两个阶段执行：
RUN阶段：按定义的顺序执行任务。如果发生错误或手动中断运行，请停止执行并转到ROLLBACK相位。如果所有任务都成功完成，请转到COMMIT相位。COMMIT/ROLLBACK阶段：任务在 相反的 秩序。
考虑一个有三个任务的批次
B = T1 -> T2 -> T3 .
正常的运行将是
run T1 -> run T2 -> run T3 -> commit T3 -> commit T2 -> commit T1 .
但是，如果t2失败，则运行将
run T1 -> run T2 (failure) -> rollback T1 .
大多数任务支持 COMMIT/ROLLBACK by creating temporary objects that only become definite objects after a COMMIT. The ROLLBACK phase then simply cleans up those temporary objects. However, some particular task types 可能不支持 COMMIT/ROLLBACK 机制（在这种情况下运行它们是确定的）。
提交阶段按相反的顺序进行，因为旧版本数据中的依赖项经常需要这样做。一个具体的例子也许能澄清事实。想象一下 T1 复制数据库表 R 从一个数据库到另一个数据库 T2 创建视图 V 根据那张桌子，所以 V 取决于 R . 如果表和视图已经存在于旧版本中( R_old 和 V_old )，在 COMMIT 阶段，以便在 ROLLBACK . 在 COMMIT 阶段， R_old 和 V_old 已删除，但无法删除 R_old 直到 V_old 被移除。因此，有必要承诺 T2 之前 T1 .
这个 COMMIT 阶段通常用具有临时名称的新对象替换旧对象。由于任务通常创建依赖于以前任务的对象的对象，因此这些对象包含对临时名称的引用。这意味着当临时对象提交并成为真正的对象时，依赖对象中的引用也必须更新。为此，使用前一个任务中的临时对象的任务将注册一个 附属国 ，这实际上是添加到上一个任务的提交阶段的更新。
如果 T3 依赖于任务 T1 我们称之为 D1 ，发生以下情况：
run T1 -> run T2 -> run T3, register D1 -> commit T3 -> commit T2 -> commit T1, update D1 .
让我们用一个例子再清楚一点。在 RUN 阶段 T1 创建表 R1_temp 和 T2 创造 V1_temp 这取决于 R1_temp ，将注册此依赖项。在提交阶段， T2 将替换 V1 通过 V1_temp . 然后， T1 将替换 T1 通过 T1_temp . 然而， V1 仍然可以参考 T1_temp 已经不存在了。因此， T1 将使用已注册的依赖项进行更新 V1 参考 T1 而不是 T1_temp .
在批处理运行中，每个已启动的任务都有一个状态。这些是可能的状态：
RUNNING：任务当前正在运行。WAITING_TO_COMMIT：任务已完成运行，但正在等待提交（或回滚），而其他任务正在运行或提交（或回滚）。COMMITTING：任务当前正在提交。ROLLING_BACK：任务当前正在回滚。COMMITTED：任务已成功提交。ROLLED_BACK：任务已成功回滚。NOT_COMMITTED：任务本应提交，但在提交阶段失败。NOT_ROLLED_BACK：任务本应回滚，但在回滚阶段失败。
如果任务的状态不是 RUNNING ， WAITING_TO_COMMIT ， ROLLING_BACK 或 COMMITTING .批处理运行没有其自身的状态，但它将接受已启动但未启动的上一个任务的状态。 COMMITTED 或 ROLLED_BACK . 如果批处理运行的状态不是 RUNNING ， WAITING_TO_COMMIT 或 COMMITTING .
在任务级别和批处理级别都有并发保护。一个批决不能在多次运行中同时运行（第二次运行将等待第一次运行完成）。一个任务不能在多个运行中同时运行，即使是不同批的一部分。单个任务也不能在多个运行中同时提交。
模板¶
模板与配置完全相同，但以下情况除外：
它们在保存时不会被验证（它们的属性不需要填写），并且
它们的任务和批处理永远无法执行。
模板用作创建彼此非常相似的配置的蓝图。通常，任务都相同，但属性值不同。但是，模板中也可以填充用作默认值的属性值。
一旦从模板创建了配置，它就独立于该模板（对模板的更改不会影响它）。然后可以像其他配置一样修改配置，包括删除、添加和操作任务。
初始化模板¶
初始化模板是具有名为 @Initialize （区分大小写），用于配置特殊行为。此批处理的目的是执行某些任务，这些任务必须至少完成一次，直到可以实际配置某些其他任务为止。例如，您可能希望基于从源数据库复制的表创建矢量图层，然后将该图层同步到目标地理服务器。将图层同步到外部地理服务器的任务将需要现有的已配置图层，只有先复制表后才能创建该图层。这个 @Initialize 在这种情况下，批处理将从源复制表，并在本地geoserver中创建一个图层。
从该模板创建配置时，配置分两个阶段进行
最初，只有与
@Initialize必须配置批处理。保存配置时@Initialize批处理将自动执行。
现在，必须配置所有其他属性和任务，并且必须再次保存配置。
这是唯一可以在填写所有必需属性之前保存配置的情况。请注意，在再次保存批之前（因此验证了属性），批不会在常规概述中计划或显示。