您可以在实现插件时应用特定方法,例如缓存对象、将对象置于后台、克隆对象等。按照此类方法操作,您可以改进插件的性能、避免并发问题并改进 Orchestrator 客户端的响应能力。

缓存对象

您的插件可与远程服务交互,这一交互操作由代表服务端远程对象的本地对象提供支持。为实现插件的最佳性能以及 Orchestrator 用户界面的卓越响应能力,您可以缓存本地对象而不是每次都从远程服务上获取。您可以考虑缓存的范围,例如所有插件客户端使用一个缓存、插件按用户各使用一个缓存以及第三方服务按用户各使用一个缓存。实施后,缓存机制会与插件接口集成以查找并使对象失效。

将对象置于后台

如果必须在插件清单中显示较长的对象列表,并且没有较快途径来检索这些对象,您可以将对象置于后台。例如,通过使对象具有 fakeloaded 状态,您可以将其置于后台。假设 fake 对象易于创建并且在清单中要显示的信息最少,例如名称和 ID。那么,就可以始终返回 fake 对象,并且当确实需要所有信息(真实对象)时,正在使用的实体或插件可以自动调用方法 load 来获取真实对象。您甚至可以配置在返回假对象后自动启动加载对象流程,从而预测使用中实体的操作。

克隆对象以避免并发问题

如果为插件使用缓存,则必须克隆对象。使用的缓存如果始终将对象的同一实例返回至每个发起请求的实体,则可能会发生意料之外的结果。例如,实体 A 请求了对象 O,并且实体查看了清单中的对象及其所有属性。与此同时,实体 B 也请求了对象 O,并且实体 A 运行了开始更改对象 O 属性的工作流。在运行结束时,工作流调用了对象的 update 方法来更新服务器端的对象。如果实体 A 和实体 B 获得对象 O 的同一实例,则实体 A 会在清单中看到实体 B 执行的所有更改,甚至在更改内容提交到服务器之前也能看到。如果运行正常,这应该不是问题。但如果运行失败,则实体 A 请求的对象 O 属性无法恢复。在这种情况下,如果缓存(插件的 find 操作)返回对象的克隆内容而不是始终返回同一实例,即每个都使用实体查看并修改各自的副本,则至少可在 Orchestrator 内避免并发问题。

向他人通知更改

同时使用缓存和克隆对象时可能会发生问题。最大的问题是使用实体视图的对象可能不是可用于对象的最新版本。例如,如果某个实体显示了清单、已经加载一次对象,但同时如果另一实体更改了部分对象,则首个实体不会看到更改内容。为避免此问题,您可以使用 Orchestrator 插件 API 中的 PluginWatcherIPluginPublisher 方法通知发生的更改,从而使 Orchestrator 客户端的其他实例能看到更改内容。如果清单中某个对象的更改影响了清单的其他对象,并且受影响对象也需要获得通知,那么上述情况也适用于 Orchestrator 客户端的唯一实例。倾向于使用通知的操作包含添加、更新和删除对象(如果这些对象或其部分属性显示在清单内)。

启用随时查找任意对象

您必须实现 IPluginFactory 接口的 find 方法来仅按类型和 ID 查找对象。重新启动 Orchestrator 并恢复工作流后,可以直接调用 find 方法。

模拟查询服务(如无)

Orchestrator 客户端可以要求在特定情况下查询部分对象,或要求将对象显示为列表或表格而非树形图。这意味着您的插件必须可以随时查询部分对象集。如果第三方技术提供了查询服务,则您需要适应并使用该服务。否则,无论解决方案的复杂度有多高,性能有多低,您都应可模拟查询服务。

查找方法不应返回运行时异常

IPluginFactory 接口中用于在插件中实施搜索的方法不应出现受控或不受控的运行时异常。这可能是当工作流在运行时出现异常验证错误失败的原因。例如,在工作流的两个节点之间,如果首个节点的输出是第二个节点的输入,则会调用 find 方法。此时,如果由于任何运行时异常而无法找到对象,您可能在 Orchestrator 客户端中不会收到除验证错误之外的更多信息。在此之后,根据插件记录异常的方式,可以在日志文件内获取或多或少的信息。