这对 Elsa 来说是一个很好的用例，我正计划为此创建一个示例应用程序 + 指南。到目前为止，有关于使用 Elsa 执行长时间运行的“后端”进程的指南和示例，但现在有理由不能也使用它来实现应用程序导航逻辑，例如由实现为单独屏幕的步骤组成的向导例子。
这就是你的答案：是的，这是一个相关的场景。但很遗憾，目前没有具体的样本可以为您指出。
除非有任何示例，否则它在客户端应用程序中的工作方式如下：
- 客户端应用程序配置了 Elsa 服务。
- 无论您决定将工作流存储在应用程序中（作为代码还是 JSON）还是存储在远程 Elsa Server 实例上都没有关系 - 一旦您在内存中有工作流，您就可以执行它。
- 由于您的工作流将驱动 UI，因此您必须考虑工作流与该 UI 的紧密耦合程度。例如，高度紧耦合的工作流可能包括表示要呈现的视图（名称）的活动，包括转换配置（如果需要配置），以及基于单击的按钮的结果。另一方面，高度松散耦合的工作流可能更多地充当动作和事件的“指挥者”或协调者，其中工作流仅由一堆原语组成，例如“SendCommand”和“Event Received”，其中一个“SendCommand”只是引发一些应用程序事件，其任务名称是您的应用程序然后处理的。 “Event Received”活动以相反的方式处理：您的应用程序向 Elsa 发出指令，而 Elsa 驱动工作流。任务可能是“导航”指令，其中下一个视图名称作为参数提供。
“SendCommand”和“EventReceived”活动是非常新的，是 Elsa 2.1 预览包的一部分。现在它们直接耦合到 webhook 场景（命令以 HTTP 请求的形式发送到外部应用程序），但目标是制定各种策略（HTTP out 请求只是其中之一，另一个可能是一个简单的中介模式，用于进程内场景，例如您的客户端应用程序）。
更新
要将设计器中设计的工作流检索到您的客户端应用程序中，您需要通过以下 API 端点获取工作流定义：
http(s)://your-elsa-server/v1/workflow-definitions/{workflow-definition-id}/Published
您将得到一个表示工作流定义的 JSON，您现在可以使用 IContentSerializer.Deserialize<WorkflowDefinition> 对其进行反序列化，这将为您提供 WorkflowDefinition。但是为了能够实际运行工作流，您需要一个工作流蓝图。要将工作流定义转换为蓝图，请使用 `IWorkflowBlueprintMaterializer.CreateWorkflowBlueprintAsync(WorkflowDefinition)。
这将为您提供一个蓝图，然后可以使用例如执行IStartsWorkflow.StartWorkflowAsync(IWorkflowBlueprint).
还有各种其他服务可以更方便地构建和运行工作流。
为了使您的客户端应用程序尽可能顺畅，您可以考虑简单地实现 IWorkflowProvider，我们目前有 3 个开箱即用：
-
ProgrammaticWorkflowProvider：提供基于使用 Fluent Workflow Builder API 编码的工作流的工作流蓝图。
-
DatabaseWorkflowProvider：提供基于数据库中存储的蓝图（设计者存储的 JSON 模型）。
-
StorageWorkflowProvider：提供基于存储在某些硬盘驱动器或 Blob 存储（如 Azure Blob 存储）上的 JSON 文件的蓝图。
您可能会做的，事实上我认为我们应该开箱即用地提供，因为您让我想到它，是创建第四个提供程序，使用 API 端点从中获取工作流。
那么您的客户端应用程序不必为调用 Elsa API 而烦恼 - 提供程序会为您完成。