受管调用

Managed File Transfer (MFT) 代理程序通常用来传输文件或消息。 它们称为受管传输。 代理程序也可用于运行命令、脚本或 JCL，而无需传输文件或消息。 此功能称为受管调用。

受管调用请求可以通过多种方式提交给代理程序：

对于受管调用，必须在代理程序属性 commandPath 中指定包含要运行的命令或脚本的目录。

受管调用无法运行位于代理程序的 commandPath中未指定的目录中的命令或脚本。 这是为了确保该代理程序不会运行任何恶意代码。
重要信息: 缺省情况下，要确保在指定 commandPath时出现此情况，请执行以下操作:
  • 代理在启动时配置任何现有代理沙箱，以便将所有 commandPath 目录自动添加到已拒绝传输访问的目录列表中。
  • 代理程序启动时，将更新任何现有用户沙箱，以便将所有 commandPath 目录 (及其子目录) 作为 <exclude> 元素添加到 <read> 和 <write> 元素。
  • 如果未将代理程序配置为使用代理程序沙箱或用户沙箱，那么在代理程序启动时将创建新的代理程序沙箱，并将 commandPath 目录指定为已拒绝的目录。

此外，您还可以对代理程序启用权限检查，以确保仅允许授权用户提交受管调用请求。 有关更多信息，请参阅限制针对 MFT 代理程序操作的用户权限。

作为受管调用的一部分调用的命令、脚本或 JCL 将作为外部进程运行，该进程由代理程序监视。 当进程退出时，受管调用将完成，并且来自进程的返回码可供调用 fte:call Ant 任务的代理程序或 Ant 脚本使用。

如果受管调用是由 fte:call Ant 任务启动的，那么 Ant 脚本可以检查返回码的值以确定受管调用是否成功。

对于所有其他类型的受管调用，您可以指定应该使用哪些返回码值来指示受管调用已成功完成。 外部进程完成时，代理程序会将来自进程的返回码与这些返回码进行比较。
注: 由于受管调用作为外部进程运行，因此一旦启动，就无法取消这些受管调用。

受管调用和源传输插槽

代理程序包含多个源传输槽（由代理程序属性 maxSourceTransfers 指定）如高级代理程序属性：传输限制中所述。

每当运行受管调用或受管传输时，它们会占用源传输插槽。 该插槽在受管调用或受管传输完成时释放。

如果在代理程序收到新的受管调用或受管转移请求时所有源传输插槽都在使用中，则该请求将由代理程序排队，直到有可用插槽。

如果受管调用启动受管传输（例如，如果受管调用运行 Ant 脚本，并且 Ant 脚本使用 fte: filecopy 或 fte: filemove 任务来传输文件），那么需要两个源传输插槽：
  • 一个用于受管传输
  • 一个用于受管调用

在此情况下，请务必注意，如果受管传输需要较长时间才能完成或进入恢复，那么将占用两个源传输插槽，直到受管传输完成，取消或由于 transferRecoveryTimeout而超时为止。 有关 transferRecoveryTimeout的详细信息，请参阅 传输恢复超时概念 。 这可能会限制代理程序可以处理的其他受管传输或受管调用的数量。

因此，您应该考虑受管调用的设计，以确保它在很长一段时间内不会占用源传输插槽。

将 REST API 与受管调用配合使用

HTTP GET 和 HTTP POST 命令支持启用托管调用，且仅适用于 REST API 的版本3。

其他动词，例如 HTTP 和 HTTP ，不支持，如果您尝试使用它们，将返回 HTTP。
注意: 提交后，无法使用 REST API取消受管调用。