Warewolf 评测

作为开发者，我们花费大量时间来连接应用程序的各种组件，这并不有趣。对我而言尤其如此，这很烦人，因为我的强项是处理和分析结果，而不是处理数据。但在我目前的应用程序中，我无法避免这项工作， resulting code has been a kludge that is not stable, and just bad logic. 我一直在寻找新的资源。

我有机会测试了一下 Warewolf，看看它是否能奏效。Warewolf 是一个很有前景的产品，可以帮助敏捷的前端应用程序处理繁重的后端任务。本文将介绍我使用该产品的体验。

首先，我想明确 Warewolf 是什么，以及它不是什么。他们的网站谈论微服务。我不认为这个工具是构建微服务的方式。微服务意味着一种非常特定的应用程序规划和构建方式，并且还有其他方面需要考虑，例如基础设施和容器。它还包括企业服务总线 (ESB)、构建 API 的工具以及作业创建等元素。

我的最终结论是，Warewolf 属于工作流或基于节点的编程类别。基本上，你有一个画布——各种节点类型，每种类型都有特定的配置。你可以连接节点，在它们之间创建逻辑，最终得到一个可运行的应用程序。如今市面上有很多类似的工具，包括开源和商业的，但它们主要专注于物联网和移动应用程序开发，而不是企业应用程序开发。

这种方法很棒，因为 GUI 使事情变得更容易。并且每个画布都可以整体可视化逻辑，而不是通过浏览代码来理解发生了什么。

安装

Warewolf 的安装很简单。起初，我很高兴尝试 marketplace 中的 Azure 实例。(但那次尝试并未成功。)

Warewolf 的最低要求包括使用 Azure 中的 A2 Basic 实例，这大约每月 200 美元。此时我有点穷，所以我忍不住尝试了一个 A0（.25 核）实例。但这不起作用。微软应该给供应商一个机会来说明哪些实例类型有效，哪些无效，并隐藏无效的实例。

不过没关系。我转而使用了本地虚拟机，从功能齐全的 试用版 下载了软件，并进行了快速安装。安装完成后，所有服务器服务都已启动，控制台也立即启动了。然后就是熟悉环境的时候了。

我立刻注意到了一件我非常感谢 Warewolf 团队的事情，那就是示例！他们有大量即时可用的示例；示例之多，足以让你演示几乎所有节点的类型和所有常见场景的基本配置。我是一个喜欢动手实践、讨厌阅读手册的人，所以这对我帮助很大。

我花了一些时间浏览示例，最终找到一个适合我应用程序的起点，名为“文件和文件夹 - 移动”。还有一个更高级的备份示例也可以工作，但我还没有准备好。由于我找不到复制“文件和文件夹”项目的方法，所以我将画布上的一切都复制粘贴到一个新项目中，并开始定制。

我的应用程序

我正在构建的应用程序是关于文档转换、索引和匹配的。基本上，它接收不同类型的文档，并根据内容相似性创建关联，以构建关系图。该应用程序接受许多输入文件类型：文档、图像、音频和视频文件，但逻辑都基于文本文件，每种文件类型都需要转换。媒体文件比较棘手。它们需要一些额外的转换才能变得有用，而文档只需简单转换。因此，对于媒体文件，我需要使用识别技术来获取足够的元数据进行分析。

如果你熟悉光学字符识别 (OCR) 和语音识别技术，你就会知道它们需要一台功能强大的服务器。它们会消耗大量 CPU，有时处理单个文件需要很长时间。虽然我的应用程序目前启用了识别功能，但设置并不理想。

目前，所有文件都复制到识别服务器上的共享位置。它们计划每天转换两次。转换完成后，结果将序列化到 Azure Blob 存储，由 Azure Search 索引，然后删除原始文件。这有很多问题。

1. Web 应用程序用户必须等待计划的运行（6-12 小时）。
2. 由于我将所有文件处理作为批处理运行，如果一个文件出现问题，可能会导致整个批处理失败。
3. 我必须在单独的 Azure WebJob 中创建特殊逻辑，以跟踪何时记录结果。
4. 由于处理时间不可预测，可能会错过前一批的结果，这意味着等待时间翻倍。
5. 没有基于文件类型的逻辑，这意味着我必须通过识别服务器本身来测试文件类型。如果上传了一个音频文件，OCR 服务会先尝试，如果被拒绝，则将其发送到语音识别服务的目录。（浪费大量时间。）
6. 文档与媒体文件一样延迟，因为它们在同一个批处理中，但它们应该立即处理。

一个选择是将应用程序的更多部分运行在识别服务器上，但这会导致 Web 用户延迟，并且无法扩展。

这就是 Warewolf 发挥作用的地方。我的想法是：使用该工具连续运行，当文件上传到识别服务器时。当文件上传时，我想根据文件类型决定做什么。当生成结果时，我想将结果 POST 回我的 Web 应用程序，它正在监听结果。

于是，我构建了它。

我使用的节点相当直接。只有在理解 RecordSets 和分配数据源如何工作时，我才遇到困难。最终我绕过了它们，因为我有很多关于跟踪数据集的问题。我也想使用“For Each”节点，但我无法弄清楚如何将“Decision”包含在循环逻辑中。没关系，因为文件频率不高，并且由于流程正在规律运行，文件被拾取时的延迟不超过 15 分钟。下面是一个“Decision”节点的逻辑示例，它查看包含“.jpg”的完整文件路径；如果为真，则发送到 OCR 路由。

我使用的三种节点类型是“Decision”、“POST”、“Copy”和“Read Folder”。我感觉有更好的方法可以做到这一点。实际上，我创建了两个流程，而我可能只需要一个。但首先，我创建了 In Flow，用于处理通过 Web 应用程序上传的所有文档，以及 Out Flow，用于处理最终转换的所有文档。以下是 In Flow 的最终逻辑

以下是 Out Flow 运行的 JSON 结果

现在，在 Web 应用程序中，用户会在队列中看到他们的文件，并且当单个文件完成时，结果会异步返回——而不是一次性全部返回。

下一步

我还有很多事情想用这些流程来做。到目前为止，我仍然需要一个 Azure WebJob，但这个 WebJob 不需要与服务器交互。它只负责接收结果通知并索引文件。

共享资源服务器功能是下一步。这可以在流程之间集中资源。所以，如果我愿意，我可以从两个流程传递变量，从而避免在我的 Web 应用程序中出现任何状态。我可以从本地文件共享切换到 Dropbox，这是一个内置在 Warewolf 中的连接器。如果我选择这样做，我可以利用 Dropbox API 中的一些功能，避免使用可能很大的虚拟机，并且应该具有更快的传输速度。

我还可以利用该功能来提取系统信息。对于那些会消耗大量资源的识别技术，我可以使用此功能来创建更高级的处理分发逻辑。它还可以为我提供更多的处理反馈以呈现给用户。

我注意到了一些额外的功能，我真的很想测试，但还没有用例（ yet）。我还注意到与 SharePoint 的大量集成，这引起了我的兴趣，因为我多年来进行了大量的 SharePoint 开发。事实上，我最近为 SharePoint 编写的一个用于自动文件同步和 MMS 填充的应用程序，如果使用 Warewolf 可能会更快完成。（我不得不放弃这个应用程序，因为它维护起来很麻烦。）

运行

运行应用程序很简单。你点击项目名称旁边的播放按钮，可以选择在调试模式下运行，或者直接在浏览器中运行。我发现，在 Microsoft Edge 中运行这些应用程序效果不太好。即使在本地运行，我也会遇到安全问题，所以我所有的测试都在 Chrome 中进行。另外，值得注意的是，虽然每个项目在每个画布的顶部都提供了一个应用程序 URL，但这对大多数项目来说并不太有用，因为它不会传递输出或输入变量——所以务必使用播放按钮。

我尝试在 Warewolf 服务器之外进行大部分测试，以确保可以从 Web 访问服务。由于 Warewolf 与识别服务运行在同一台机器上，我所要做的就是本地安排服务器并告诉 Web 应用程序监听结果。在一个完整的设置中，你可能需要将 Warewolf 服务器分开，但要在同一局域网内，并且至少有两个 Warewolf 服务器，一个用于开发，一个用于部署生产流程。

测试正在运行的流程的一个好方法是利用像 Postman 这样的工具。这很快，而且允许你测试来自 Web 的调用，而不仅仅是内部调用。

上线运行

我花了大约两天时间完成设置和与我的 Web 应用程序的集成。我仍然称之为 Beta 版，但我已经看到了更好的结果。我的单个文件处理时间不到一小时，而不是每 12 小时一次。我的核心应用程序的逻辑复杂得多，文件处理也稳定得多。

我认为该应用程序可以在 UI/UX 方面有所改进。我还认为数据源的处理可以得到简化。例如，RecordSets 花费了我很长时间才理解。但没有任何东西阻止我构建我的应用程序。而且，他们有很好的文档在其 知识库 中。

一个我花了一段时间才找到，但我非常想要的功能是 版本控制。你可以对流程进行版本控制，以便在进行更改时可以回滚。这是一个重要的功能。

在我完成我的应用程序后，我意识到我的用例可能不是最好的。更好的场景是当你需要创建一个 Web 服务集合而不必从头开始构建自己的 API，或者不需要一个完整的 API。

这种方法的威力

Warewolf 对于快速创建后台作业非常有用，特别是对于业务线或流程密集型应用程序。通过我与该产品合作的一小段时间，我能够改进我的应用程序的逻辑，并卸载了一些非常繁琐的处理过程。采用这种方法的完整好处列表是

1. 更容易管理核心应用程序之外的代码。
2. 更容易管理作业逻辑
3. 更容易升级我的逻辑
4. 更容易与团队共享逻辑：无需代码审查，只需流程审查。
5. 出色的调试：你无法为脚本作业获得这样的调试。

除了流程示例，我必须赞扬 Warewolf 团队和社区（我提过它是开源的吗？）没有将产品复杂化，没有添加很多专业语言或功能。（有些工具需要类，而且你必须专门学习该工具才能开始。）Warewolf 中的一切都标准且直观，令人愉悦。

我不知道 Warewolf 或基于流程的编程是否对所有应用程序都有用。但是对于现有应用程序的后台作业，或者主要基于逻辑且用户交互最少（不要与输入混淆）的应用程序，Warewolf 是一个绝佳的解决方案。

Warewolf 需要考虑的事项

• “Decision”仅在我关闭并重新打开时添加新条件。
• 在工具箱中，你只能拖动一个已选中的对象，即使它与你拖动的对象不同。最好不要每次都先选择。
• 当我点击一个示例时，它应该立即打开，而不是需要点击一个眼球图标
• 当我选择 OpsSystem 用于系统信息示例时，Warewolf 崩溃了。
• 不清楚如何命名一个文档。
• 我希望能够复制项目。
• 如果我更改了 Decision 的显示文本，然后添加了第一个值，它会重命名显示文本
• 画布上的吸附网格会很方便。
• 使用 Delete 键删除节点会很方便。
• 不明白为什么你不能在“For Each”块中放置一个“Decision”。
• 画布上有一个运行按钮会很方便。

---

来自 Warewolf，对 Code Project 上发布的 Warewolf 评测的回应。

感谢您撰写有关 Warewolf 的文章！

我们咨询了我们的技术团队，并希望就本次评测中提出的主要问题提供一些意见。

• 首先，我们认为提及设计表面的顶部 URL *确实* 可以作为变量传递输入和输出，这一点非常重要。
• 每个服务都会接受输入并产生输出，如果它们在 变量列表 中这样设置的话。
• 每个工作流都是一个可以被另一个工作流调用（只需将其拖放为一个节点）或从 Web 调用其的服务。
• 调试（播放按钮）用于 调试。

回应提出的观点

Warewolf 需要考虑的事项

• “Decision”仅在我关闭并重新打开时添加新条件。
  • 谢谢，这是一个 bug。将在下一个版本中解决。
• 在工具箱中，你只能拖动一个已选中的对象，即使它与你拖动的对象不同。最好不要每次都先选择。
  • 同意。已修复，将在下一个版本发布。
• 当我点击一个示例时，它应该立即打开，而不是需要点击一个眼球图标
  • 双击一个项目即可打开它。我们喜欢单击即可打开的想法，并将将其放入待办事项列表。
• 当我选择 OpsSystem 用于系统信息示例时，Warewolf 崩溃了。
  • 哇。我们完全无法复制此问题。请在崩溃时发送崩溃报告！
• 不清楚如何命名一个文档。
  • 保存时提供名称。我们也许应该在创建时就这样做。我们将添加到待办事项列表。
• 我希望能够复制项目。
  • 同意。已在待办事项列表。
• 如果我更改了 Decision 的显示文本，然后添加了第一个值，它会重命名显示文本
  • 这是按设计进行的
• 画布上的吸附网格会很方便。
  • 我们喜欢当前设计表面的易于定位。也许提供一个选项。
• 使用 Delete 键删除节点会很方便。
  • 如果节点被选中，按 Delete 键将从服务中删除它。
• 不明白为什么你不能在“For Each”块中放置一个“Decision”。
  • 这是按设计进行的。Decision 会改变流量方向，因此在一个执行中不能执行多次。要实现这一点，请创建一个包含 Decision 的服务，然后将该服务拖放到“For Each”中。
• 画布上有一个运行按钮会很方便。
  • 你还可以利用快捷键来运行和调试你的流程。F6 在 Studio 中调试（使用之前的输入值），F7 从浏览器运行工作流服务。

我们正在努力为用户制作一套更友好的视频，以进一步降低学习曲线。在此期间，我们有两个非常全面的用户指南，其中包含分步练习，让你在使用 Warewolf 的同时进行学习。从这里开始：https://warewolf.io/knowledge-base/warewolf-user-guide-1/

我们非常感谢你对一些细节的反馈——我们很乐意收到反馈！我们很乐意邀请所有开发人员通过我们的 社区论坛 分享他们对 Warewolf 的体验。